Google und Google Cloud unterstützen seit dem 14. September die MCP-Spezifikation 2026-07-28. Die Meldung selbst ist kurz. Technisch steckt dahinter aber eine größere Änderung: MCP verabschiedet sich auf Protokollebene von Sessions und bewegt sich näher an normale, stateless HTTP-Infrastruktur.
Für Entwickler, die MCP-Server nur lokal an einen einzelnen Client hängen, wirkt das zunächst abstrakt. Sobald ein MCP-Server jedoch hinter einem Load Balancer läuft, mehrere Instanzen hat oder als Teil einer SaaS-Plattform betrieben wird, verändert diese Entscheidung die Architektur deutlich.
Kein initialize-Handshake mehr
Die Version 2026-07-28 entfernt den bisherigen initialize/initialized-Austausch und den Mcp-Session-Id-Header aus dem Kernprotokoll.
Stattdessen trägt jede Anfrage ihre Protokollversion, Client-Informationen und Capabilities selbst mit. Ein Client kann die Fähigkeiten eines Servers weiterhin über server/discover abfragen, muss aber nicht zuerst eine dauerhafte Protokollsitzung aufbauen.
Der Effekt ist unspektakulär, aber praktisch: Eine Anfrage kann an jede beliebige Instanz eines MCP-Servers gehen. Sticky Sessions oder ein gemeinsamer Session Store sind für den Protokollzustand nicht mehr grundsätzlich nötig.
Das ist genau die Eigenschaft, die bei klassischen Web-APIs seit Jahren das horizontale Skalieren vereinfacht.
MCP wird leichter hinter normale Infrastruktur zu setzen
Ein zustandsbehafteter Transport zwingt Infrastruktur und Anwendung enger zusammen. Wenn eine bestimmte Sitzung an einer bestimmten Instanz hängt, muss der Load Balancer diese Beziehung kennen oder der Zustand muss extern gespeichert werden.
Mit dem stateless Core kann ein MCP-Server deutlich normaler betrieben werden: mehrere Instanzen hinter einem Round-Robin-Load-Balancer, ohne dass jede Request-Serie an denselben Prozess zurückkehren muss.
Das bedeutet nicht, dass MCP-Anwendungen keinen Zustand mehr haben dürfen. Ein Tool kann weiterhin eigene Handles erzeugen und damit über mehrere Aufrufe hinweg einen fachlichen Zustand referenzieren. Dieser Zustand wird dann aber explizit Teil der Anwendung und nicht implizit durch die Transportverbindung erzeugt.
Diese Trennung ist sauberer. Wenn ein Agent beispielsweise einen langen Import startet, sollte der Import ohnehin eine eigene ID besitzen. Dass derselbe HTTP-Prozess die nächste Anfrage bekommt, ist dafür keine belastbare Zustandsverwaltung.
Google Cloud ist als Implementierer interessanter als die reine Versionsnummer
Die Spezifikation selbst erschien bereits am 28. Juli. Neu ist jetzt, dass Googles eigene Google- und Google-Cloud-MCP-Server die Version unterstützen. Google bezeichnet die Änderung als rückwärts kompatibel zu 2025-11-25.
Hier muss man präzise sein: Die aktuelle MCP-Spezifikation hat auf dem Wire gegenüber der vorherigen Generation durchaus grundlegende Änderungen. Ein alter Client und ein neuer Server können nicht automatisch jede neue Semantik verwenden. Googles Aussage bezieht sich auf die eigene Implementierung und deren Unterstützung für bestehende Clients, nicht darauf, dass zwischen den beiden Spezifikationen technisch nichts geändert worden wäre.
Für das Ökosystem ist genau diese Übergangsphase relevant. Ein Standard wird erst dann praktisch wertvoll, wenn große Clients, Clouds und SDKs nicht nur das Dokument unterstützen, sondern Migration und Versionserkennung in realen Deployments abfangen.
Header-basierte Routinginformationen sind für Gateways interessant
Die neue Spezifikation legt relevante Routinginformationen stärker in Header. Dazu gehören unter anderem Methode und Name des aufgerufenen MCP-Elements.
Damit kann Infrastruktur früher erkennen, welche Art von Request ankommt. Gateways müssen nicht zwingend den gesamten JSON-RPC-Body interpretieren, nur um grundlegende Routing- oder Policy-Entscheidungen zu treffen.
Das kann für Rate Limits, Observability und Security-Policies nützlich werden. Ein Gateway könnte beispielsweise Tool-Aufrufe anders behandeln als reine List-Abfragen oder bestimmte Tools gezielt auf eigene Worker-Pools routen.
Ob einzelne Cloud-Anbieter genau diese Möglichkeiten nutzen, ist eine Implementierungsfrage. Die Protokollstruktur macht solche Architekturen aber einfacher.
Cachebare Listen sparen bei großen Tool-Sets Arbeit
Die neue Version erlaubt außerdem, Ergebnisse von tools/list, resources/list und prompts/list mit einer TTL zu versehen. Das ist bei kleinen MCP-Servern kaum relevant. Bei einem Agenten mit vielen verbundenen Servern kann das ständige erneute Laden derselben Metadaten jedoch unnötige Requests und Latenz verursachen.
Tool-Discovery ist damit nicht mehr automatisch etwas, das bei jedem neuen Transportzustand erneut passieren muss.
Gerade Agent-Plattformen mit dynamischer Tool-Auswahl profitieren davon, wenn die Infrastruktur zwischen einer stabilen Tool-Liste und einem tatsächlichen Tool-Aufruf unterscheiden kann.
MCP wird weniger wie eine spezielle Agentenverbindung und mehr wie Web-Infrastruktur
Für uns ist an der Google-Ankündigung deshalb nicht die Versionsnummer der interessante Teil. Relevant ist, dass sich MCP architektonisch von einer dauerhaften Client-Server-Sitzung entfernt.
Das macht Remote-MCP-Server einfacher skalierbar und zwingt Entwickler gleichzeitig dazu, echten Anwendungszustand explizit zu modellieren.
Wenn MCP langfristig die Verbindungsschicht zwischen Agenten und externen Systemen werden soll, ist das vermutlich die vernünftigere Richtung. Ein Protokoll für Tools sollte nicht voraussetzen, dass ein bestimmter Prozess dauerhaft weiß, welcher Agent vor einigen Requests mit ihm gesprochen hat.
Quellen: Google Cloud MCP Server Release Notes, 14. September 2026; Model Context Protocol Specification 2026-07-28 und offizieller MCP-Changelog.