MCP wird stateless: Die Spezifikation beseitigt endlich den letzten Enterprise-Blocker

Eine neue Überarbeitung des Model Context Protocol entfernt die Anforderung für eine zustandsbehaftete Sitzung - der Teil, der MCP hinter einem Lastenausgleicher schwer skalierbar machte. Kleine Änderung auf dem Papier; große Änderung bei der Bereitstellung.

In einfachen Worten. Das Model Context Protocol - die Spezifikation, die es KI-Assistenten ermöglicht, externe Tools aufzurufen - hat eine Überarbeitung veröffentlicht, die die Anforderung einer zustandsbehafteten Verbindung zwischen Client und Server entfernt. Das ist die Änderung, auf die die Enterprise-Infrastruktur-Teams gewartet haben.

Warum stateful ein Problem war

Der ursprüngliche MCP-Transport ging von einer persistenten Client-Server-Sitzung aus. Wenn Ihr Assistent einen Tool-Aufruf benötigte, teilten sich der Assistent und das Tool einen Live-Kanal für die Dauer der Interaktion. Auf einem Laptop in Ordnung; unangenehm in großem Maßstab.

Die Unannehmlichkeit zeigt sich, sobald Sie einen Load Balancer davor setzen. Eine zustandsbehaftete Sitzung bedeutet, dass jeder nachfolgende Aufruf auf der gleichen Backend-Instanz landen muss. Das tötet das günstigste Bereitstellungsmuster in der Enterprise-Infrastruktur - Anfragen über einen zustandslosen Pool verteilen, bei Last automatisch skalieren, Node-Verlust tolerieren. Sie enden damit, dass Sie Session-Affinität-Kludges, Sticky-Routing oder schlimmer, Connection-Manager bauen, die zu ihren eigenen SPOFs werden.

Was die neue Spezifikation tatsächlich ändert

Laut den Berichten ermöglicht der überarbeitete Transport, dass Server einen zustandslosen Modus ankündigen. In der Praxis:

# vorher (paraphrasiert)
POST /mcp/session → session_id
POST /mcp/call { session_id, tool, args } # muss denselben Node treffen
POST /mcp/close { session_id }

# nachher - zustandsloser Modus
POST /mcp/call { tool, args, ctx } # beliebiger Node, keine Sitzung

Der ctx ist das Element, das alles trägt, was der Server über frühere Runden benötigt, und vom Client gepusht wird. Es ist dasselbe Muster, auf das sich REST-APIs vor zwanzig Jahren geeinigt haben - Zustandslosigkeit, erkauft mit etwas größeren Anfragen.

Unter der Haube: der Trade-off, den Sie jetzt besitzen

Zustandslosigkeit ist nicht kostenlos. Zwei Dinge verlagern sich auf den Client:

• Kontextmanagement. Der Client ist nun die Quelle der Wahrheit für jeden pro-Gespräch-Zustand, den ein Tool benötigt. Größere Payloads und eine neue Klasse von Fehlern: Vergessen, den Kontext weiterzugeben.
• Idempotenz. Sobald jeder Node jeden Aufruf bedienen kann, werden Wiederholungen in mehr Bereichen plausibel. Tool-Autoren müssen ihre Aufrufe idempotent machen oder mit doppelter Ausführung umgehen.

Für die meisten Enterprise-Einsätze lohnt sich dieser Tausch. Für Assistenten mit niedriger Latenz, bei denen Round-Trip-Bytes zählen, ist es eine echte Kosten.

Was dies signalisiert

Der MCP-Ökosystem-Faden drehte sich darum, dass die Rohrleitungen von "Prototypenqualität" zu "wir können dies tatsächlich hinter einem SRE-Team platzieren" reifen. Der zustandslose Transport ist der konkrete Schritt in diese Richtung. Es sagt Ihnen auch, wo die Autoren der Spezifikation das Wachstum sehen: innerhalb von Unternehmen, hinter Proxies, nicht auf den Maschinen einzelner Entwickler.

Also was

Für einen Builder: Wenn Sie eine MCP-Integration verschifft haben und auf Session-Affinitäts-Schmerzen gestoßen sind, ist die Lösung jetzt spezifikationsgesegnet und nicht mehr maßgeschneidert. Für einen Entscheider: MCP ist gerade beschaffungsfreundlich geworden. Erwarten Sie, dass Anbieter "MCP-nativ" bewerben, so wie sie früher "REST-nativ" beworben haben.