---
title: ""
canonical: "https://studiomeyer.academy/en/playbooks/mcp-mit-lokalen-modellen"
language: en
publisher: "StudioMeyer Academy, https://studiomeyer.academy (llms.txt: https://studiomeyer.academy/llms.txt)"
---

[← Alle Playbooks](https://studiomeyer.academy/playbooks)

Playbook· lokal

# MCP with local models, tools without the cloud

A local model that does not just talk but reads files, checks the calendar and uses your memory. Ten steps to a fully self-owned setup, including the point where small models fail at tool calling.

A language model on its own is a conversation partner without hands. It cannot look anything up, cannot compute, cannot fetch, it can only answer from what is in the conversation. It gets interesting when it is given tools, and the protocol for that is MCP.

What is taken for granted with Claude or ChatGPT also works entirely locally. Model on your machine, tools on your machine, data on your machine. This playbook shows the way there and says at the right point where it gets rough, because at one point it genuinely does.

## 1\. Work out which three parts you need

The protocol knows three roles, and the confusion usually comes from throwing the model in with them.

The **host** is the application you sit in, Claude Desktop or a local web interface for instance. It starts one **client** per connection, and each client talks to exactly one **server**. The server provides the tools, file access or a database for instance.

The model is deliberately not in that list. It is not a participant in the protocol. The host collects the tool list from the servers, puts it in front of the model, and when the model wants to call one, the host executes the call. That sounds like hair-splitting, but it is the reason the same server works behind any model.

In Claude Desktop the host and the model access sit in one application. In a local setup you separate them: Ollama supplies the model, an interface or your own script is the host. It is the same server software as with Claude, and that is the entire point of an open protocol. Which servers you actually register in which environment is independent of that and a security question, see step 10.

**Tip:** If the protocol itself is still unfamiliar, read the lesson [What is MCP](https://studiomeyer.academy/levels/4/02-was-ist-mcp) first. Everything here assumes it.

## 2\. Check whether your model can use tools at all

Not every local model handles tool calling. Some were never trained for it, others can do it formally and then use it wrongly. That is the first hurdle, and it eliminates a good share of the candidates.

In the Ollama library, models with tool support are labelled accordingly. Stick to that instead of trying and then spending half an hour looking for why nothing happens.

**Tip:** For tool calling do not take the smallest model you can find. Below roughly seven billion parameters the capability is largely missing and you get malformed calls. Above that, what decides is not size but whether the model was explicitly trained for it: in comparisons, 8B and 14B models with tool training land close together, while considerably larger models without that training do worse. Bigger is not automatically better here.

## 3\. Take an interface that already speaks MCP

The fastest route is an interface that brings the protocol along. Open WebUI has supported MCP natively since version 0.6.31 and is built for local models. That saves you writing the client yourself.

The setup is then: Ollama runs in the background, Open WebUI connects to it, and in its settings you register your MCP servers.

One detail catches nearly everyone on the first attempt: the servers are the same, the registration is not. What Claude Desktop configures as a locally started process (stdio, so a command plus arguments) needs a reachable address in a web interface. Some servers can do both, others only one.

If you need a bridge for a stdio server, that is not a mere format change but a new open door. Bind it to `127.0.0.1`, give it an access token, and do not put it on the network. A file server exposed through a bridge without authentication is file access for anyone who knows the address.

**Tip:** Before you build your own client, try the ready-made one. Most people notice at that point that they do not need their own.

## 4\. Start with a harmless server

Take a read-only server first. File access restricted to a single test directory is ideal. That way you see whether the chain works without a misfire doing any damage.

Then ask the model a question it cannot answer without the tool. "What does the file notes.txt say" is a good test, because the answer is unambiguously right or wrong.

**Tip:** If the model answers without having used the tool, it made the answer up. That is exactly why a test with an unambiguous answer beats an open-ended one.

## 5\. Expect the model to overlook tools

Here is the point where local setups differ from Claude, and it matters more than anything technical.

A large model reliably decides when a tool is needed. A small local model does not always. It sometimes answers from its gut although the right tool is sitting there. It sometimes calls the wrong one. And on a chain of several steps it can lose the thread.

Before you blame the model: it can also come from the setup. A wrong chat template, a server that does not describe its tools cleanly, too coarse a quantization, an interface that does not pass tool calls through at all. Check that first. If the behaviour survives, it is a capability limit of the model, and you will not configure that away.

**Tip:** The fewer tools are active at once, the more reliable the selection gets. Three well described tools beat twenty, and with small models by a wide margin.

## 6\. Write tool descriptions for a weaker model

With a strong model a tool description may be terse, it works out the context by itself. With a local model the description is your most important lever.

Write into it when the tool is to be used, not only what it does. So instead of "searches the database", write "use this when the question is about a customer, an invoice or a case". The difference in hit rate is substantial.

**Tip:** If you build your own servers, that is better practice anyway. The rules for good tool design are in [Tool design](https://studiomeyer.academy/levels/6/03-tool-design), and with local models they pay off twice over.

## 7\. Attach your memory

The most valuable server in a local setup is the one that remembers things. A small model knows little about the world and even less about you. A memory partly compensates for both, because then the knowledge does not have to sit inside the model, it gets looked up.

That is also the point where the size question loses its edge. An 8 billion model with access to your notes beats a large model without that access on questions about your project.

**Tip:** This is precisely the core thesis of this academy. A model that knows your context beats a stronger one that has to guess. The setup is in [Setting up memory](https://studiomeyer.academy/levels/4/03-memory-einrichten).

## 8\. Keep writing tools on a short leash

Writing tools are the obvious risk. A model that can delete files, send mail or change records and occasionally grabs the wrong tool is an uncomfortable combination. Those need a confirmation, always.

That does not make reading harmless, and this is the mistake you read in guides constantly. A read tool with too wide a scope pulls SSH keys, credentials, tax paperwork or client data into the model context, and from there into logs and histories. If you later run that same interface against a cloud model once, that is exactly the route outward you were trying to avoid. On top of that: what is named "read" need not be free of side effects, the protocol does not enforce that.

So the rule is not "reading free, writing locked" but as little access as possible on both sides. Give the file server a single directory rather than your home folder, and have writing actions confirmed.

**Tip:** Start with a single directory in read access and widen only once you know what the setup actually touches. Not the other way round.

## 9\. Vet third-party servers before you attach them

An MCP server is executable code on your machine. Your model running locally does not make a third-party server any safer. The privacy gain from the local model is gone if the attached server phones home.

**Tip:** The vetting procedure is in [Vetting third-party MCP servers safely](https://studiomeyer.academy/playbooks/fremde-mcp-server-sicher-pruefen). In a setup that is explicitly local for privacy reasons, this step is not optional.

## 10\. Decide honestly whether it is enough

After a week of daily use you know whether the setup carries. Two outcomes are normal and both are fine.

Either it is enough, and then you have an assistant with tools where nothing leaves the house. Or it is not enough, because the model reaches wrong too often. Then the answer is not "local is useless" but a mixed setup: the local one for everything with sensitive data, the large model for the hard cases.

What step 8 warns about applies here, though. If you switch between local and cloud model inside the same profile, the tools and the existing history come along, and with them everything a read tool pulled in earlier. So separate at the level that actually separates: two **separate installations**, or separate configuration directories. A second window is not enough, and neither is a second user profile in the same interface: the MCP servers and model credentials are usually registered globally there, so both profiles can reach them. The local installation holds the sensitive servers and no cloud access; the other holds the cloud access and simply does not list those servers.

**Tip:** That an MCP server COULD run on both sides does not mean it should. Portability saves you the learning curve when setting up the second environment, not the decision about which servers get registered there at all. More on the principle in [Tool portability](https://studiomeyer.academy/levels/4/05-tool-portabilitaet).

## What next

If the model itself is still missing, start with [Your first local AI model in 30 minutes](https://studiomeyer.academy/playbooks/erstes-lokales-modell-in-30-minuten). The size question is covered by [Which local model fits your hardware](https://studiomeyer.academy/playbooks/welches-lokale-modell-passt-zu-deiner-hardware). And if you eventually want to build your own server instead of attaching other people's, level 6 with [Planning an MCP server](https://studiomeyer.academy/levels/6/01-mcp-server-planen) is the way in.

## Sources

- Model Context Protocol, official specification: https://modelcontextprotocol.io
- Ollama, models with tool support: https://ollama.com/search?c=tools
- Open WebUI, documentation on the MCP connection: https://docs.openwebui.com

[← Local AI and the GDPR, what it](https://studiomeyer.academy/playbooks/lokale-ki-und-die-dsgvo) [Local or cloud, the honest ari →](https://studiomeyer.academy/playbooks/lokal-oder-cloud-die-ehrliche-rechnung)

Alle Playbooks

[01. From ChatGPT to Claude, guide in 10 steps](https://studiomeyer.academy/playbooks/von-chatgpt-zu-claude) [02. From ChatGPT to Codex, guide in 10 steps](https://studiomeyer.academy/playbooks/von-chatgpt-zu-codex) [03. Your first MCP server in 90 minutes](https://studiomeyer.academy/playbooks/erster-mcp-server-in-90-minuten) [04. Using memory portably, same memory in Claude, Codex and Cursor](https://studiomeyer.academy/playbooks/memory-portabel-nutzen) [05. DACH legal. EU AI Act and GDPR for AI operators](https://studiomeyer.academy/playbooks/dach-legal-eu-ai-act-und-dsgvo) [06. Your first sub-agent in 30 minutes](https://studiomeyer.academy/playbooks/erster-sub-agent-in-30-min) [07. Publishing an MCP server step by step](https://studiomeyer.academy/playbooks/mcp-server-publishen) [08. Hooks against hallucinations](https://studiomeyer.academy/playbooks/hooks-gegen-halluzinationen) [09. Git for AI, 30-minute quickstart](https://studiomeyer.academy/playbooks/git-fuer-ki-quickstart) [10. Scheduled agents with Claude Code routines](https://studiomeyer.academy/playbooks/scheduled-agents-mit-routines) [11. Avoiding tool sprawl, from 530 to 30 MCP tools per session](https://studiomeyer.academy/playbooks/tool-sprawl-vermeiden) [12. Claude Code update strategy, without your workflow suddenly breaking](https://studiomeyer.academy/playbooks/claude-code-update-strategie) [12. Structuring your subagent team, the six roles you need in a daily driver](https://studiomeyer.academy/playbooks/subagent-team-strukturieren) [13. Claude Code cost controls for daily drivers, staying under 30 dollars a day in 10 steps](https://studiomeyer.academy/playbooks/claude-code-cost-controls-fuer-daily-driver) [14. Your own slash commands for Claude Code, productive in 30 minutes](https://studiomeyer.academy/playbooks/eigene-slash-commands-fuer-claude-code) [15. Claude Code headless in CI/CD, a setup that runs tomorrow](https://studiomeyer.academy/playbooks/claude-code-headless-in-ci-cd) [16. Agent eval in 60 minutes, how to find out if your agent is any good](https://studiomeyer.academy/playbooks/agent-eval-in-60-minuten) [17. Plan Mode in Claude Code, the invisible seatbelt, when you need it and how to keep it on](https://studiomeyer.academy/playbooks/plan-mode-richtig-nutzen) [18. Debugging MCP when nothing works, the 10 checks that solve 90 percent of cases](https://studiomeyer.academy/playbooks/mcp-debuggen-wenn-nichts-geht) [18. Mastering prompt caching, from cache miss to an 80 percent hit rate in 10 steps](https://studiomeyer.academy/playbooks/prompt-caching-meistern) [19. Repair memory drift, when your agent's memory starts contradicting itself](https://studiomeyer.academy/playbooks/memory-drift-reparieren) [20. MCP STDIO security, what the OX Security story means for you](https://studiomeyer.academy/playbooks/mcp-stdio-sicherheit) [21. Opus 4.7 migration, what changed for API builders](https://studiomeyer.academy/playbooks/opus-4-7-migration) [22. Your first Skill in 30 minutes, when slash commands aren't enough](https://studiomeyer.academy/playbooks/erste-eigene-skill-in-30-min) [23. Managing the context window in long Claude Code sessions](https://studiomeyer.academy/playbooks/context-window-managen-claude-code) [24. Advisor Tool, Opus as advisor and Sonnet as executor in one API call](https://studiomeyer.academy/playbooks/advisor-tool-opus-als-berater-sonnet-als-executor) [25. Secure your MCP server with OAuth 2.1 in 60 minutes](https://studiomeyer.academy/playbooks/mcp-server-auth-mit-oauth-2-1) [26. Distributing plugin bundles via URL, --plugin-url in 30 minutes](https://studiomeyer.academy/playbooks/plugin-bundle-via-url-distribution) [27. Claude Code in a Team, how to keep CLAUDE.md alive without turning it into a trash bin](https://studiomeyer.academy/playbooks/claude-code-im-team-claude-md-gemeinsam-pflegen) [27. Loading third-party Claude Code plugins from ZIP and URL, safely in 20 minutes](https://studiomeyer.academy/playbooks/claude-code-plugins-aus-zip-und-url-laden) [28. Confused deputy audit for Claude Code, done in 25 minutes](https://studiomeyer.academy/playbooks/confused-deputy-audit-fuer-claude-code) [28. Your first Claude Code plugin in 60 minutes, from empty folder to installable bundle](https://studiomeyer.academy/playbooks/dein-erstes-claude-code-plugin) [29. Pull request reviews with Claude Code, 10 steps for a PR workflow nobody blocks anymore](https://studiomeyer.academy/playbooks/pull-request-reviews-mit-claude-code) [30. Claude Projects for non-coders, a productive workspace in 30 minutes](https://studiomeyer.academy/playbooks/claude-projects-fuer-nicht-coder) [31. Build a prompt library, reuse your favourite prompts without copy-paste](https://studiomeyer.academy/playbooks/prompt-bibliothek-aufbauen) [32. Output Styles for Claude Code, your own tone in 20 minutes](https://studiomeyer.academy/playbooks/output-styles-fuer-claude-code) [33. Statusline for Claude Code, context at a glance in 15 minutes](https://studiomeyer.academy/playbooks/statusline-fuer-claude-code) [34. Claude Code checkpoints and /rewind: your safety net for risky edits](https://studiomeyer.academy/playbooks/claude-code-checkpoints-und-rewind) [34. Keeping discovery files consistent so AI crawlers do not quote old nonsense bios](https://studiomeyer.academy/playbooks/discovery-files-konsistent-halten) [34. Debugging hooks when nothing fires](https://studiomeyer.academy/playbooks/hooks-debuggen-wenn-nichts-feuert) [34. Parallel Claude Code sessions with git worktrees, two branches at once without conflict](https://studiomeyer.academy/playbooks/parallele-claude-sessions-mit-worktrees) [34. Skill does not trigger, what to check in 10 steps before you type /command again](https://studiomeyer.academy/playbooks/skill-trigger-debugging) [34. Sub-agent or skill or MCP tool, which one do you pick when](https://studiomeyer.academy/playbooks/sub-agent-oder-skill-oder-mcp-tool) [35. Running parallel Claude Code sessions with git worktrees](https://studiomeyer.academy/playbooks/claude-code-mit-git-worktrees) [35. Memory backup before an update, so you do not cry over a schema migration bug](https://studiomeyer.academy/playbooks/memory-backup-vor-update) [36. AGENTS.md alongside CLAUDE.md, one repo context for several AI tools](https://studiomeyer.academy/playbooks/agents-md-neben-claude-md) [47. Generative Engine Optimization for small sites, so Perplexity and ChatGPT-Search cite you](https://studiomeyer.academy/playbooks/geo-fuer-kleine-sites) [50. Opus 4.8 migration, the first Opus update with no breaking changes](https://studiomeyer.academy/playbooks/opus-4-8-migration) [51. Background sessions with Claude agents: run long tasks without blocking your terminal](https://studiomeyer.academy/playbooks/background-sessions-mit-claude-agents) [52. Set up the Claude Code bash sandbox: isolate commands instead of blindly allowing them](https://studiomeyer.academy/playbooks/claude-code-bash-sandbox-einrichten) [53. From script to your own agent: the Claude Agent SDK in 90 minutes](https://studiomeyer.academy/playbooks/claude-agent-sdk-erster-eigener-agent) [54. Build an MCP App: interactive UI in your MCP tool instead of a wall of text](https://studiomeyer.academy/playbooks/mcp-app-interaktive-ui-bauen) [55. The expensive-model myth: when the top AI model is really worth it](https://studiomeyer.academy/playbooks/mythos-klasse-wann-lohnt-sich-das) [56. Setting up fallback models so Claude Code doesn't stall on overload](https://studiomeyer.academy/playbooks/claude-code-fallback-modelle) [57. Dynamic workflows in Claude Code, your first orchestrated multi-agent script](https://studiomeyer.academy/playbooks/dynamic-workflows-in-claude-code) [58. Security-guidance plugin for Claude Code, automatic security review while you build](https://studiomeyer.academy/playbooks/claude-code-security-guidance-plugin) [59. Claude Code acting up after a config change, how to find the cause](https://studiomeyer.academy/playbooks/claude-code-safe-mode-diagnose) [60. MCP is stateless: what the 2026-07-28 spec changes and what you need to do now](https://studiomeyer.academy/playbooks/mcp-spec-2026-07-was-aendert-sich) [61. Your first real n8n flow: automation for people who don't code](https://studiomeyer.academy/playbooks/mein-erster-n8n-flow-fuer-nicht-coder) [62. Agentic payments with x402, what builders need to know about machine-paid APIs](https://studiomeyer.academy/playbooks/agentic-payments-x402) [63. GPT-5.6 or Opus 5, which model for which task](https://studiomeyer.academy/playbooks/gpt-5-oder-opus-4-8-welches-modell) [64. Subagents that spawn subagents, Claude Code's 5-level rule](https://studiomeyer.academy/playbooks/subagents-die-subagents-spawnen) [65. Setting up Claude Code agent teams, multiple sessions working together](https://studiomeyer.academy/playbooks/claude-code-agent-teams-einrichten) [66. Tracking model availability, when a model vanishes overnight](https://studiomeyer.academy/playbooks/modell-verfuegbarkeit-tracken) [67. Data protection when working with AI tools: ten habits that keep you safe](https://studiomeyer.academy/playbooks/datenschutz-mit-ki-tools) [68. Using Auto Mode in Claude Code safely, in 10 steps without suicide commands](https://studiomeyer.academy/playbooks/claude-code-auto-mode-sicher-nutzen) [69. AI for the job hunt: 10 steps through the ATS filter](https://studiomeyer.academy/playbooks/ki-fuer-jobsuche) [70. Build an AI portfolio that lands you a job, in 10 steps](https://studiomeyer.academy/playbooks/ai-portfolio-fuer-den-job) [71. Proving your AI skills credibly in CV and interview](https://studiomeyer.academy/playbooks/ai-skills-belegen-lebenslauf-interview) [72. Effort levels in Claude Code, when low is enough and when you need max](https://studiomeyer.academy/playbooks/effort-level-in-claude-code-einstellen) [73. From Academy skill to your first paid AI gig](https://studiomeyer.academy/playbooks/erster-bezahlter-ki-auftrag) [74. Fact-checking an AI answer: 10 steps against wrong information](https://studiomeyer.academy/playbooks/ki-antwort-faktenchecken) [75. AI images for your brand, from first prompt to finished set](https://studiomeyer.academy/playbooks/ki-bilder-fuer-deine-marke) [76. AI for freelancers, writing quotes and client emails in half the time](https://studiomeyer.academy/playbooks/ki-fuer-selbststaendige-angebote-und-mails) [77. Spotting and correctly labelling AI content](https://studiomeyer.academy/playbooks/ki-inhalte-erkennen-und-kennzeichnen) [78. AI meeting notes that are actually usable](https://studiomeyer.academy/playbooks/ki-notizen-fuer-meetings) [79. Local AI on your own machine, so your data never leaves the house](https://studiomeyer.academy/playbooks/lokale-ki-auf-dem-eigenen-rechner) [80. Understanding the three MCP primitives. Tools, Resources and Prompts](https://studiomeyer.academy/playbooks/mcp-primitives-tools-resources-prompts) [81. Reliable JSON from any AI, so your automation doesn't break](https://studiomeyer.academy/playbooks/verlaessliches-json-aus-ai) [82. What AI tools really cost, and where the hidden bills hide](https://studiomeyer.academy/playbooks/was-kostet-ki-wirklich) [83. Understanding prompt injection, the three traps when your AI assistant reads foreign text](https://studiomeyer.academy/playbooks/prompt-injection-erkennen) [84. Protecting yourself from AI fraud, fake calls, phishing and bogus job offers](https://studiomeyer.academy/playbooks/dich-vor-ki-betrug-schuetzen) [85. Opus 5 migration, when thinking becomes the default](https://studiomeyer.academy/playbooks/opus-5-migration) [86. The AI policy for small teams, on a single page](https://studiomeyer.academy/playbooks/ki-richtlinie-fuer-kleine-teams) [87. Stopping agents that drift off course](https://studiomeyer.academy/playbooks/agenten-die-abdriften-stoppen) [88. Seeing what your agent actually did, tracing in 10 steps with OpenTelemetry](https://studiomeyer.academy/playbooks/agent-tracing-mit-opentelemetry) [89. Having AI summarize long documents without it inventing things](https://studiomeyer.academy/playbooks/lange-dokumente-sicher-zusammenfassen) [90. Vetting third-party MCP servers safely before you install them](https://studiomeyer.academy/playbooks/fremde-mcp-server-sicher-pruefen) [91. AI as a learning coach: teaching yourself a new field for a career change](https://studiomeyer.academy/playbooks/ki-lern-coach-berufswechsel) [92. The AI operator job: what do you actually do?](https://studiomeyer.academy/playbooks/berufsbild-ai-operator) [93. Using AI without losing your own edge](https://studiomeyer.academy/playbooks/ki-nutzen-ohne-selbst-zu-verlernen) [94. Why your screenshot shrinks, and how to control it](https://studiomeyer.academy/playbooks/bilder-und-screenshots-an-die-ki-geben) [95. Framing a deep research brief so the report is actually worth something](https://studiomeyer.academy/playbooks/deep-research-auftrag-formulieren) [96. Analysing numbers and tables with AI without ending up with nonsense](https://studiomeyer.academy/playbooks/zahlen-und-tabellen-mit-ki-auswerten) [97. Reading AI benchmarks without being taken for a ride](https://studiomeyer.academy/playbooks/ki-benchmarks-richtig-lesen) [98. AI as a sparring partner, better decisions instead of polite agreement](https://studiomeyer.academy/playbooks/ki-als-sparringspartner-fuer-entscheidungen) [99. Learning a new skill with AI, the honest way](https://studiomeyer.academy/playbooks/mit-ki-neue-faehigkeit-lernen) [100. Changing your MCP server without breaking your users](https://studiomeyer.academy/playbooks/mcp-server-aendern-ohne-nutzer-zu-brechen) [101. Your first local AI model in 30 minutes](https://studiomeyer.academy/playbooks/erstes-lokales-modell-in-30-minuten) [102. Which local model fits your hardware](https://studiomeyer.academy/playbooks/welches-lokale-modell-passt-zu-deiner-hardware) [103. Local AI and the GDPR, what it really solves and what it does not](https://studiomeyer.academy/playbooks/lokale-ki-und-die-dsgvo) [104. MCP with local models, tools without the cloud](https://studiomeyer.academy/playbooks/mcp-mit-lokalen-modellen) [105. Local or cloud, the honest arithmetic](https://studiomeyer.academy/playbooks/lokal-oder-cloud-die-ehrliche-rechnung) [106. When a stranger's repo configures your AI. The ChainDrop case](https://studiomeyer.academy/playbooks/agent-konfiguration-als-angriffsweg) [107. Transcribing conversations offline, without them leaving the building](https://studiomeyer.academy/playbooks/gespraeche-offline-transkribieren) [108. Connecting n8n to a local model](https://studiomeyer.academy/playbooks/n8n-mit-lokalem-modell-verbinden) [109. Reading documents offline when the scan must not be uploaded](https://studiomeyer.academy/playbooks/dokumente-offline-auslesen) [→ Zur Academy](https://studiomeyer.academy/levels/1)

## Sitemap

Public pages of this site as Markdown: [sitemap](https://studiomeyer.academy/sitemap.md). Curated entry point: [llms.txt](https://studiomeyer.academy/llms.txt), full text: [llms-full.txt](https://studiomeyer.academy/llms-full.txt).