MCP wird stateless: Sessions weichen expliziten State-Handles

TL;DR

TL;DR: Der MCP-Spec-Release-Candidate vom 28. Juli 2026 (SEP-2567, SEP-2575) entfernt Mcp-Session-Id und den initialize-Handshake — Server werden protokollseitig zustandslos, Zustand wandert in explizite, vom Tool zurückgegebene Handles (z. B. basket_id). Das macht MCP-Server hinter einem gewöhnlichen Round-Robin-Load-Balancer betreibbar, ohne Sticky Sessions oder geteilten Session-Store. Es ist ein Breaking Change ohne Deprecation-Fenster; laut SEP-2567 sind rund 3,7% der Server-Implementierungen mit session-gebundenem Zustand direkt migrationspflichtig. Parallel ist die Enterprise-Managed-Authorization-Extension (ID-JAG, erste Umsetzung: Okta) stabil geworden — Single-Login über alle firmenweiten MCP-Server statt wiederholter Autorisierungs-Prompts.

Warum Sessions bislang ein Problem waren

Die MCP-Spezifikation definierte Sessions bislang auf Protokollebene: Beim ersten Kontakt schickt ein Client wie Claude ein initialize, der Server antwortet mit seinen Capabilities und einer Session-ID im Mcp-Session-Id-Header. Diese ID scoped seitdem fünf Kategorien von Zustand — verhandelte Capabilities, Elicitation/Sampling-Zwischenzustand, Application-State (das Lehrbuchbeispiel: ein Warenkorb, der implizit pro Session existiert), variable Listen-Endpunkte (tools/list, resources/list, prompts/list können pro Session unterschiedlich ausfallen) und Resource-Subscriptions.

Das Problem laut SEP-2567: Die Lebensdauer einer Session ist in der Praxis völlig uneinheitlich. ChatGPT und (inzwischen) Claude.ai behandeln sie pro Tool-Call, Desktop- und IDE-Clients pro Anwendungsstart, Web-Clients pro Seitenaufruf — und fast kein Client nimmt eine Session nach einem Verbindungsabbruch wieder auf. Server können unter diesen Bedingungen keine verlässlichen zustandsbehafteten Workflows entwerfen, weil unklar bleibt, was eine „Session“ im jeweiligen Deployment überhaupt bedeutet. Und operativ kommt hinzu: Ein Server-Fleet hinter einem Load Balancer muss entweder Sticky Routing auf eine feste Instanz erzwingen oder Session-Zustand zwischen allen Instanzen teilen — beides zusätzliche Infrastruktur, die mit der eigentlichen Aufgabe des Servers nichts zu tun hat.

SEP-2567: Explizite State-Handles statt Session-IDs

Der Kern der Änderung: Der Mcp-Session-Id-Header verschwindet ersatzlos aus der Spezifikation. An seine Stelle tritt ein Muster, das mehrere produktive Remote-MCP-Server längst informell nutzen — Linear, Notion, GitHub und Stripe geben schon heute IDs zurück (Issue-ID, Page-ID, PR-Nummer, Customer-ID), die nachfolgende Tool-Aufrufe als gewöhnliches Argument mitschicken. SEP-2567 macht dieses Muster zum offiziellen Standard: Handles sind keine neue Protokoll-Konstruktion, sondern gewöhnliche Strings in Tool-Ergebnissen und -Argumenten.

Der Ablauf am Beispiel eines Warenkorbs

// Schritt 1: Zustand anlegen, Handle zurückbekommen
// → tools/call
{ "name": "create_basket", "arguments": {} }

// ← result
{ "content": [{ "type": "text", "text": "Created basket bsk_a1b2c3" }],
  "structuredContent": { "basket_id": "bsk_a1b2c3" } }

// Schritt 2: Handle durch nachfolgende Aufrufe fädeln
// → tools/call
{ "name": "add_item",
  "arguments": { "basket_id": "bsk_a1b2c3", "sku": "shoes" } }

// Schritt 3: Finale Operation mit demselben Handle
// → tools/call
{ "name": "checkout", "arguments": { "basket_id": "bsk_a1b2c3" } }

Der Handle bsk_a1b2c3 ist ein gewöhnlicher String in structuredContent — landet automatisch im Chat-Verlauf, lässt sich über Verbindungs- und Session-Grenzen hinweg weiterreichen und ist reine Tool-Daten, kein Protokoll-Feld. Das löst gleich drei Probleme des alten Modells: Die Lebensdauer wird explizit in der Tool-Beschreibung dokumentiert („basket_id läuft nach 24h Inaktivität ab“), Listen-Endpunkte dürfen nur noch vom Auth-Kontext abhängen statt vom Verbindungszustand — Clients können tools/list-Resultate also über Subagenten hinweg cachen —, und die Kardinalität ist nicht mehr auf eins pro Session fixiert: Ein Orchestrator kann einen gemeinsamen Warenkorb für alle Subagenten anlegen oder für jeden Subagenten eine eigene Browser-Instanz — das Modell entscheidet pro Zustand, was geteilt und was isoliert wird.

Was sonst noch im RC steckt

Die Session-Entfernung ist die auffälligste, aber nicht die einzige Änderung im Release Candidate vom 28. Juli:

• Kein initialize-Handshake mehr (SEP-2575): Protokollversion, Capabilities und Client-Info wandern als _meta-Feld in jede einzelne Anfrage statt in eine separate Verhandlung zu Beginn. Server können Capabilities stattdessen über eine neue server/discover-Methode offenlegen.
• Routing über Header statt Body-Inspection: Die neuen Mcp-Method- und Mcp-Name-Header erlauben Load Balancern und Gateways, Traffic zu routen, ohne den Request-Body zu parsen.
• Tasks als Extension statt Core-Feature: Die bisher experimentelle Tasks-API wird zur eigenständigen Extension und komplett um das zustandslose Modell herum neu gebaut; tasks/list fällt weg, Clients steuern über tasks/get, tasks/update, tasks/cancel.
• Drei Deprecations mit mindestens 12 Monaten Übergangsfrist: Roots (ersetzt durch Tool-Parameter/Resource-URIs/Konfiguration), Sampling (ersetzt durch direkte LLM-Provider-API-Integration) und Logging (ersetzt durch stderr bei stdio-Transporten bzw. OpenTelemetry).
• Sechs Authorization-SEPs ziehen die Autorisierung näher an OAuth-2.0-/OpenID-Connect-Praxis heran, unter anderem verpflichtende iss-Validierung nach RFC 9207.
• Fehlercode-Änderung: Fehlende Ressourcen liefern jetzt den JSON-RPC-Standardcode -32602 statt des MCP-eigenen -32002 — wer auf den Literalwert matcht, muss seinen Code anpassen.

Sicherheitsimplikationen der Handles

Ein Handle ist kein Geheimnis mehr im Sinne einer Session-ID, die nur Client und Server kennen — er landet in Chat-Verläufen, Subagent-Prompts, Copy-Paste-Puffern und Browser-Historien. SEP-2567 macht die Konsequenz explizit: Für authentifizierte Server gilt „Besitz des Handles ist nicht gleich Autorisierung“ — jeder Aufruf muss die Kombination aus Handle und Auth-Kontext validieren, analog dazu, wie Google Docs den Zugriff über eine ACL statt über die Geheimhaltung der Dokument-ID steuert. Für unauthentifizierte Server (Bearer-Token-Modell) empfiehlt die SEP mindestens 128 Bit kryptografische Entropie (UUIDv4 oder 22+ Base64-Zeichen), keine Ableitung aus vorhersagbaren Eingaben und eine begrenzte Lebensdauer — vergleichbar mit „Jeder mit dem Link“-Freigabe-URLs oder Passwort-Reset-Tokens. Wer eigene MCP-Server mit zustandsbehafteten Tools betreibt, sollte diese beiden Regeln als Minimalstandard behandeln, nicht als Option.

Enterprise-Managed Authorization: Single-Login über alle MCP-Server

Parallel zur Session-Änderung ist die Enterprise-Managed-Authorization-Extension (EMA) stabil geworden — eine Antwort auf ein häufig genanntes Problem in Unternehmens-Deployments: wiederholte Autorisierungs-Prompts, sobald mehrere MCP-Server im Spiel sind. Technisch nutzt EMA einen Identity Assertion JWT Authorization Grant (ID-JAG), den der Authorization-Server des MCP-Servers gegen ein Access-Token eintauscht — die Autorisierungsentscheidung wandert damit vom einzelnen Nutzer bzw. Server in den unternehmensweiten Identity-Provider. Wichtig ist die Abgrenzung: Die Identity-Schicht entscheidet, ob ein Client sich überhaupt mit einem Server verbinden darf, inspiziert aber nicht den laufenden MCP-Traffic — sie ersetzt keine separate Policy-Durchsetzung für sicherheitskritische Laufzeitentscheidungen. Okta ist der erste Identity-Provider mit Unterstützung (über dessen Cross-App-Access-Ansatz); auf Client-Seite unterstützen bereits Claude, Claude Code und Cowork sowie Visual Studio Code, auf Server-Seite unter anderem Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase, Slack ist in Arbeit. Identity-Provider ohne EMA-Unterstützung benötigen weiterhin einen Fallback-Auth-Pfad — das Protokoll ist additiv, kein Zwang.

Was das für Betreiber eigener MCP-Server bedeutet

SEP-2567 selbst beziffert die Migrationslast: Rund 90% aller Server-Implementierungen referenzieren Sessions gar nicht und sind nicht betroffen. Weitere 6,3% betreffen reine SDK-/Transport-Interna (Session-Routing in der TypeScript-SDK, sessionIdGenerator-Option), die mit dem Umstieg auf die zustandslose SDK-Transport-Variante ohnehin entfallen. Konkret handeln müssen die verbleibenden rund 3,7%: Wer Application-State an die Session gebunden hat (2,5%), muss auf explizite Handles oder den Auth-Principal umstellen. Wer Proxies/Gateways mit Sticky Routing auf Session-Basis betreibt (0,7%), muss auf Routing nach Auth-Principal oder einen selbst ausgestellten Gateway-Header wechseln. Wer OAuth-Flows (PKCE, JWT) an die Session gebunden hat (0,5%), braucht einen serverseitig generierten Nonce im state-Parameter des OAuth-Flows.

Wichtig: Es gibt kein Deprecation-Fenster — dies ist ein Breaking Change per Protokollversion. Server auf der alten Version sprechen weiter das alte Protokoll, neuere sprechen das neue; die Versions-Aushandlung hält beides parallel lauffähig, verhindert aber bewusst eine dauerhafte „Unterstützt beides“-Variante, die die Cache-Vorteile der neuen Listen-Semantik wieder zunichtemachen würde. Wer eigene MCP-Server betreibt, sollte vor dem 28. Juli prüfen, in welche der oben genannten Kategorien die eigene Implementierung fällt — und ob die verwendete SDK-Version die zustandslose Transport-Variante bereits unterstützt.

Fazit

Zwei unabhängige, aber am selben Tag sichtbar gewordene Änderungen treffen den Kern dessen, wie MCP-Server in Produktion betrieben werden: Sessions verschwinden aus dem Protokoll zugunsten expliziter, vom Modell sichtbarer State-Handles, und Autorisierung wandert für Unternehmensumgebungen in eine zentrale Identity-Schicht. Für die meisten Server-Betreiber bedeutet das ein SDK-Update ohne Codeänderung; für die Minderheit mit session-gebundenem Application-State, Sticky-Routing-Gateways oder session-gebundenen OAuth-Flows ist es ein Pflichttermin vor dem 28. Juli — ohne Übergangsfrist.

Quellen

• TechCrunch — AI's most important protocol is getting a little bit easier to use
• InfoQ — MCP Enterprise-Managed Authorization
• Arcade — MCP Going Stateless
• MCP — SEP-2567: Sessionless MCP via Explicit State Handles
• MCP Blog — The 2026-07-28 MCP Specification Release Candidate
• GitHub — SEP-2567 Pull Request
• GitHub — SEP-2575: Make MCP Stateless