Fortgeschritten 14 Min.MCP

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.

Von Mohamed Meguedmi·Aktualisierung 2026-08-27·Unter Windows, macOS und Linux getestet

#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.

i
MCP ≠ Funktionenaufruf
MCP ist keine neue LLM-API. Es ist eine Schicht über der Tool-Nutzung: Das Modell verwendet weiterhin klassisches Function Calling; MCP standardisiert lediglich das Auffinden und die Ausführung von Tools auf der Serverseite.

#Warum MCP an Ollama anschließen?

Das Kit „Copilote Local“

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.
!
MCP ermöglicht Aktionen
Ein Dateisystem- oder Shell-Server ermöglicht es dem Modell, Dateien zu schreiben oder Befehle auszuführen. Begrenzen Sie stets den Zugriffsbereich (Stammverzeichnis, Datenbank mit reinem Lesezugriff) und prüfen Sie sensible Aufrufe vor der Ausführung.

#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-*).
Terminal — Umgebung vorbereiten
# Vérifier Ollama
ollama --version
curl http://localhost:11434/api/tags

# Tirer un modèle capable de tool-use
ollama pull qwen3.5:9b

# Environnement Python
python -m venv .venv
source .venv/bin/activate
pip install mcp ollama

#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 Tool-Nutzung vor dem Programmieren testen
Bevor Sie MCP anbinden, prüfen Sie mit einem einfachen Test über /api/chat und einem Dummy-Tool, ob das Modell tatsächlich Tools aufruft. Wenn das Modell Text statt eines tool_call zurückgibt, wechseln Sie das Modell, statt die Bridge zu debuggen.

#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.

  1. 01
    1. Einen MCP-Server starten
    Ein 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.
  2. 02
    2. Tools auflisten und konvertieren
    session.list_tools() gibt die MCP-Tools zurück. Diese werden in das von Ollamas /api/chat erwartete „tools“-Format umgewandelt (name, description, inputSchema → parameters).
  3. 03
    3. Werkzeugaufrufschleife
    Man 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.
  4. 04
    4. Antwort senden
    Wenn das Modell kein Tool mehr anfordert, ist seine letzte Textantwort das endgültige Ergebnis, das dem Benutzer präsentiert wird.
bridge.py — MCP + Ollama
import asyncio
import ollama
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

MODEL = "qwen3.5:9b"

# Serveur MCP filesystem limité au dossier ./workspace
server = StdioServerParameters(
    command="npx",
    args=["-y", "@modelcontextprotocol/server-filesystem", "./workspace"],
)

def to_ollama_tools(mcp_tools):
    return [{
        "type": "function",
        "function": {
            "name": t.name,
            "description": t.description,
            "parameters": t.inputSchema,
        },
    } for t in mcp_tools]

async def run(prompt: str):
    async with stdio_client(server) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            tools = (await session.list_tools()).tools
            ollama_tools = to_ollama_tools(tools)
            messages = [{"role": "user", "content": prompt}]

            while True:
                resp = ollama.chat(
                    model=MODEL,
                    messages=messages,
                    tools=ollama_tools,
                )
                msg = resp["message"]
                messages.append(msg)

                if not msg.get("tool_calls"):
                    return msg["content"]

                for call in msg["tool_calls"]:
                    fn = call["function"]
                    result = await session.call_tool(
                        fn["name"], fn.get("arguments", {}),
                    )
                    text = "".join(c.text for c in result.content
                                    if getattr(c, "text", None))
                    messages.append({
                        "role": "tool",
                        "content": text,
                    })

if __name__ == "__main__":
    print(asyncio.run(run("Liste les fichiers du dossier et résume leur contenu.")))
i
Schutz vor Endlosschleifen
Fügen Sie im Produktivbetrieb einen Iterationszähler (max_iterations) hinzu, damit ein Modell, das immer wieder dasselbe Tool aufruft, nicht endlos weiterläuft. Etwa zehn Iterationen reichen für die meisten Aufgaben völlig aus.

#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.
Multi-Server-Konfiguration (Auszug)
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./workspace"]
    },
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "./data/app.db"]
    }
  }
}

#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.
→
Die passende Größenklasse im Jahr 2026: Qwen 3.5 9B
Für einen zuverlässigen lokalen MCP-Agenten sollten Sie Qwen 3.5 9B in Q4_K_M anpeilen (ca. 6,6 GB VRAM, auf einer RTX 3060 mit 12 GB oder einer 4070 lauffähig). Bei Modellen unter 4B sollten Sie den Agenten auf klar eingegrenzte Aufgaben mit nur einem Werkzeug beschränken.

#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.
Hat Ihnen dieser Guide geholfen?

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.