Stateless MCP: der Zustand verschwindet nicht, er wechselt die Schicht

Google
Agentic Engineering
Automation

Google hat am 5. August einen Beitrag von Kurtis Van Gent und Alan Blount veröffentlicht, der den sitzungslosen Kern des Model Context Protocol aus Betriebssicht erklärt. Zwei Dinge gehören hier auseinandergehalten. Das eine ist die Spezifikation: Der Release Candidate 2026-07-28 entfernt die Sitzungsverwaltung aus der Transportschicht, und er ist älter als der Beitrag. Das andere ist Googles Lesart der Folgen, und die ist die eigentliche Nachricht. Meine These: Der Zustand verschwindet nicht. Er wandert aus dem Transport in Ihre Anwendung, und damit von der Infrastruktur zu Ihnen.

Was hat Google veröffentlicht?

Eine Begründung und eine Migrationsempfehlung. Google beschreibt, warum es die Entfernung der Sitzungen vorangetrieben hat, verlinkt den entsprechenden Pull Request an der Spezifikation und nennt die eigene Rolle beim Aufbau der MCP Transports Working Group, gemeinsam mit Hugging Face und weiteren Partnern. Der Anlass ist nach Googles Darstellung Eigenbedarf: Als das Unternehmen MCP-Server in der eigenen Cloud-Infrastruktur ausrollte, stieß es an eine Wand, weil das ursprüngliche Sitzungsmodell persistenten Zustand, Handshakes und Session-Pinning verlangte.

Google nennt den Release Candidate „bereits breit übernommen“ und verlinkt dafür einen fremden Blogbeitrag. Belegt ist im Text selbst genau ein Beispiel, der GitHub MCP Server. Das ist kein Vorwurf, aber es ist der Unterschied zwischen einer Angabe und einem Beleg.

Warum war die Sitzung ein Engpass?

Weil sie den Client an einen bestimmten Prozess band. In der Version 2025-11-25 begann eine HTTP-Verbindung mit einem initialize-Aufruf, der Server antwortete mit einem Header Mcp-Session-Id, und jeder weitere Werkzeugaufruf musste diese Kennung mitschicken. Damit hing der Client an genau dem Container, der seinen Sitzungszustand im Speicher hielt.

Google listet vier Folgen daraus auf. Ein gewöhnlicher Round-Robin-Load-Balancer weiß nicht, welcher Container welche Sitzung hält: Hinter drei Pods landet die zweite Anfrage auf einem anderen Pod und bekommt einen Fehler „400 Session Not Found“. Wer das umgeht, konfiguriert Sticky-Affinität am Load Balancer, verhindert damit aber die gleichmäßige Verteilung und macht Autoscaling ineffizient. Startet ein Pod neu oder stürzt er ab, ist der Sitzungszustand sofort weg, und der Fehler landet in einem laufenden Chat. Und wer Remote-Server betreibt, brauchte geteilte Redis-Sitzungsspeicher oder eine Paketinspektion im Gateway. So beschreibt Google die Ausgangslage. Es ist eine glaubwürdige Beschreibung, aber es ist Googles Beschreibung.

Was fällt weg, und was kommt dafür?

Der Handshake fällt weg. initialize und initialized (SEP-2575) sowie der Header Mcp-Session-Id (SEP-2567) sind vollständig entfernt. Was früher einmal beim Verbindungsaufbau ausgehandelt wurde, Protokollversion, Client-Info und Client-Fähigkeiten, reist jetzt in einem Feld _meta bei jeder einzelnen Anfrage mit. Jede Anfrage beschreibt sich selbst.

Dazu kommen drei Standard-HTTP-Header (SEP-2243): Mcp-Protocol-Version, Mcp-Method und Mcp-Name, also Protokollversion, aufgerufene JSON-RPC-Methode und der Name des Werkzeugs, Prompts oder Resource. Sie spiegeln den Body. Widersprechen sie ihm, weist der Server die Anfrage mit dem Code -32020 ab. Der Zweck ist nüchtern: Proxies, Gateways und Load Balancer können routen, drosseln und protokollieren, ohne den Body zu lesen. Für das Caching führt SEP-2549 die Felder ttlMs und cacheScope ein, an Cache-Control angelehnt. Ein Client weiß damit, wie lange eine Antwort auf tools/listfrisch ist, statt eine SSE-Verbindung offen zu halten, nur um Änderungen mitzubekommen.

Wohin geht der Zustand, den Sie trotzdem brauchen?

In die Anwendung. Das steht bei Google selbst, in einem Nebensatz: Die Verantwortung für den Zustand verschiebt sich von der Transport- in die Anwendungsschicht, und deshalb werde Sicherheit dort zentral. Genau dieser Satz gehört auf das Migrationsticket.

Zwei Mechanismen zeigen, wie das aussieht. Multi Round-Trip Requests (SEP-2322) lösen Rückfragen an den Nutzer ohne offene Verbindung: Der Server antwortet sofort mit einem InputRequiredResult, das einen serialisierten requestState enthält. Der Client holt die Antwort beim Menschen ein und schickt den Aufruf erneut, mit inputResponses und dem zurückgereichten requestState. Weil dieser Payload alles zum Fortsetzen enthält, kann jede beliebige Server-Instanz die Fortsetzung übernehmen. Die Tasks Extension (SEP-2663) wird von einer experimentellen Funktion zur regulären Erweiterung. Ein lang laufender Aufruf gibt sofort eine taskId zurück, die Arbeit läuft im Hintergrund, und der Client fragt über tasks/get und tasks/updatenach.

Bemerkenswert ist Googles eigenes TypeScript-Beispiel für die Tasks Extension. Es legt den Anfangszustand einer Aufgabe in einem geteilten Datenspeicher ab, und der genannte Vorschlag ist Redis. Redis ist also nicht aus dem Bild verschwunden, sondern nur aus dem Sitzungspfad. Das ist ein echter Gewinn, weil nicht mehr jeder Aufruf durch den geteilten Speicher muss. Es ist aber nicht dasselbe wie „kein Zustand mehr“.

Was ändert sich an Sicherheit und Abkündigungen?

Google nennt drei Sicherheitspunkte des Release Candidate. Öffentliche Clients müssen den Parameter iss in Autorisierungsantworten prüfen (RFC 9207), was gegen Übernahme und Umleitungsangriffe in Mehr-Server-Architekturen schützen soll. Resource Indicators (RFC 8707) machen explizit, für welchen MCP-Server ein Token gedacht ist, gegen das Confused-Deputy-Problem. Und Werkzeug-Schemas dürfen das volle JSON Schema 2020-12 nutzen, inklusive oneOf, anyOf, allOf und lokaler $ref-Definitionen.

Praktisch genauso wichtig: MCP bekommt zum ersten Mal eine formale Abkündigungspolitik (SEP-2577), mit den Stufen Active, Deprecated und Removed und einem Übergangsfenster von mindestens zwölf Monaten. Drei Funktionen treten heute in die Abkündigung ein. Roots wird durch explizite Werkzeugparameter, Resource-URIs oder Serverkonfiguration ersetzt. Sampling durch direkte Aufrufe der LLM-Anbieter-APIs. Logging durch stderr bei stdio-Verbindungen oder OpenTelemetry in der Cloud. Wer eines davon nutzt, hat jetzt einen Zeitplan, statt eines Gerüchts.

Was heißt das für Ihre Migration?

Es ist ein konkreter Punkt für die Liste, kein Grund zur Hektik. Alle vier Tier-1-SDKs (TypeScript, Python, Go und C#) haben Betas für die Spezifikation 2026-07-28, und Google empfiehlt ausdrücklich das Testen in Staging. In Python installieren Sie pip install "mcp[cli]==2.0.0b1". In TypeScript ersetzt Version 2 das monolithische Paket @modelcontextprotocol/sdk durch getrennte Pakete für Server und Client, für die Umbenennungen gibt es einen Codemod. Es bleibt ein Release Candidate. Beta-SDKs gehören in Staging, nicht in die Produktion.

Die ehrliche Prüffrage für Ihren eigenen Server lautet nicht „ist mein SDK aktuell“, sondern: Was hält mein Server zwischen zwei Aufrufen im Speicher? Alles, was dort liegt, bricht in dem Moment, in dem der Load Balancer die nächste Anfrage an eine andere Instanz gibt. Googles Betriebsvorteile, gewöhnliches Round-Robin, Serverless mit Herunterskalieren auf null, Failover ohne sichtbaren Bruch, folgen nicht automatisch aus der Spezifikation. Sie folgen daraus, dass Ihre Anwendung wirklich zustandslos ist.

Das ist dieselbe Linie wie bei den Retries in der MCP-Verkabelung und bei den Managed Agents, die Remote-MCP-Server direkt aufrufen. Im Agentic Engineering entsteht Verlässlichkeit nicht im Modell, sondern in der Architektur darum herum. Diese Revision räumt eine Klasse von Betriebsproblemen ab und schiebt die Zustandsfrage eine Schicht nach oben. Beantworten muss sie weiterhin ein Mensch, und zwar der, dem der Server gehört.