MCP Clients

Ein MCP-Client ist die Anwendung, in der Nutzer mit einem Sprachmodell arbeiten (Chat-Fenster oder Coding-Editor) und die dabei externe Werkzeug-Server anbindet. MCP steht für Model Context Protocol, einen von Anthropic Ende 2024 veröffentlichten offenen Standard für die Verbindung zwischen Sprachmodell und externen Datenquellen oder Werkzeugen. Der Client startet die Server, gleicht deren Fähigkeiten mit dem Modell ab und reicht Aufrufe zwischen Modell und Server durch. Bekannte Beispiele sind Claude Desktop, Cursor, Continue, Zed sowie MCP-fähige Erweiterungen für VS Code und JetBrains-IDEs.

Was ist ein MCP-Client?

Das Model Context Protocol (MCP) wurde Ende 2024 von Anthropic als offener Standard veröffentlicht und beschreibt drei Rollen: Host (die Anwendung, in der der Mensch arbeitet, etwa Chat-Fenster oder Coding-Editor), Client (die Vermittlungs-Instanz innerhalb des Hosts) und Server (die Werkzeug- oder Datenquellen-Seite). Die [offizielle Spezifikation](https://modelcontextprotocol.io/docs/develop/build-client) definiert den Host als Programm, in dem der Nutzer arbeitet. Innerhalb des Hosts läuft pro angebundenem Server eine eigene Client-Instanz, die die Verbindung zu genau einem Server hält. Im Sprachgebrauch werden „MCP-Client" und „Host-Anwendung" häufig synonym verwendet; für die Definition ist beides zulässig, weil die Client-Instanzen technisch innerhalb des Hosts liegen.

Die Kernaufgaben eines MCP-Clients lassen sich in sechs Schritten fassen. Erstens startet der Client den Server-Prozess (Transport-Variante stdio, ein Subprozess pro Server) oder öffnet eine Netzwerkverbindung (HTTP mit Server-Sent Events oder Streamable HTTP für Remote-Server). Zweitens führt der Client die Capability-Negotiation über den Initialize-Handshake und handelt Protokoll-Version und Feature-Set mit dem Server aus. Drittens ruft der Client die Liste der angebotenen Werkzeuge, Ressourcen und Prompts ab und spielt sie dem Sprachmodell als Tool-Definitionen aus. Viertens leitet er Werkzeug-Aufrufe des Modells an den Server weiter und schickt die Ergebnisse zurück in den Kontext. Fünftens holt er User-Confirmations ein (Bestätigung pro Aufruf oder pro Session, je nach Konfiguration). Sechstens rendert er Ressource-Inhalte, bevor sie in den Modell-Kontext eingebettet werden.

Die 2026 produktiv MCP-fähige Host-Landschaft umfasst Claude Desktop (Anthropic-eigener Host, MCP-first seit der Ankündigung Ende 2024), Cursor (Coding-IDE mit MCP-Support seit 2025), Continue (Open-Source-IDE-Erweiterung), Zed (Editor mit MCP-Integration), VS Code über MCP-fähige Erweiterungen wie Continue und Cline sowie den JetBrains AI Assistant. Die Konfiguration erfolgt in host-spezifischen Dateien, typischerweise claude_desktop_config.json bei Claude Desktop oder mcp.json bei Cursor.

Die Rolle existiert, weil ohne standardisierte Client-Seite jede Chat- oder IDE-Anwendung eigene Adapter für jeden externen Datenquellen- oder Werkzeug-Server bauen müsste. Der MCP-Client kapselt die Anbindung als Protokoll und macht Server-Anbieter und Host-Anwendung unabhängig voneinander tauschbar.

Abgrenzung zu MCP-Server, A2A-Client und Function Calling

Der Begriff wird häufig mit angrenzenden Rollen im agentischen Stack vermischt. Die Tabelle klärt die Zuordnungen.

Der MCP-Server ist die spiegelbildliche Rolle: Er stellt die Fähigkeiten bereit, der MCP-Client konsumiert sie im Kontext einer Host-Anwendung. Server und Client sind komplementär, ihre Rollen aber unterschiedlich. Ein A2A-Client ist keine MCP-Rolle: Er kommuniziert horizontal zwischen zwei Agenten über das Agent2Agent-Protokoll, während der MCP-Client vertikal zwischen einem Modell und dessen Werkzeugen vermittelt. Beide Protokolle ergänzen sich; ein A2A-Remote-Agent nutzt intern häufig einen MCP-Client, um an seine Werkzeuge zu kommen. Function Calling schließlich beschreibt die Anbieter-spezifische Modell-API (OpenAI, Google) beziehungsweise Tool Use bei Anthropic und liegt eine Ebene tiefer als der MCP-Client: Der Client übersetzt die vom Server angebotenen Werkzeuge in Function-Call-Definitionen für das Modell, der Function-Call-Mechanismus selbst bleibt in der Modell-API. Agent-Frameworks wie LangGraph oder CrewAI können einen MCP-Client als Baustein nutzen, sind aber selbst keine MCP-Clients.

Beispiel: Wissensarbeiter mit zwei MCP-Servern in Claude Desktop

Ein Wissensarbeiter startet Claude Desktop. Die lokale claude_desktop_config.json enthält zwei Einträge: einen internen Wissens-Server auf einem Lakehouse und einen GitHub-Server. Beim Anwendungsstart erzeugt Claude Desktop pro Eintrag eine MCP-Client-Instanz. Jede Instanz startet den zugehörigen Server-Prozess über stdio (bei lokalen Servern) oder öffnet eine HTTPS-Verbindung (bei Remote-Servern), führt den Initialize-Handshake und lädt die Werkzeug-Liste des Servers.

Stellt der Nutzer die Frage nach der letzten Compliance-Änderung, entscheidet das Modell auf Basis der geladenen Tool-Definitionen, das Werkzeug search_documents des Wissens-Servers aufzurufen. Der zuständige MCP-Client leitet den Aufruf mit den Argumenten an den Server, empfängt das Ergebnis-Artefakt, holt bei Bedarf eine Nutzer-Bestätigung ein und übergibt den sanitisierten Inhalt an das Modell für die finale Antwort. Ein späterer Wechsel des Wissens-Servers ändert an dieser Kette nur den Eintrag in der Client-Konfiguration; Host und Modell bleiben unverändert. Diese Trennung ist der zentrale Zweck des Standards: Server-Anbieter und Host-Anwendung entwickeln unabhängig voneinander weiter, solange beide Seiten das Protokoll implementieren.