MCP und lokale LLMs: MCP-Server verbinden mit Ollama
Das Model Context Protocol (MCP) standardisiert, wie ein LLM externe Tools aufruft: zum Lesen von Dateien, für Webanfragen oder für den Zugriff auf eine Datenbank. Die Kombination von MCP und Ollama ermöglicht es, einen Agenten zu betreiben, der auf Ihrem Rechner Aktionen ausführen kann, ohne Ihre Daten jemals an eine Cloud-API zu senden. Dieser Leitfaden zeigt, wie Sie eine MCP-Ollama-Bridge in Python erstellen, welche lokalen Modelle den Einsatz von Tools tatsächlich unterstützen und wo die tatsächlichen Grenzen kleiner Modelle liegen.
#Was ist MCP und warum verändert es lokale Agenten?
MCP (Model Context Protocol) ist ein offenes Protokoll, das Anthropic Ende 2024 veröffentlicht hat. Sein Ziel: eine einheitliche Schnittstelle zwischen einem Sprachmodell und den Werkzeugen, die es nutzen kann. Statt für jede Datenquelle eine eigene Integration neu zu schreiben, stellt ein „MCP-Server“ Werkzeuge (tools), Ressourcen (resources) und Prompts in einem standardisierten Format bereit. Jeder kompatible Client – Claude Desktop, eine IDE oder Ihre eigene Bridge – kann sich dann damit verbinden.
Konkret stellt ein MCP-Server „filesystem“ Tools wie read_file, write_file oder list_directory bereit. Ein Server „sqlite“ stellt query oder list_tables bereit. Der LLM greift nie direkt auf den Datenträger zu: Er fordert einen Tool-Aufruf an, der Client führt ihn über den MCP-Server aus und gibt anschließend das Ergebnis an das Modell zurück. Diese Trennung zwischen Client und Server macht das Protokoll wiederverwendbar.
Bei lokalen Agenten geht es um zwei Dinge: das wachsende Ökosystem von MCP-Servern zu nutzen (es gibt bereits Dutzende) und zugleich dank Ollama die Inferenz zu 100 % auf Ihrem Rechner zu belassen. So erhalten Sie einen Agenten, der Ihre Dateien liest und Ihre Datenbanken abfragt, ohne dass auch nur ein Byte Ihr Netzwerk verlässt.
#Warum MCP an Ollama anschließen?
Dieser Guide führt Sie zum Modell. Das Kit führt Sie zum Copiloten, der in Ihrem Editor Code schreibt.
- Lebenslanger Online-Zugang
- PDF + Dateien
- Erstattung binnen 30 Tagen
Die meisten MCP-Demos verwenden ein Cloud-Modell (Claude, GPT). MCP lokal mit Ollama zu nutzen, verändert die Situation in drei Punkten: Vertraulichkeit (Ihre Dateien und SQL-Abfragen verlassen die Maschine nicht), Kosten (kein einziges Token wird in Rechnung gestellt, unabhängig von der Anzahl der Tool-Aufrufe) und Kontrolle (Sie wählen das Modell, die Quantisierung und die zugelassenen Server).
- Datenschutz
- Ein MCP-Dateisystemserver gibt dem Modell Zugriff auf Ihre Ordner. Bei lokaler Nutzung werden diese Inhalte niemals über einen Dritten geleitet.
- Kostenlos
- Agenten führen viele Aufruf- und Antwortrunden mit Tools durch. In der Cloud kostet jede Runde Tokens; mit Ollama ist das kostenlos.
- Hors-ligne
- Sobald das Modell heruntergeladen und die MCP-Server installiert sind, funktioniert das System ohne Internetverbindung (außer bei Web-Servern natürlich).
- Souveränität
- Sie bestimmen, welche Tools verfügbar sind, und können jeden Aufruf vor dem Ausführen auditieren.
#Voraussetzungen
- Ollama installiert
- Der Daemon lauscht standardmäßig auf http://localhost:11434. Überprüfen Sie dies mit „ollama --version“.
- Ein Modell mit Tool-Use-Fähigkeit
- Planen Sie mindestens Granite 4.2 8B ein, für zuverlässige Ergebnisse idealerweise Qwen 3.5 9B (siehe nächster Abschnitt).
- Python 3.10+
- Das offizielle MCP-SDK und der Ollama-Client sind in Python geschrieben.
- Node.js (optional)
- Viele Referenz-Server von MCP starten über npx (@modelcontextprotocol/server-*).
#Welche lokalen Modelle den Einsatz von Tools korrekt unterstützen
Nicht alle Modelle sind beim Function Calling gleich gut. Ein Modell, das das Format der Tools „kennt“, aber deren Argumente schlecht auswählt, macht den Agenten unbrauchbar. In der Praxis ermöglicht die Modellgeneration von 2026 (Qwen 3.5, Granite 4.2) bereits ab 8–9B Parametern einen zuverlässigen Tool-Einsatz, während man 2024 noch 14B anstreben musste. Hier sind die mit Ollama überprüfbaren Richtwerte und der jeweilige VRAM-Bedarf in Q4_K_M.
- Qwen 3.5 4B / 9B
- Hervorragende Unterstützung für die Nutzung von Tools. Das 9B-Modell (≈6,6 GB VRAM in Q4, 256k Kontext, Bildverarbeitung) bietet für einen lokalen Agenten den besten Kompromiss zwischen Zuverlässigkeit und Hardwarebedarf.
- Granite 4.2 8B
- Solide native Tool-Nutzung und sehr sparsamer Tokenverbrauch (≈5,3 GB in Q4, 128k Kontext). Hervorragender Einstieg mit 6–8 GB VRAM.
- Mistral Small 24B
- Zuverlässiges Function Calling und gute Französischkenntnisse (≈14 GB in Q4). Kommt gut mit etwas komplexeren Tool-Schemata zurecht.
- Qwen 3.6 35B-A3B
- Sehr zuverlässiges MoE-Modell bei Aufrufketten (≈23 GB in Q4, nur 3 Milliarden aktive Parameter, daher schnell). Nur für GPUs mit 24 GB Speicher wie die RTX 4090 vorsehen.
- 2–3B-Modelle
- Qwen 3.5 2B oder Granite 4.2 3B passen in ≈2 GB, aber die Zuverlässigkeit der Tool-Nutzung nimmt schnell ab, sobald mehrere Tools vorhanden sind. Für einen echten Agenten zu vermeiden.
#Die MCP-Ollama-Bridge in Python, Schritt für Schritt
Ollama ist kein nativer MCP-Client. Die Bridge dient als Vermittler: Sie startet einen MCP-Server, konvertiert dessen Tools in das von der Ollama-API erwartete Format, führt die Schleife für Tool-Aufrufe aus und gibt anschließend die Ergebnisse an das Modell zurück. Wir verwenden das offizielle MCP-SDK (Paket mcp) und den ollama-Client.
- 011. Einen MCP-Server startenEin MCP-Server wird über stdio als Unterprozess gestartet. Hier ist der offizielle Dateisystem-Server, der auf ein Arbeitsverzeichnis beschränkt ist, das als Argument übergeben wird.
- 022. Tools auflisten und konvertierensession.list_tools() gibt die MCP-Tools zurück. Diese werden in das von Ollamas /api/chat erwartete „tools“-Format umgewandelt (name, description, inputSchema → parameters).
- 033. WerkzeugaufrufschleifeMan sendet die Nutzernachricht und die Liste der Tools. Wenn das Modell mit einem tool_call antwortet, führt man diesen auf der MCP-Seite aus, speist das Ergebnis wieder ein und wiederholt die Schleife, bis eine endgültige Antwort vorliegt.
- 044. Antwort sendenWenn das Modell kein Tool mehr anfordert, ist seine letzte Textantwort das endgültige Ergebnis, das dem Benutzer präsentiert wird.
#Beispiele für nützliche MCP-Server für Selbsthosting
Der Vorteil von MCP liegt im Katalog einsatzbereiter Server. Hier sind diejenigen, die einem lokalen Agenten den größten Mehrwert bieten und sich alle über npx oder pip starten lassen.
- filesystem
- Lesen und Schreiben von Dateien innerhalb eines fest vorgegebenen Stammverzeichnisses. Am nützlichsten für einen Agenten, der mit Ihren Dokumenten arbeitet.
- sqlite / postgres
- Eine lokale Datenbank in natürlicher Sprache abfragen. Stellen Sie die Verbindung auf schreibgeschützten Zugriff um, um jegliche Änderungen zu vermeiden.
- fetch
- Eine Webseite abrufen und in Text umwandeln. Der einzige, der eine Internetverbindung erfordert.
- git
- Ein Repository erkunden: Log, Diff, Status. Nützlich für einen Code-Review- oder Dokumentationsagenten.
- memory
- Ein persistenter Schlüssel-Wert-Speicher, der dem Agenten über Sitzungen hinweg ein Langzeitgedächtnis verleiht.
#Die tatsächlichen Grenzen kleiner Modelle
Eine funktionierende Bridge garantiert noch keinen guten Agenten. Das schwache Glied bleibt das Modell. Bei den kleinsten Modellen (2–4B) treten regelmäßig mehrere Probleme auf, sobald die Aufgabe komplexer wird.
- Falsche Werkzeugwahl
- Das Modell ruft read_file auf, wenn es list_directory benötigt, oder erfindet einen Werkzeugnamen. Häufig bei Modellen unter 7B.
- Falsch formatierte Argumente
- Fehlerhafte relative Pfade, ungültiges JSON in den Argumenten. Ein guter Systemprompt und klare Werkzeugbeschreibungen reduzieren das Problem.
- Kurze Abfolgen
- Kleine Modelle haben bei mehr als 2–3 aufeinanderfolgenden Aufrufen Schwierigkeiten und verlieren das Ziel aus den Augen.
- Ergebnis ignorieren
- Das Modell ruft ein Tool auf und antwortet anschließend, ohne die erhaltenen Informationen zu berücksichtigen. Ein klassisches Symptom eines zu kleinen Modells.
#Fehlerbehebung
- Das Modell erzeugt keinen tool_call
- Prüfen Sie, ob das Modell die Verwendung von Tools unterstützt (Qwen 3.5, Granite 4.2) und ob der Parameter „tools“ tatsächlich an /api/chat übergeben wird. Ein nicht kompatibles Modell ignoriert die Tools.
- « connection refused » auf 11434
- Der Ollama-Daemon läuft nicht. Starten Sie ihn („ollama serve“) und testen Sie erneut mit „curl http://localhost:11434/api/tags“.
- Der MCP-Server startet nicht
- Testen Sie den Befehl npx / uvx allein in einem Terminal. Fehlt ein Node-Server, lässt sich das durch die Installation des betreffenden Pakets mit „npm i -g“ beheben.
- Endlosschleife bei Tool-Aufrufen
- Fügen Sie eine Iterationsgrenze in die Schleife hinzu und protokollieren Sie jeden tool_call, um zu erkennen, welches Modell denselben Aufruf wiederholt.
#Weiterführende Informationen
MCP baut auf den grundlegenden Bausteinen des lokalen Ökosystems auf. Diese ergänzenden Leitfäden auf dieser Website vervollständigen den vorliegenden Leitfaden:
- Einen lokalen KI-Agenten mit LangChain und Ollama erstellen
- Der klassische Agentenansatz mit LangChain, der MCP bei der Orchestrierung von Werkzeugen ergänzt.
- Ollama über die REST-API in Python integrieren
- Den OpenAI-kompatiblen Endpunkt und das Function Calling verstehen, die dem Bridge zugrunde liegen.
- Quantisierung wählen (Q4, Q5, Q8, FP16)
- Ein Qwen 3.5 9B mit Tool-Use in den Speicher Ihrer GPU einpassen, ohne die Zuverlässigkeit zu beeinträchtigen.
Haben Sie Feedback, einen Fehler entdeckt oder möchten Sie etwas präzisieren? Geben Sie uns Bescheid – so wird der Guide für alle besser.