Kapitel 5 — Transportprotokolle und Discovery

Fünfter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Jede Nachricht in den Kapiteln 3 und 4 hat zwischen Host und Server in der Luft geschwebt — aber Nachrichten schweben nicht, sie reiten auf einem Transport, und der Transport entscheidet still fast alles Operative an einer Integration.

Warum dieses Kapitel existiert

MCP definiert sein Nachrichtenformat — JSON-RPC 2.0 über einen Duplex-Kanal — und definiert dann drei Transports, die den Kanal implementieren. Die Transports sind nicht austauschbar. Jeder passt zu einem Deployment-Muster, trägt unterschiedliches operatives Gepäck und legt unterschiedliche Sicherheitsflächen frei. Eine zweite Frage hängt über demselben Gebiet: wie findet ein Host überhaupt einen Server? Bis der Host weiß, dass ein Server existiert und wo er lebt, erzeugt das schönst spezifizierte Protokoll keine Konversationen.

Dieses Kapitel geht beides durch. Die Transports entscheiden, ob der Server co-located oder remote ist, ob du Authentifizierung oder Prozessisolation hast und wie der Server skaliert. Die Discovery-Schicht entscheidet, ob dein Server etwas ist, das ein Entwickler nutzt, oder etwas, das ein Team übernehmen kann.

5.1 stdio, SSE und Streamable HTTP

stdio bedeutet, dass der Host den Server als Kindprozess startet. Der Host schreibt JSON-RPC auf stdin des Kindes und liest Antworten von stdout; stderr trägt Logs. Kein Port, kein Socket, kein Netzwerk. Authentifizierung übernimmt die OS-Prozessstart-Grenze. Claude Desktop, Cursor und der offizielle MCP-Inspector verwenden stdio für lokale Server. Das Modell ist ehrlich, was es ist: ein Werkzeug auf der eigenen Maschine, co-located, in derselben Vertrauensdomäne wie der Host. Es lässt sich nicht über Hosts teilen, nicht auf einer anderen Maschine fahren, und Eins-pro-Host ist die einzige verfügbare Vielfachheit — fünf Clients, die denselben Server wollen, verbrennen fünf Prozesse.

HTTP+SSE war MCPs erste Antwort auf den Netzwerkfall. Bidirektional, aber Duplex aus zwei unidirektionalen Stücken zusammengeschraubt. Abgelöst. Noch in der Wildnis. SSE-basierte Server werden dir noch eine Weile begegnen.

Streamable HTTP ist der bevorzugte Netzwerktransport. Ein einziger Endpunkt — typisch /mcp — akzeptiert JSON-RPC-Requests und antwortet entweder mit einer einzelnen Antwort (für synchrone Aufrufe) oder mit einem Strom von Server-Sent Events, wenn es mehrere Nachrichten gibt, einschließlich server-initiierter Notifications. Sessions werden über einen Mcp-Session-Id-Header identifiziert, der beim Initialize gesetzt und durch jeden folgenden Request gefädelt wird. Die Session ist die Einheit des Zustands, freigegeben per DELETE oder per Timeout eingesammelt. Der Transport komponiert sauber mit Load Balancern, Reverse Proxies, Edge Caches und TLS. Horizontale Skalierung ist Sticky-Session über die Session-ID. Nichts davon ist neuartiges HTTP-Engineering; der Punkt ist, dass MCP hineinpasst, ohne eine neue Schicht zu erfinden.

Die Wahl ist genauso eine Sicherheitsentscheidung wie eine Deployment-Entscheidung. stdio-Server neigen zur Über-Privilegierung — sie erben Dateisystem- und Netzwerkrechte der Nutzerin, ohne Authentifizierung, weil es keinen Remote-Aufrufer gibt. Netzwerk-Server stehen dem offenen Internet gegenüber und müssen jeden Request authentifizieren, mit OAuth 2.1 als jetzt konvergierendem Standard. Den falschen Transport für deine Sicherheitshaltung zu wählen, zwingt dich, nachzurüsten, was eingebaut hätte sein sollen.

5.2 Server-Discovery: .well-known/mcp.json und Server Cards

Ein Protokoll, das verlangt, dass jeder Host mit jeder Server-Adresse von Hand konfiguriert wird, wird kein Ökosystem. Es wird ein Konfigurationsalbtraum. Die Discovery-Schicht von MCP übernimmt das Well-Known-URI-Muster aus RFC 8615 — dasselbe, das robots.txt und .well-known/openid-configuration nutzen. Ein Server publiziert .well-known/mcp.json auf seiner Basis-URL. Ein Host holt das, parst es und erfährt, was der Server über sich behauptet: den MCP-Endpunkt, die Protokollversion, das Auth-Schema, Identitätsmetadaten und einen Zeiger auf die Server Card.

Die Server Card ist MCPs openapi.json: ein selbstbeschreibendes Artefakt, das Maschinen und Menschen lesen können. Ein Host kann die Card der Nutzerin beim Connect-Flow zeigen — „dieser Server sagt, er kann auf deinen Linear-Workspace zugreifen, wird Tickets lesen, aber nicht löschen, wird von Linear selbst betrieben, nutzt OAuth" — und die Nutzerin entscheidet, ob die Behauptung akzeptabel ist. In ihrer unsignierten Form sind die Cards Behauptungen, kein Beweis. Die Minderung ist signierte Attestation, mit einem Signiermodell, das auf sigstore-Stil OIDC konvergiert ist: eine Card, die per GitHubs OIDC-Integration unter github.com/some-org/mcp-server signiert ist, lässt sich von jedem Host verifizieren, der GitHubs Identitätsbehauptungen vertraut. Hosts können Policy darüberlegen — nur signierte Cards vertrauen, nur signierte Cards eines bestimmten Anbieters, nur welche, die nicht auf einer Revocation-Liste stehen.

Der Ablauf sieht aus wie das Hinzufügen eines WLAN-Netzwerks. Einmal. Der Host speichert die Konfiguration; folgende Sessions überspringen Discovery. Was „etwas hat sich geändert" praktisch heißt — Versionssprünge, Scope-Erweiterungen, Capability-Verschiebungen — sollte erneute Zustimmung auslösen, so wie ein TLS-Zertifikatswechsel. Hosts, die diesen Schritt überspringen, lassen Server still ihre Reichweite ausweiten, was genau das langsame Capability-Kriechen ist, das das Vertrauen in jede langlebige Integration kompromittiert.

5.3 Die langweiligen Teile, die entscheiden, ob du shippen kannst

Drei operative Themen verdienen eigene Behandlung, weil jedes eine Stelle ist, an der nachlässige Implementierung entweder kaputte Integrationen oder Sicherheitslücken produziert.

CORS zählt für jeden MCP-Server, der von einem Browser-basierten Host erreichbar ist. Die Versuchung ist, Access-Control-Allow-Origin: * zu setzen und weiterzuziehen. Das ist falsch. Kombiniert mit Cookie-Auth ist es ein CSRF-Desaster; kombiniert mit Bearer-Tokens im localStorage ist es ein Token-Exfiltrationsrisiko. Nutze eine per-Origin-Allowlist und bevorzuge Authorization-Header gegenüber Cookies, damit Same-Origin nicht deine einzige Verteidigungslinie ist.

Origin-Validierung ist CORS, server-seitig angewendet, weil Nicht-Browser-Clients nichts erzwingen. Der klassische Fehler: eine Entwicklerin fährt einen MCP-Server auf localhost:8000, besucht eine Seite, die die Konvention kennt, die Seite feuert einen Request, und der Server — ohne Origin-Prüfung — tut, was die Seite verlangte. Validiere Origin auf jedem Streamable-HTTP-Server.

Caching-Header sind das dritte Thema. Statische Dokumentation lässt sich aggressiv cachen; eine Datenbankzeile nur solange Subskriptionen verdrahtet sind; ein aktiv editiertes Dokument gar nicht. Liefere passende Cache-Control- und ETag-Werte pro Resource. Die Wechselwirkung zwischen Caching und Subskriptionen ist die Stelle, an der Entwickler gebissen werden — ein Vermittler, der eine veraltete Kopie ausliefert, bedeutet, dass die resources/updated-Notification des Hosts nie auslöst, weil der Subskriptionsmechanismus den lebenden Server nie erreicht.

DNS-Rebinding rundet die Nachbarschaft ab und trifft lokale Server überproportional. Bind an 127.0.0.1, nicht 0.0.0.0, validiere den Host-Header gegen eine Allowlist, verlange ein Auth-Token auch für localhost. Ein lokaler MCP-Server ohne diese ist eine Demo von einer Sicherheitswarnung entfernt.

Was Kapitel 5 vorbereitet

Das schließt Teil II des Buchs. Wir haben das Protokoll in der Hand: Server-Primitives in Kapitel 3, Client-Primitives in Kapitel 4, Wire und Discovery hier. Wir wissen, welche Nachrichten in welche Richtung über welchen Transport zwischen welchen Vertrauensdomänen nach welchem Handshake reisen. Teil III wendet sich von Primitiven zu Mustern. Ein einziger Server, mit einem einzigen Host verbunden, ist nützlich; die architektonische Auszahlung von MCP ist Komposition — mehrere Server, mehrere Agenten, mehrere Modelle, die auf größere Ziele hin kooperieren.

Als Nächstes — Kapitel 6: Grundlegende Orchestrierungsstrategien. Wann ein einzelner gut bewaffneter Agent ein Multi-Agent-Design schlägt, und die zwei grundlegenden Formen — sequenzielle Pipelines und Scatter-Gather-Nebenläufigkeit — auf die sich die meisten Produktions-Deployments stützen.