Model Context Protocol (MCP)

Das Model Context Protocol (MCP) ist ein offener Standard von Anthropic, der beschreibt, wie ein KI-Chatbot oder Sprachmodell (LLM, Large Language Model) auf externe Werkzeuge und Datenquellen zugreift. Statt für jede Kombination aus Modell und Zielsystem einen eigenen Konnektor zu bauen, definiert MCP eine gemeinsame Schnittstelle zwischen zwei Rollen: dem MCP-Client (der Verbindungsschicht in der KI-Anwendung, etwa Claude Desktop oder ChatGPT) und dem MCP-Server (einem kleinen Programm vor dem eigentlichen System, etwa einer Datenbank, einem Dateisystem oder einer Cloud-Anwendung).

Was ist das Model Context Protocol?

Anthropic hat das Model Context Protocol im November 2024 als Open-Source-Standard veröffentlicht. Ausgangspunkt war das sogenannte N×M-Integrationsproblem: N Anbieter von Sprachmodellen (Anthropic, OpenAI, Google, Microsoft) mal M Zielsysteme (Postgres, GitHub, Slack, Salesforce, Filesystem) ergeben pro Kombination einen eigenen Konnektor, der einzeln entwickelt, dokumentiert und gepflegt werden muss. MCP standardisiert diese Verbindung auf 1×N Server und 1×M Clients. Jedes Zielsystem wird einmal als Server gekapselt und ist damit für jede MCP-fähige Anwendung nutzbar. Die Spezifikation liegt öffentlich auf [modelcontextprotocol.io](https://modelcontextprotocol.io/docs/getting-started/intro), die Referenz-SDKs (Software Development Kits für Python, TypeScript, Kotlin, Swift, C#) und Beispielserver liegen unter [modelcontextprotocol auf GitHub](https://github.com/modelcontextprotocol).

Ein MCP-Server exponiert drei Primitive über eine JSON-RPC-2.0-Schnittstelle: Tools (ausführbare Funktionen mit JSON-Schema-Input, etwa run_query oder create_ticket), Resources (lesbare Datenobjekte mit URI-Adresse, etwa postgres://db/table oder file:///docs/onboarding.md) und Prompts (parametrisierte Prompt-Templates für wiederkehrende Workflows). Bevor Methodenaufrufe stattfinden, tauschen Client und Server in einem Initialize-Handshake Protokoll-Version und Capabilities aus. Erst nach dieser Aushandlung folgen tools/list, tools/call, resources/list und resources/read.

Als Transport stehen zwei Optionen bereit: stdio für lokale Prozesse (typisch für IDE-Integrationen wie Claude Desktop oder Cursor) und Streamable HTTP für Remote-Server, seit März 2025 der offizielle Nachfolger des früheren HTTP+SSE-Transports. Für Remote-Server ist OAuth 2.1 mit Delegated Access im Standard beschrieben.

Der Standard hat sich innerhalb eines Jahres zum de-facto-Adressierungsmodell für die Tool-Anbindung an LLM-Anwendungen entwickelt. Neben Anthropic unterstützen OpenAI (ChatGPT, Deep Research), Google (Gemini, Agent Development Kit), Microsoft (Copilot Studio) und AWS MCP-Verbindungen in ihren Produkten; für Enterprise-Systeme wie Confluence, Jira, GitHub, ServiceNow, Snowflake, Salesforce und Databricks existieren offizielle MCP-Server der jeweiligen Anbieter.

Abgrenzung: MCP, A2A, Function Calling und die Rollen im Protokoll

Der Begriff wird häufig mit angrenzenden Konzepten und mit den eigenen Rollen im Protokoll vermischt.

MCP und A2A stehen auf zwei unterschiedlichen Achsen. MCP standardisiert die vertikale Achse zwischen einem Agenten und seinen Werkzeugen. A2A standardisiert die horizontale Achse zwischen mehreren eigenständigen Agenten. Beide Protokolle sind komplementär: Ein A2A-Remote-Agent nutzt intern typischerweise MCP-Server für den Zugriff auf CRM-Daten, Ticket-Systeme oder Dateien.

Function Calling liegt eine Ebene tiefer als MCP. Function Calling beschreibt das Wie auf Modell-Ebene: Wie formuliert ein Modell selbst einen strukturierten Tool-Aufruf (Name plus JSON-Argumente) in seinem Output. MCP beschreibt das Wo und Wonach auf System-Ebene: Welche Tools stehen zur Verfügung, wie werden sie beschrieben, wie werden sie ausgeführt. Ein MCP-Client bekommt vom Server die Tool-Definitionen, reicht sie an das Modell weiter, und das Modell entscheidet per Function Calling, welches Tool aufzurufen ist. Function Calling ist die Modell-API-Ebene unter MCP.

MCP-Client und MCP-Server sind Rollen innerhalb des Protokolls und bezeichnen die beiden Endpunkte einer MCP-Verbindung. Der Client ist die Verbindungsschicht im Host (etwa Claude Desktop, ChatGPT, eine IDE oder eine Agent-Runtime) und spricht mit genau einem Server. Der Server kapselt ein Zielsystem und veröffentlicht dessen Fähigkeiten. Verwechslungen entstehen, weil Consumer-Anwendungen wie Claude Desktop gleichzeitig Host- und Client-Komponenten enthalten und weil das Server-Ökosystem (Anbieter-Server für GitHub, Postgres, Slack) sichtbarer ist als das Protokoll dahinter.

Beispiel: Tool-Anbindung eines internen Wissens-Assistenten

Ein Data-Team stellt einen internen Wissens-Assistenten bereit, der SQL gegen ein Databricks-Warehouse ausführen und Antworten mit interner Dokumentation aus einem SharePoint-Store belegen soll. Statt für jede LLM-Anbindung (Claude, ChatGPT, Gemini) einen eigenen Konnektor zu bauen, schreibt das Team zwei MCP-Server: einen für Databricks SQL mit den Tools run_query und list_tables und der Resource catalog://<schema>, und einen für SharePoint mit dem Tool search_documents und der Resource sharepoint://<doc-id>.

Beide Server laufen als eigenständige, kleine Prozesse mit definierter Authentifizierung. Auf Anwendungsseite lässt sich der Assistent gegen jeden MCP-fähigen Client betreiben: Claude Desktop für Analysten, ein Custom-Agent im Data-Portal für Business-Nutzer, eine IDE-Integration für Data Engineers. Neue Zielsysteme werden über zusätzliche Server angeschlossen, nicht über neue Adapter je Client-Produkt. Vor MCP hätte dieselbe Kombination aus drei Clients und zwei Zielsystemen sechs individuelle Integrationen erfordert.