MCP-Grundlagen: Rollen, Nachrichten und Kontrolle

Das Problem ist die Zahl der Integrationskanten

Ein AI-Host soll Tickets lesen, Quellcode durchsuchen und Änderungen anstoßen. Ohne gemeinsamen Vertrag entsteht für jede Kombination aus Host und Backend ein eigener Adapter. Drei Hosts und vier Systeme ergeben bis zu zwölf Integrationskanten. MCP standardisiert nicht die Fach-API der Backends, sondern die Verbindung zwischen AI-Anwendung und bereitgestellten Fähigkeiten. Ein Server übersetzt sein Fachsystem einmal in MCP; mehrere Hosts können denselben veröffentlichten Vertrag verwenden.

Model Context Protocol — Ein offenes, auf JSON-RPC aufgebautes Protokoll, über das AI-Anwendungen Kontext und ausführbare Fähigkeiten von Servern entdecken und verwenden.

Der überraschende Punkt: MCP macht die Integration austauschbarer, aber nicht automatisch fachlich richtig. Ein gemeinsamer Umschlag ersetzt weder ein gutes Tool-Schema noch Autorisierung, Freigabe oder Fehlerbehandlung. Der Server bleibt für die Wirkung seines Backends verantwortlich; der Host bleibt für Modellzugriff, Nutzerinteraktion und Kontextauswahl verantwortlich. Genau diese Trennung verhindert, dass aus Protokollkompatibilität ein falsches Sicherheitsversprechen wird.

Host, Client und Server sind drei verschiedene Rollen

Die Architektur hat drei Rollen. Der Host ist die AI-Anwendung und Produktgrenze. Er koordiniert Modell, Nutzer, Kontext und Richtlinien. Ein Client ist die vom Host verwaltete Protokollkomponente für genau einen Server. Der Server veröffentlicht einen begrenzten Satz an Tools, Resources und Prompts. Ein Host kann mehrere Clients besitzen; jeder Client kommuniziert mit genau einem Server. Das ist kein Wortspiel: Die 1:1-Beziehung verhindert, dass ein einzelner Client still mehrere Vertrauensdomänen vermischt.

Host

Besitzt Modellintegration, Nutzeroberfläche, Consent und Kontextaggregation

Client

Spricht MCP mit genau einem Server und hält dessen Datenfluss getrennt

Server

Veröffentlicht fokussierte Fähigkeiten und setzt Backend-Regeln durch

In einer IDE ist die IDE der Host, nicht der MCP-Server. Der eingebaute Connector für das Ticketsystem ist der Client. Ein separater Prozess oder Remote-Dienst, der Ticketfunktionen veröffentlicht, ist der Server. Derselbe Prozess kann in einer anderen Architektur mehrere Rollen implementieren; die Verantwortungen bleiben trotzdem getrennt. Prüfe deshalb immer die logische Rolle im Datenfluss und nicht nur Prozessnamen oder Deployment-Boxen.

Der Host hält Gespräch und Server voneinander getrennt

Die MCP-Architektur legt die breite Sicht absichtlich in den Host. Ein Server soll weder den gesamten Gesprächsverlauf sehen noch in andere Server hineinblicken. Der Host wählt aus, welche Argumente, Resource-Inhalte oder Zwischenergebnisse an welchen Server gehen. Cross-Server-Orchestrierung ist damit Host-Verantwortung. Ein Git-Server erhält nicht automatisch das Ergebnis des Ticket-Servers, nur weil beide im selben Host aktiviert sind.

• Der Host entscheidet, welche Server überhaupt verbunden und dem Modell angeboten werden.
• Jeder Client kapselt den Verkehr mit genau einem Server.
• Der Server autorisiert jede angeforderte Wirkung in seinem eigenen Backend.
• Nur die für einen Aufruf nötigen Daten überschreiten die jeweilige Grenze.

Isolation kostet Kontextqualität: Ein eng versorgter Server kann weniger selbstständig kombinieren. Das ist gewollt. Zusätzlicher Kontext wird pro Aufgabe freigegeben, statt als dauerhafte Vollsicht zu gelten. Diese Grenze ist später entscheidend für Mandantentrennung, Prompt-Injection und Auditierbarkeit.

Auf dem Draht liegen JSON-RPC-Nachrichten

JSON-RPC 2.0 — Ein Nachrichtenformat für Methodenaufrufe. Eine Anfrage trägt jsonrpc, id, method und optional params; die Antwort trägt dieselbe id sowie entweder result oder error.

MCP definiert drei Grundformen. Ein Request startet eine Operation und besitzt eine eindeutige String- oder Integer-id. Eine Response korreliert über dieselbe id und enthält Erfolg oder Fehler. Eine Notification ist einseitig und hat deshalb keine id; der Empfänger antwortet nicht. Das unterscheidet eine Benachrichtigung von einem Request, dessen Antwort bloß ignoriert wird.

Request

Erwartet genau eine korrelierte Response; id ist Pflicht

Result Response

Enthält result und in modernem MCP einen resultType

Error Response

Enthält ganzzahligen code, message und optional data

Notification

Einweg-Nachricht ohne id und ohne Antwort

Der Transport ist davon getrennt. stdio und Streamable HTTP tragen dieselben MCP-Nachrichten, ändern aber Start, Adressierung und Netzgrenze. Ein HTTP-Status ersetzt die JSON-RPC-Korrelation nicht. Umgekehrt macht ein valides JSON-RPC-Dokument noch keinen validen MCP-Aufruf: Methodenname, Parameter, Metadaten und Fähigkeiten müssen ebenfalls zum Protokollvertrag passen.

Modernes MCP ist zustandslos pro Request

Seit Revision 2026-07-28 gibt es im modernen Core keinen initialize-Handshake und keine Protokollsession. Jeder Request ist selbstbeschreibend. Er trägt die Protokollversion und die für diesen Aufruf angebotenen Client-Fähigkeiten in params._meta. Der Server darf nicht aus einer früheren Nachricht, einer TCP-Verbindung oder einem langlebigen stdio-Prozess ableiten, welche Version, Identität oder Fähigkeiten gelten.

io.modelcontextprotocol/protocolVersion

Pflicht: Revision, nach deren Regeln dieser Request verarbeitet wird

io.modelcontextprotocol/clientCapabilities

Pflicht: Client-Fähigkeiten, die dieser Request verwenden darf

io.modelcontextprotocol/clientInfo

Empfohlen: selbst gemeldeter Name und Version für Anzeige und Diagnose

Fehlen Pflichtfelder, ist der Request ungültig. Benötigt die Verarbeitung eine nicht deklarierte Client-Fähigkeit, antwortet der Server mit MissingRequiredClientCapabilityError. clientInfo und das vom Server zurückgegebene serverInfo sind selbst gemeldet. Die Spezifikation warnt ausdrücklich davor, daraus Autorisierung oder sicherheitsrelevantes Verhalten abzuleiten. Ein Anzeigename ist kein Identitätsnachweis.

Der Preis des zustandslosen Kerns ist mehr Umschlag pro Request und explizites Zustandsdesign. Der Gewinn ist wesentlich: Ein Request kann auf jeder kompatiblen Instanz landen, Wiederverbindungen ändern seine Bedeutung nicht, und versteckter Connection-State fällt als Fehlerquelle weg.

Zustandslos bedeutet nicht, dass das Backend nichts speichern darf. Ein Warenkorb, eine Transaktion oder ein langer Arbeitsauftrag kann fortbestehen, wenn der Server einen expliziten, opaken Handle ausgibt und spätere Tools ihn als Argument verlangen. Der Handle ist bei authentifizierten Servern nur ein Name: Der Server prüft die Berechtigung des aktuellen Aufrufers bei jeder Verwendung erneut. Ohne Authentifizierung wirkt er dagegen wie ein Bearer Token und braucht hohe Entropie sowie begrenzte Lebensdauer. Versteckter Zustand an Verbindung oder Prozess wäre bequemer, zerbricht aber bei Lastverteilung, Neustart und parallel verschachtelten Aufgaben.

Discovery ist verfügbar, aber kein Pflichtvorspann

Jeder moderne Server muss server/discover implementieren. Der Client darf Discovery vor anderen Aufrufen verwenden, muss es aber nicht. Er kann sofort etwa tools/list senden und einen Versionsfehler behandeln. Diese Unterscheidung ist wichtig: verpflichtende Serverfähigkeit bedeutet nicht verpflichtender erster Client-Aufruf.

server/discover liefert unterstützte Versionen, Server-Capabilities, optionale Anweisungen und Cachehinweise. Die Serveridentität steht in modernem MCP in result._meta.io.modelcontextprotocol/serverInfo. Discovery ist besonders nützlich, wenn eine UI Fähigkeiten vorab anzeigen soll oder ein Dual-Era-Client auf stdio zwischen modernem und altem Server unterscheiden muss.

Dual-Era — Client oder Server, der sowohl modernes per-Request-MCP ab 2026-07-28 als auch ältere, durch initialize aufgebaute Sitzungen unterstützt.

Bei einer Versionsabweichung meldet ein moderner Server UnsupportedProtocolVersionError und nennt unterstützte Revisionen. Der Client wählt nur eine tatsächlich unterstützte Version und sendet einen neuen Request. Er darf nicht still so tun, als spräche die Gegenseite seine bevorzugte Revision. Für alte Server gelten eigene Erkennungsregeln: Ein Dual-Era-Client probiert auf stdio zunächst server/discover und fällt nur bei einem nicht als modern erkannten Fehler auf initialize zurück. Ein erkannter moderner Versionsfehler ist gerade kein Anlass für Legacy-Fallback. Der Preis von Dual-Era-Unterstützung sind zwei Semantikpfade mit getrennten Tests.

Tools, Resources und Prompts unterscheiden sich durch Kontrolle

Die drei bekannten Server-Primitiven unterscheiden sich nicht bloß im Datenformat. Entscheidend ist, wer die Nutzung anstößt. Tools sind modellgesteuerte, ausführbare Funktionen. Resources sind anwendungsseitig ausgewählter Kontext mit URI. Prompts sind nutzerseitig auswählbare Vorlagen. Der Host darf jede dieser Interaktionen anders darstellen; MCP schreibt keine bestimmte Oberfläche vor. Das Kontrollmodell bleibt dennoch die tragende Heuristik für den Entwurf.

Tool

Modellgesteuert; führt Operation aus oder fragt ein System aktiv ab

Resource

Anwendungsgesteuert; stellt adressierbaren Kontext zum Lesen bereit

Prompt

Nutzergesteuert; liefert auswählbare Nachrichten- oder Workflowvorlage

Ein lesender Backend-Aufruf kann trotzdem ein Tool sein, wenn das Modell die Abfrage mit Parametern auslösen soll. Eine Resource kann dynamisch erzeugt werden und bleibt dennoch Resource, wenn der Host sie als adressierbaren Kontext auswählt. Nicht das HTTP-Verb oder die technische Implementierung entscheidet, sondern die gewünschte Kontroll- und Vertragsschnittstelle.

Tools sind veröffentlichte Wirkung, keine beliebigen Funktionen

Ein Tool besitzt mindestens name, description und ein valides inputSchema. Der Client entdeckt es über tools/list und ruft es mit tools/call auf. Die Spezifikation bezeichnet Tools als modellgesteuert, fordert aber zugleich sichtbare Kontrolle für sensible Operationen: Nutzer sollen angebotene Tools und Eingaben sehen und Aufrufe ablehnen können. Modellgesteuert bedeutet also Auswahl durch das Modell, nicht Freibrief zur Wirkung.

Der Server validiert Eingaben, setzt Zugriffskontrolle und Rate Limits durch und bereinigt Ausgaben. Tool-Annotations sind nur Hinweise; ein Client muss sie als unvertrauenswürdig behandeln, solange der Server selbst nicht vertrauenswürdig ist. Auch clientInfo ersetzt keine Authentifizierung. Diese Regeln zeigen die doppelte Grenze: Der Host kontrolliert, ob der Aufruf passieren darf, und der Server kontrolliert, ob der konkrete Aufrufer die Backend-Operation ausführen darf.

Die Rückgabe ist ebenfalls Teil der Vertrauensgrenze. Ein tools/call kann unstrukturierten content und optional structuredContent liefern. Definiert das Tool ein outputSchema, muss die strukturierte Ausgabe dazu passen; der Client soll sie validieren. Das macht die Daten maschinenlesbarer, aber nicht vertrauenswürdig. Texte, Links und eingebettete Resources stammen weiterhin aus einem externen System und können falsche oder manipulative Inhalte tragen. Der Host entscheidet deshalb getrennt, was er anzeigt, in den Modellkontext übernimmt oder als Eingabe für ein weiteres Tool verwendet. Strukturvalidierung beweist Form, nicht Wahrheit oder Berechtigung.

Resources liefern Kontext, Prompts liefern einen Startpunkt

Resources tragen Text oder Binärdaten unter einer URI. Der Client kann verfügbare Resources und Templates auflisten und Inhalte über resources/read anfordern. Die URI ist Teil des Vertrags: Sie adressiert Bedeutung, nicht bloß einen zufälligen Download. Der Host entscheidet, welche Resource gelesen und dem Modellkontext hinzugefügt wird. Damit eignet sie sich für Runbooks, Dateien, Schemas oder Statusansichten, die als Kontext behandelt werden sollen.

Prompts werden über prompts/list entdeckt und über prompts/get mit benannten Argumenten abgerufen. Sie liefern strukturierte Nachrichten, die einen Nutzer-Workflow beginnen oder unterstützen. Das Protokoll schreibt nicht vor, ob der Client sie als Slash-Command, Menüpunkt oder Formular zeigt. Die Nutzerkontrolle ist das Designziel: Eine Vorlage für Code-Review oder Incident-Analyse soll bewusst gewählt werden.

• Nimm eine Resource, wenn der Host adressierbaren Kontext auswählen und lesen soll.
• Nimm einen Prompt, wenn der Nutzer eine vorbereitete Interaktion bewusst starten soll.
• Nimm ein Tool, wenn das Modell eine parametrisierte Operation anfordern soll.
• Teile Fähigkeiten auf, wenn ein einziger Vertrag mehrere Kontrollmodelle vermischt.

Wann MCP passt und wann ein direkter Adapter besser ist

MCP lohnt sich, wenn mehrere AI-Hosts dieselbe Fähigkeit nutzen sollen, wenn Server und Hosts unabhängig entwickelt werden oder wenn Discovery und ein gemeinsames Kontrollmodell Integrationskosten senken. Der Nutzen wächst mit der Zahl realistischer Wiederverwendungen. Ein Protokoll nur deshalb einzuführen, weil ein einzelner Prozess eine interne Funktion aufruft, verschiebt Komplexität ohne Interoperabilitätsgewinn.

Mehrere Hosts, fokussierter Serververtrag

MCP schafft eine wiederverwendbare Integrationsgrenze

Ein Host, ein stabiles internes Backend

Direkter Adapter kann kleiner und leichter zu debuggen sein

Unkontrollierte beliebige Codeausführung

Kein geeigneter Vertrag; Fähigkeit zuerst begrenzen

Reiner Datentransport zwischen klassischen Diensten

HTTP-, Event- oder Queue-Vertrag passt meist direkter

MCP ersetzt keine Service-API, keinen Message Broker und keine allgemeine Workflow-Engine. Es sitzt an der Grenze, an der eine AI-Anwendung Fähigkeiten und Kontext externer Systeme verwendet. Wenn kein Modell, kein AI-Host und kein Bedarf an dieser standardisierten Grenze existiert, ist das Protokoll wahrscheinlich nicht der kleinste passende Baustein.

Vom Nutzerwunsch zum kontrollierten Aufruf

Im folgenden Check ordnest du Rollen und Primitiven zu, unterscheidest Request von Notification, behandelst moderne Requests zustandslos und entscheidest über Discovery, Consent und den Einsatz von MCP. Achte auf die häufigsten Fallen: server/discover ist serverseitig Pflicht, clientseitig aber optional; eine Verbindung ist keine Sitzung; und ein Tool darf modellgesteuert sein, ohne die menschliche und serverseitige Kontrolle aufzugeben.