MCP 2026-07-28 wird zustandslos: Initialize-Handshake und Session-ID verschwinden

MCP 2026-07-28, die umfangreichste Überarbeitung des Model Context Protocol seit dem Start, wird am 28. Juli final. Zwei Specification Enhancement Proposals prägen das Release: SEP-2575 entfernt den Initialize-Handshake, und SEP-2567 entfernt den Mcp-Session-Id-Header samt der Session auf Protokollebene. Der Transport wird zustandslos, und jede Anfrage erreicht jede beliebige Serverinstanz hinter einem einfachen Round-Robin-Load-Balancer.

Das Model Context Protocol ist der offene Standard, der LLM-Clients mit externen Tools, Datenquellen und Diensten verbindet. Anthropic führte es Ende 2024 ein, und die Verbreitung wuchs rasch über IDEs, Agenten-Frameworks und Enterprise-Plattformen hinweg. Bis Mitte 2026 sind MCP-Server in Entwicklerwerkzeugen, Coding-Agenten und internen Enterprise-Gateways verbaut, was jede breaking Transportänderung zu einem flottenweiten Ereignis macht. In jeder früheren Revision öffnete eine MCP-Verbindung mit einem Handshake und trug einen Session-Identifier über ihre gesamte Lebensdauer. Dieses Design zwang Remote-Deployments zu Sticky-Routing und geteilten Session-Stores, und eine verlorene Session wurde teuer: Der Client musste sich neu verbinden und den Handshake wiederholen. Die Revision 2026-07-28 schreibt dieses Fundament neu, und die Folgen erreichen jedes Team, das MCP-Server in Produktion betreibt.

Was sich auf Protokollebene ändert

Der Release Candidate wurde am 21. Mai 2026 eingefrorenund die finale Spezifikation erscheint am 28. Juli. SEP-2575 beseitigt den Initialize/Initialized-Austausch. Protokollversion, Client-Info und Client-Capabilities reisen jetzt bei jeder Anfrage in _meta, und eine neue server/discover-Methode lässt Clients die Server-Capabilities bei Bedarf abrufen. SEP-2567 entfernt den Mcp-Session-Id-Header und die Session auf Protokollebene vollständig. Mit beiden Änderungen aktiv landet jede MCP-Anfrage auf jeder beliebigen Serverinstanz, und Sticky-Routing verlässt die Liste der Protokollanforderungen.

Weitere Proposals vervollständigen das Bild. SEP-2243 verlangt die Header Mcp-Method und Mcp-Name, sodass ein Load Balancer allein anhand des Headers routet. SEP-2322 führt Multi-Round-Trip-Requests ein und ersetzt damit die früheren SSE-Streams. SEP-2260 erlaubt serverseitig ausgelöste Anfragen während der aktiven Client-Verarbeitung, und SEP-414 fügt W3C Trace Context in _meta für verteiltes Tracing hinzu. SEP-2549 ergänzt die Felder ttlMs und cacheScope in List- und Read-Antworten. SEP-2106 bringt volle Unterstützung für JSON Schema 2020-12, SEP-2164 ändert einen Fehlercode von -32002 auf -32602, und SEP-2577 legt eine Deprecation-Policy für Roots, Sampling und Logging fest. Tasks, einst ein Kernfeature, kehren als Erweiterung über SEP-2663 zurück, und MCP Apps kommen für serverseitig gerenderte UIs über SEP-1865.

Die server/discover-Methode gestaltet die Capability-Aushandlung neu. Wo der alte Handshake einen vollständigen Capability-Austausch vorlud, fragen Clients jetzt genau die Oberfläche ab, die sie aufrufen wollen, und die Antwort trägt die ttlMs- und cacheScope-Hinweise aus SEP-2549, sodass der Client Tool- und Ressourcenlisten über Anfragen hinweg cacht. Zusammen mit der _meta-Payload wird eine einzelne zustandslose Anfrage vollständig selbstbeschreibend: Version, Identität, Trace-Context und Routing-Header reisen alle gemeinsam.

Beta-SDKs erschienen vor dem Stichtag für alle vier Tier-1-Ziele: Python mcp v2.0.0b1, TypeScript v2 unter neuen Paketnamen, Go v1.7.0-pre.1 und C# v2.0.0-preview.1. Tier 1 markiert die höchstpriorisierten SDKs im Support-Framework der Community, und jede liefert funktionierende Unterstützung innerhalb des Validierungsfensters. Teams installieren die Python-Beta mit pip install \"mcp[cli]==2.0.0b1\" und beziehen die TypeScript-Pakete über den @beta-Tag. Das Validierungsfenster läuft rund vier Wochen, bevor die Spezifikation am 28. Juli final wird.

Die architektonische Implikation

Ein zustandsloser Transport verändert die Deployment-Rechnung. Ein Remote-MCP-Server läuft jetzt auf gewöhnlicher Infrastruktur, einem einfachen Round-Robin-Load-Balancer, horizontalem Autoscaling und kurzlebigen Containern, weil jede Anfrage ihren eigenen Kontext mitbringt. Sticky-Sessions und geteilte Session-Stores verlassen den kritischen Pfad, was Betriebskosten senkt und einen typischen Fehlerfall schließt, bei dem eine verlorene Session eine vollständige Neuverbindung erzwang. Für eine Agentenplattform, die Tausende gleichzeitiger Tool-Calls über eine Flotte verteilt, gestaltet dies die Kapazitätsplanung neu.

Das Entfernen der Session auf Protokollebene lässt den Anwendungszustand vollständig intakt. Ein Server, der Zustand tragen muss, prägt ein explizites Handle aus einem Tool-Call und lässt das Modell dieses Handle als gewöhnliches Argument bei späteren Aufrufen zurückgeben. Zustand wird zu Daten, die die Anwendung besitzt, statt einer verborgenen Eigenschaft der Verbindung, und diese Verschiebung gibt Engineering-Teams direkte Kontrolle darüber, wo Zustand lebt und wie lange er überdauert. Das Release verbindet dies mit einer Härtung der Autorisierung und rückt MCP näher an die Sicherheitshaltung, die Enterprise-Deployments verlangen.

Die Sicherheitshaltung verschiebt sich zusammen mit dem Transport. Eine zustandslose Anfrage, die jede Instanz bedienen kann, hebt die Messlatte für die Autorisierung pro Anfrage, und das Release antwortet mit gehärteten Auth-Regeln sowie den Mcp-Name- und Mcp-Method-Headern, die einem Gateway die Durchsetzung von Policies am Rand erlauben. Für Multi-Tenant-Plattformen bedeutet dies, dass Autorisierungsentscheidungen auf Daten innerhalb jeder Anfrage reisen statt auf einer vertrauten Session, die einmal beim Verbindungsaufbau etabliert wurde, ein Modell, das Zero-Trust-Gateways und Audit-Logging deutlich entgegenkommt.

Rückwärtskompatibilität reist innerhalb der SDKs. Neue Clients fallen auf den Initialize-Handshake zurück, sobald sie einen Server auf der Revision 2025-11-25 oder früher erreichen, sodass bestehende Server weiter Traffic bedienen. Python-v2-Server verarbeiten beide Protokollrevisionen aus einem einzigen Endpoint zur gleichen Zeit. Die Spezifikation führt zudem eine Feature-Lifecycle-Policy mit 12-monatigen Deprecation-Fenstern zwischen der Markierung eines Features als veraltet und seiner Entfernung ein, was Implementierern eine planbare Startbahn für jede künftige Änderung gibt.

Die Entscheidung für die Engineering-Leitung

Die konkrete Entscheidung vor der Engineering-Leitung ist der Upgrade-Zeitplan. Server, die auf dem alten Handshake aufbauen, werden über den Fallback-Pfad mit neuen Clients interoperieren, sodass die Produktion über den 28. Juli hinaus lebendig bleibt. Die Aktion für dieses Quartal gliedert sich in drei Schritte: die zum eigenen Stack passende Tier-1-Beta beziehen, einen Testserver gegen den Release Candidate aufsetzen und prüfen, dass die Routing-Schicht die Header Mcp-Method und Mcp-Name weiterreicht. Teams, die MCP im großen Maßstab betreiben, gewinnen am meisten, weil das Ablegen von Sticky-Sessions und geteilten Session-Stores den Load Balancer vereinfacht und echtes horizontales Autoscaling freischaltet. Behandle die stabilen Tier-1-Releases als Freigabesignal und den Fallback-Pfad als Brücke statt als Ziel. Kartiere die Migration jetzt, validiere innerhalb des Vier-Wochen-Fensters und plane den Cutover, sobald deine Tier-1-SDK ein stabiles Release erreicht.