MCP Version 2 geht am 28. Juli 2026 live. Sie verzichtet auf jeden Handshake, jeden Session-ID-Header und die drei Legacy-Subsysteme, die das Model Context Protocol (MCP) an Sticky-Session-Server banden. Das Protokoll wird vollständig zustandslos (stateless), sodass jede autoskalierte oder serverlose Instanz jede Anfrage bearbeiten kann, ohne den Client-Zustand beibehalten zu müssen.

Warum dieser Wechsel wichtig ist

MCP v1 zwang den Client dazu, eine Session mit einem initialize-Handshake zu starten; der Server wies daraufhin eine Mcp-Session-Id zu. Jeder spätere Aufruf musste diesen Header enthalten, was den Nutzer an einen einzelnen Backend-Knoten band. Load Balancer mussten Session Affinity erzwingen, was Latenz und operativen Aufwand verursachte.

Zustandslosigkeit eliminiert diese Reibungspunkte. Der gesamte Kontext befindet sich nun in dedizierten Meta-Feldern, die bei jedem HTTP-Aufruf mitgesendet werden. Eine Anfrage kann auf jeder beliebigen Instanz landen, verarbeitet werden, und die Instanz kann in dem Moment verworfen werden, in dem die Antwort gesendet wird. Teams, die serverlose Plattformen, container-orchestrierte Cluster oder Umgebungen nutzen, in denen Pods bedarfsgerecht hoch- und heruntergefahren werden, können das Protokoll nun optimal auf ihre Infrastruktur abstimmen.

Was eingestellt wird

Drei Subsysteme, die von persistenten Verbindungen abhängig waren, werden offiziell als veraltet (deprecated) eingestuft:

  • Sampling – In v1 konnte ein Server den Client bitten, Text zu generieren, ein Muster, das eine offene Session erforderte. v2 erwartet, dass der Server den Large-Language-Model-Provider direkt aufruft oder das InputRequiredResult-Muster verwendet, bei dem der Client fehlende Eingaben in einer Folgeanfrage liefert.
  • Roots – Zuvor sendeten Clients URIs, die die Sicht des Servers auf externe Ressourcen einschränkten. Der neue Ansatz übergibt diese URIs als Tool-Parameter oder bettet sie in die Resource-Felder der Anfrage ein, wodurch der separate „Roots“-Aushandlungsschritt entfällt.
  • Logging – Logging-Header auf Protokollebene fallen weg. Schreiben Sie für das lokale Debugging in stderr oder nutzen Sie OpenTelemetry für die Observability in der Produktion.

Das Zeitfenster für die Abkündigung (Deprecation) beträgt ein Jahr. Veraltete Funktionen bleiben für diesen Zeitraum funktionsfähig, sodass Teams Zeit für Refactorings haben, bevor das Protokoll sie ablehnt.

Was es außer der Zustandslosigkeit Neues gibt

MCP v2 fügt zwei offizielle Erweiterungen hinzu:

  • MCP Apps – Eine leichtgewichtige Methode zur Beschreibung serverseitig gerenderter Benutzeroberflächen, die das Protokoll aufrufen kann.
  • Tasks – Ein Muster für die Handhabung von langlaufenden Operationen, die sich über mehrere Request-Response-Zyklen erstrecken können.

Beide Erweiterungen setzen auf das zustandslose Request-Modell und vermeiden versteckten Session-Zustand.

Risiken und Gegenargumente

Die Änderung ist kein Plug-and-Play-Upgrade. Die v2-SDKs befinden sich noch in der Beta-Phase, und ihre öffentlichen APIs können sich vor einer stabilen Veröffentlichung noch ändern. Für Produktions-Workloads, die keine Breaking Changes tolerieren können, sollten Sie beim stabilen v1-SDK bleiben, bis das v2-SDK die Beta-Phase verlässt.

Entwickler müssen zudem den bestehenden Code auf die drei veralteten Subsysteme prüfen.

Ein pragmatischer Migrationsplan

  1. Heute prüfen (Audit) – Scannen Sie Ihre Dienste auf die Verwendung des Handshakes, der Mcp-Session-Id, Sampling-Aufrufen, Roots-URIs und des Logging auf Protokollebene. Identifizieren Sie Code, der unter einem zustandslosen Modell nicht mehr funktionieren würde.
  2. An einem unkritischen Knoten testen – Sobald ein stabiles v2-SDK veröffentlicht wird, starten Sie einen Sandbox-Server, verbinden Sie ihn mit einem Test-Client und verifizieren Sie, dass alle erforderlichen Meta-Felder vorhanden und korrekt interpretiert werden.
  3. Vollständige Migration vor Ablauf der Frist – Schließen Sie die Umstellung auf allen Produktionsknoten ab, bevor die einjährige Übergangsfrist endet, um Laufzeitfehler (Rejections) zu vermeiden.

Worauf man als Nächstes achten sollte

  • Veröffentlichung des stabilen SDKs – Die Beta-SDKs werden eingefroren und ein versioniertes, stabiles Paket wird veröffentlicht. Diese Version wird das sichere Ziel für alle kritischen Deployments sein.

Der Übergang wird Codeänderungen und eine kurze Phase des Experimentierens mit Beta-SDKs erfordern, aber der Gewinn ist ein saubererer, skalierbarerer Integrationspunkt für jede LLM-gestützte Anwendung.

Fazit: Wenn Ihr Stack noch von MCP-Handshakes oder den drei veralteten Subsystemen abhängt, beginnen Sie jetzt mit dem Audit; ein Jahr Übergangsfrist ist großzügig, aber die eigentlichen Kosten sind der Refactoring-Aufwand, nicht die Frist.