Das Model Context Protocol: USB-C für Tools
Anthropic hat das Model Context Protocol als offenen Standard veröffentlicht: JSON-RPC 2.0 mit Servern, Clients, Tools, Ressourcen und Prompts. Wir erklären die Architektur, den stdio-Transport und die bewussten Lücken des Protokolls — und warum eine einzige Integrationsfläche die heutigen N-mal-M-Spezialkonnektoren ersetzen kann. Ein Überblick zum Start am 25. November 2024.
Eine Schnittstelle statt N mal M
Jeder KI-Assistent, der mehr können soll als Konversation, braucht Zugriff auf externe Systeme: Ticketdatenbanken, Wikis, Repositories, interne APIs. Jede dieser Verbindungen ist heute eine Einzelanfertigung. Eine Anwendung, die mit GitHub, Postgres und Slack spricht, trägt drei Spezialkonnektoren. Eine zweite Anwendung braucht drei weitere. Bei M Anwendungen und N Systemen pflegt die Branche M mal N Integrationen — jede mit eigener Authentifizierung, eigener Fehlerbehandlung und eigenem Update-Zyklus.
Ein gemeinsames Protokoll macht aus dem Produkt eine Summe. Jede Anwendung implementiert das Protokoll einmal als Client, jedes System stellt es einmal als Server bereit; aus M mal N wird M plus N. Die Analogie im Titel ist USB-C: ein genormter Port statt eines proprietären Kabels pro Peripheriegerät. Am 25. November 2024 hat Anthropic genau diesen Port für KI-Tooling veröffentlicht.
Was Anthropic am 25. November veröffentlicht hat
Die Veröffentlichung unter dem Namen Model Context Protocol (MCP) besteht aus drei Teilen: einer offenen Spezifikation mit SDKs für TypeScript und Python, lokaler MCP-Server-Unterstützung in den Claude-Desktop-Apps und einem Open-Source-Repository mit Referenzservern. Vorgefertigte Server existieren für Google Drive, Slack, GitHub, Git, Postgres und Puppeteer. Die Spezifikation trägt die Revision 2024-11-05 und wird öffentlich auf GitHub entwickelt.
Technisch ist MCP JSON-RPC 2.0 über eine zustandsbehaftete Verbindung. Client und Server verhandeln Fähigkeiten in einem Initialize-Handshake: Der Client nennt Protokollversion und Features wie Sampling, der Server antwortet mit seinem Angebot — Tools, Ressourcen, Prompts, Logging. Nichts am Protokoll ist Claude-spezifisch; jede Anwendung kann beide Seiten implementieren.
Hosts Clients und Server
Die Spezifikation benennt drei Rollen. Ein Host ist eine LLM-Anwendung, die Verbindungen initiiert — Claude Desktop ist das erste ausgelieferte Beispiel. Ein Client ist das Verbindungsobjekt im Host; er hält genau eine Verbindung zu genau einem Server. Ein Server ist ein meist kleines Programm, das Kontext und Fähigkeiten bereitstellt. Ein Host kann viele Clients parallel betreiben, einen pro Server.
Die Verbindungen sind bidirektional. Server beantworten Datenanfragen und führen Tools aus, können aber auch in Gegenrichtung Arbeit anfordern: Über das Sampling-Feature bittet ein Server den Client um eine LLM-Vervollständigung. Die Spezifikation verlangt, dass Nutzer solche Anfragen explizit freigeben. Diese Umkehrung unterscheidet MCP von einer gewöhnlichen Plugin-API.
Tools Ressourcen und Prompts
Ein Server bietet bis zu drei Primitive an, und die Spezifikation legt präzise fest, wer jeweils die Kontrolle hat. Tools sind modellgesteuert: Funktionen mit einem JSON-Schema als inputSchema, die das Modell über tools/list entdeckt und über tools/call aufruft. Ressourcen sind anwendungsgesteuert: Daten hinter URIs, die der Client als Kontext anhängt. Prompts sind nutzergesteuert: Vorlagen, die Sie bewusst aufrufen, etwa als Slash-Kommandos.
Diese Trennung ist die Designentscheidung, die sich zu kopieren lohnt. Ein Tool-Aufruf ist eine Entscheidung des Modells, ein Ressourcen-Anhang eine Entscheidung der Client-Software, ein Prompt-Aufruf eine Entscheidung des Menschen. Systeme, die diese drei Linien verwischen, enden entweder bei unbrauchbaren Freigabedialogen oder bei Modellen, die ohne Aufsicht handeln.
Stdio als Standard-Transport
Die Revision 2024-11-05 definiert zwei Transporte. Der primäre ist stdio: Der Client startet den Server als Subprozess und tauscht zeilengetrennte JSON-RPC-Nachrichten über stdin und stdout aus; stderr ist für Logging reserviert. Die Spezifikation empfiehlt, dass Clients stdio wann immer möglich unterstützen. Der zweite Transport, HTTP mit Server-Sent Events, zielt auf Server, die als eigenständige Prozesse mehrere Clients bedienen.
Stdio hat praktische Konsequenzen. Server laufen auf Ihrem Rechner; Zugangsdaten für das Zielsystem verlassen ihn nicht, und es gibt keinen Netzwerk-Endpunkt abzusichern. Es bedeutet aber auch: MCP ist heute ein lokales Protokoll. Anthropic hat Entwickler-Toolkits für entfernte Produktionsserver angekündigt, aber noch nicht ausgeliefert.
Was MCP nicht löst
MCP standardisiert die Verkabelung, nicht die Intelligenz. Ob ein Modell das richtige Tool mit den richtigen Argumenten wählt, bleibt eine Eigenschaft des Modells und der Tool-Beschreibungen — das Protokoll garantiert nur, dass der Aufruf in definiertem Format transportiert und beantwortet wird. Schlecht beschriebene Tools bleiben schlecht genutzt, über jedes Protokoll.
Weitere Lücken sind explizit. Die Spezifikation definiert kein Authentifizierungs- oder Autorisierungsschema gegenüber dem Zielsystem; jeder Server verwaltet seine Zugangsdaten selbst, typischerweise über Umgebungsvariablen. Es gibt keine Registry: Server zu finden heißt, ein GitHub-Repository zu lesen. Und das N-mal-M-Argument trägt nur, wenn M über eins hinauswächst — zum Start sind Anthropics eigene Anwendungen die einzigen ausgelieferten Hosts.
Das frühe Ökosystem
Der Start ist nicht leer. Block und Apollo haben MCP bereits in ihre Systeme integriert; Zed, Replit, Codeium und Sourcegraph bauen Unterstützung in ihre Entwicklungswerkzeuge ein. Das Open-Source-Repository enthält Referenzserver über die sechs genannten hinaus, und Anthropic weist darauf hin, dass Claude 3.5 Sonnet neue Server-Implementierungen aus einer Beschreibung der Ziel-API heraus zuverlässig schreibt.
Der letzte Punkt ist ökonomisch entscheidend. Wenn das Anbinden eines internen Systems einen Nachmittag kostet statt eines Sprints, wird der Long Tail von Nischensystemen erreichbar. Wir bei Blue IT Systems haben eine Nur-Lese-Sicht auf eine interne Postgres-Datenbank noch in der Startwoche als stdio-Server verpackt; der Code passt in eine Datei.
| Primitiv | Kontrolle | Typisches Beispiel |
|---|---|---|
| Tools | Modell | Datenbankabfrage oder API-Aufruf |
| Ressourcen | Anwendung | Dateiinhalte oder ein Datenbankschema |
| Prompts | Nutzer | Wiederverwendbare Review-Vorlage als Slash-Kommando |
Ausblick aus der Startwoche
Unsere Prognose aus der Startwoche: MCPs Schicksal entscheidet sich bei den Hosts, nicht bei den Servern. Server sind billig zu schreiben; das Protokoll gewinnt in dem Moment, in dem eine zweite und dritte große Anwendung es als Client spricht. Das Language Server Protocol hat nach 2016 genau diesen Weg genommen — erst ein Editor, dann alle, und Sprach-Tooling hörte auf, ein M-mal-N-Problem zu sein.
Für 2025 erwarten wir drei Entwicklungen: einen gehärteten Remote-Transport mit echter Authentifizierungslösung, eine Form von Server-Registry und die Übernahme durch mindestens einen Modellanbieter außerhalb von Anthropic — die Spezifikation enthält nichts Claude-Spezifisches, das dem entgegenstünde. Bis dahin behandeln wir MCP-Server als Standardform neuer Integrationen: Im schlechtesten Fall bleibt ein dünner JSON-RPC-Wrapper, den wir ohnehin geschrieben hätten.