Kapitel 2 — Das Model Context Protocol (MCP) enthüllt

Zweiter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Darin: wir bauen das mentale Modell — drei Rollen, ein JSON-RPC-Wireformat, eine dynamische Discovery-Fläche und ein Session-Lebenszyklus — sorgfältig genug, dass der Rest des Buchs darauf stehen kann.

Warum dieses Kapitel existiert

Kapitel 1 hat das Problem benannt. Dieses Kapitel baut das mentale Modell der Antwort. MCP lässt sich in einem Satz zusammenfassen und in einem Absatz missverstehen, deshalb nimmt sich das Kapitel Zeit: was das Protokoll auf der Wireebene ist, was die drei Rollen bedeuten und was jede besitzt, wie es sich in den Fällen, die in der Produktion wirklich zählen, von einer REST-API unterscheidet und was während einer Session von Verbindung bis Teardown passiert. Das Ziel ist, dass du am Ende — vor dem nächsten Kapitel — vorhersagen kannst, was ein Server-Primitiv sein muss, was ein Client-Primitiv sein muss und warum MCP die Struktur verdient, die es hat.

2.1 Was MCP ist und was „USB-C für KI" tatsächlich bedeutet

Das Model Context Protocol ist eine offene Spezifikation dafür, wie LLM-Anwendungen externe Fähigkeiten entdecken, beschreiben und aufrufen. Am Draht ist es JSON-RPC 2.0 über einen aus einer kleinen Auswahl von Transports. Architektonisch ist es der Vertrag, mit dem ein Host mit jedem konformen Server arbeiten kann, ohne maßgeschneiderten Integrationscode. Ein Werkzeug, das einmal gegen das Protokoll gebaut wurde, funktioniert mit jedem Host, der es spricht. Ein Host, der einmal gegen das Protokoll gebaut wurde, kann jedes Werkzeug nutzen, das es spricht.

Das Kürzel, das hängengeblieben ist, lautet „USB-C für KI". Die strukturelle Form spiegelt USB-C wirklich — ein einziger Verbindungsstandard, der zwischen einer offenen Population von Geräten und einer offenen Population von Hosts vermittelt. Die Grenzen der Metapher gehören dazu: USB-C standardisiert einen Stecker plus einen Stack darüber; MCP standardisiert nur das Protokoll. USB-C läuft auf elektrischer Zeitskala mit hardwaregestütztem Framing; MCP läuft auf Netzwerkzeitskala mit softwaredefiniertem Framing, weshalb MCP flexibler sein darf, aber auch abgebrochene Verbindungen und langsame Gegenstellen behandeln muss, die USB-C so nicht kennt.

Ein engerer Vergleich für Entwickler ist LSP. Das Language Server Protocol definierte ein Protokoll, das jeder Editor und jeder Sprachserver sprechen konnte; MCP definiert eines, das jeder LLM-Host und jeder Capability-Anbieter sprechen kann. Die Form des Gewinns ist identisch — viele-zu-viele kollabiert durch ein gemeinsames Protokoll zu etwas, das additiv skaliert. Die Wahl, MCP auf JSON-RPC 2.0 aufzubauen statt ein neues Wireformat zu erfinden, war bewusst: JSON-RPC ist klein, reif, sprachenagnostisch und unspektakulär. Die interessanten architektonischen Entscheidungen liegen nicht auf der Wireebene. Sie liegen darin, wie Hosts, Clients und Server die Verantwortung aufteilen.

2.2 Hosts, Clients und Server — was jede Rolle besitzt

MCP definiert drei Rollen, und das Erste, was du verstehen solltest, ist, dass „Client" und „Server" hier nicht das bedeuten, was sie anderswo oft bedeuten. Ein Server stellt Capabilities bereit — Tools, Resources, Prompts. Ein Client ist eine einzelne protokollsprechende Verbindung zu einem Server, verwaltet innerhalb einer größeren Anwendung. Die größere Anwendung ist der Host. Der Host besitzt das Modell, die Session der Nutzerin und die Policy darüber, was das Modell tun darf. Die Server besitzen ihre Capability-Flächen. Die Clients sind die Drähte dazwischen, einer pro Server.

Die Aufteilung zählt, weil jede Rolle eine andere Verantwortung und eine andere Vertrauenshaltung hat. Der Host ist die Vertrauensgrenze, die aus Nutzersicht zählt; alles andere ist etwas, das der Host hereinzulassen entschieden hat. Ein Host, der mit fünf Servern spricht, hat fünf Clients in sich, jeder mit eigenem Session-Zustand, eigenen Subskriptionen, eigener Sicht darauf, welche Capabilities ausgehandelt wurden. Stürzt ein Server ab, stürzt der entsprechende Client ab; die anderen Clients laufen weiter; der Host bleibt am Leben. Die Clients sind Pro-Verbindungs-Isolatoren, die verhindern, dass ein schlechter Server die ganze Session vergiftet.

Es gibt auch ein Sicherheitsargument für die Aufteilung. Jeder Server ist, im Minimum, von jemand anderem geschriebener Code. Der Client vermittelt alles, was der Server tun kann und was den Host betrifft — Notifications, Elicitations, Sampling-Anfragen, veröffentlichte Resources — und dort gehört Pro-Server-Policy hin. Hosts, Clients und Server sind logische Rollen, nicht streng physische: lokal ist der Server oft ein Subprozess über stdio; remote ist es ein Dienst über einen HTTP-basierten Transport. Das Protokoll kümmert das nicht; die Rollengrenzen schon.

2.3 MCP gegenüber REST — was dynamische Discovery und semantische Beschreibungen einbringen

Die berechtigte Frage lautet „ist das nicht einfach REST?" Die Unterschiede sind nicht kosmetisch. Die folgenreichsten sind dynamische Discovery, semantische Beschreibungen für ein LLM und ein bidirektionales Nachrichtenmodell.

Eine REST-API veröffentlicht Endpunkte in Dokumentation für menschliche Entwickler. Welche Endpunkte ein Client nutzt, ist zur Build-Zeit fest; neue Endpunkte erfordern Re-Deploys. MCP dreht das um. Beim Sessionstart fragt der Client „was bietest du?" und der Server antwortet mit einem typisierten Katalog — Schemata, Beschreibungen, Metadaten — den der Host programmatisch nutzt. Fügt der Server später ein Tool hinzu, aktualisiert eine listChanged-Notification den Client mitten in der Session ohne Neustart. Der Server ist die autoritative Quelle der Wahrheit über seine eigenen Capabilities; die Beschreibung kann nicht von der Implementierung abdriften, weil es keine client-seitige Kopie gibt, von der sie abdriften könnte.

Semantische Beschreibungen sind der zweite Unterschied. Die Doku eines REST-Endpunkts ist für eine Entwicklerin geschrieben, die liest und entscheidet. Die Beschreibung eines MCP-Tools ist für ein LLM geschrieben, das sie als Teil seines Prompts liest und autonom entscheidet. Eine Beschreibung wie „POST an /users/:id/orders" ist für ein LLM nutzlos — es muss wissen, welche konzeptionelle Operation das Tool ausführt, wann es bevorzugt werden sollte, welche Nebenwirkungen es hat und was seine Inputs in fachlichen Begriffen bedeuten. Die Übersetzungsarbeit von der API ins LLM-Lesbare wird einmal in den Server geschoben, wo die Menschen sie pflegen, die der Capability am nächsten stehen.

Der dritte Unterschied ist Bidirektionalität. REST ist Request-Response; die Verbindung schließt. MCP ist bidirektional von Geburt. Der Server kann jederzeit Notifications senden, kann Sampling-Anfragen an den Client zurückinitiieren, kann Antworten von der Nutzerin mitten im Ablauf erheben. Nichts davon ist über REST technisch unmöglich. Alles davon ist dort umständlich. In MCP ist es Teil des Standards.

2.4 Capability-Verhandlung und der Session-Lebenszyklus

Eine Session beginnt, wenn der Client einen Transport öffnet und einen initialize-Request mit seiner Protokollversion und seinen Capabilities sendet. Der Server antwortet mit eigenen Capabilities — bietet er Tools, bietet er Resources, bietet er Subskriptionen, unterstützt er fortgeschrittene Features. Der Client bestätigt mit einer initialized-Notification. Die Session ist dann im Betriebszustand, und die verfügbaren Nachrichtentypen sind genau die Teilmenge, auf die sich beide Seiten geeinigt haben.

Diese Verhandlung erlaubt es, dass ein Client und ein Server mit unterschiedlichen Feature-Sets produktiv koexistieren. Hier wird auch Versionierung gehandhabt: Der Server wählt die höchste Version, die beide Seiten unterstützen. Operativ hat der Lebenszyklus Folgen. Initialisierung ist nicht gratis — ein Round Trip, bei Remote-Servern plus Verbindungsaufbau. Langlebige Sessions sind das bevorzugte Muster; Capability-Änderungen fließen als Notifications statt als Reconnect. Hosts, die das respektieren — Sessions warm halten, im Hintergrund nach Netzaussetzern reconnecten — erreichen messbar bessere Latenz. Hosts, die für jeden Request abreißen und neu initialisieren, arbeiten korrekt, aber ineffizient.

Eine Asymmetrie, die festzuhalten lohnt: Requests haben Antworten; Notifications nicht. List-Changed-Events sind Notifications, und ein Client, der eine verpasst, muss bereit sein, seine Sicht durch einen erneuten list_tools-Aufruf zu erneuern. Die Notification ist eine Optimierung, keine Garantie. Robuster MCP-Code behandelt sie als Hinweis, nicht als Protokoll.

Was Kapitel 2 vorbereitet

Du hast jetzt das mentale Modell. MCP ist ein JSON-RPC-Protokoll mit drei Rollen, mit dynamischer Discovery, die den Server für seine eigenen Capabilities autoritativ macht, mit Beschreibungen für ein LLM-Publikum, mit einem bidirektionalen Nachrichtenmodell mit Notifications und server-initiierten Requests und mit einem Lebenszyklus, der mit expliziter Capability-Verhandlung beginnt und innerhalb der ausgehandelten Teilmenge operiert. Das ist genug Gerüst, um konkret darüber zu reden, was Server und Clients jeweils freigeben — was die nächsten beiden Kapitel tun.

Als Nächstes — Kapitel 3: Server-Primitives — Resources, Prompts, Tools. Die drei Nomen, die ein Server anbieten kann, warum jedes zählt und die Disziplin, das richtige Primitiv zu wählen, statt eines in das Territorium eines anderen zu überladen.