MCP wirft den Session-State raus

Am 28.07.2026 hat die Agentic AI Foundation die neue Spezifikation des Model Context Protocol veröffentlicht. Sie heißt schlicht 2026-07-28 und ersetzt die Version 2025-11-25. Es ist die größte Änderung seit dem Start, und sie betrifft genau die Stelle, an der viele MCP-Server im Betrieb weh tun: den Zustand.

Die Kurzfassung: MCP verhält sich jetzt wie ein normaler HTTP-Service. Kein Handshake, keine Session-ID, kein Sticky Routing.

Was konkret weg ist

Bisher lief jede MCP-Verbindung so: Der Client schickt initialize, der Server antwortet, der Client bestätigt mit initialized. Danach gehört die Verbindung zu einer Session, die über den Header Mcp-Session-Id identifiziert wird. Alle weiteren Requests müssen bei derselben Serverinstanz landen, weil dort der Sessionzustand liegt.

Beides ist gestrichen (SEP-2575 für den Handshake, SEP-2567 für den Header). Dabei verschwinden zwei verschiedene Dinge, die man auseinanderhalten sollte.

Der Handshake hatte die Aufgabe, einmal zu Beginn auszuhandeln, worauf sich beide Seiten einigen: Protokollversion, Identität und Fähigkeiten. Diese Aushandlung wandert in jeden einzelnen Request. Die Version steht im _meta-Feld unter dem Key io.modelcontextprotocol/protocolVersion, auf HTTP zusätzlich im Header MCP-Protocol-Version. Der Server entscheidet pro Request, ob er sie bedient. Kann er nicht, kommt ein UnsupportedProtocolVersionError mit der Liste der unterstützten Versionen zurück, und der Client versucht es erneut.

Der Sessionzustand dagegen wird nicht ersetzt, er entfällt ersatzlos. Die Protokollversion tritt nicht an seine Stelle, sie ist nur der Teil der alten Aushandlung, der jetzt mitreisen muss. Der Zustand selbst ist weg, weil das Protokoll ihn nicht mehr braucht: Jeder Request bringt alles mit, was zu seiner Bearbeitung nötig ist. Genau deshalb ist es egal, welche Instanz ihn beantwortet.

flowchart TB
  subgraph legacy["Bis 2025-11-25"]
    L1["Client"] -->|"initialize,<br/>dann Session-ID"| L2["Instanz A"]
    L2 --- L3["Sessionzustand<br/>klebt an Instanz A"]
  end
  subgraph modern["Ab 2026-07-28"]
    M1["Client"] -->|"Request bringt<br/>alles selbst mit"| M2{"Load<br/>Balancer"}
    M2 --> M3["Instanz A"]
    M2 --> M4["Instanz B"]
    M2 --> M5["Instanz C"]
  end
  legacy ~~~ modern
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC
  class M2 decision
  class M3,M4,M5 success

Für den Betrieb ist das der eigentliche Gewinn. Ein MCP-Server läuft jetzt hinter einem gewöhnlichen Round-Robin-Load-Balancer, in beliebig vielen Replicas, ohne gemeinsamen Session-Store und ohne Klebeband in der Ingress-Konfiguration. Wer MCP-Server auf Kubernetes betreibt, kennt den Schmerz, den das wegnimmt.

Weil es keinen Handshake mehr gibt, an dem sich Fähigkeiten austauschen ließen, gibt es einen neuen Pflicht-Aufruf: server/discover. Server müssen ihn implementieren, Clients dürfen ihn nutzen, müssen aber nicht. Ein Client kann auch direkt losfeuern und den Versionsfehler abfangen.

Was noch drin ist

Vier weitere Änderungen sind für die Praxis relevant:

Multi Round-Trip Requests (MRTR, SEP-2322). Serverinitiierte Anfragen wie elicitation/create, sampling/createMessage und roots/list brauchten einen offenen Stream. Stattdessen antwortet der Server jetzt mit resultType: "input_required" und sagt, was er braucht. Nutzerbestätigung mitten im Tool-Call funktioniert damit ohne persistente Verbindung.

Header-basiertes Routing (SEP-2243). Die Header Mcp-Method und Mcp-Name sind Pflicht. Gateways und Web Application Firewalls können damit routen und filtern, ohne den JSON-Body zu parsen. Das ist der Punkt, der MCP für Firmen mit ernsthafter Netzwerkinfrastruktur überhaupt erst handhabbar macht.

Cachebare Listen (SEP-2549). Antworten von tools/list, prompts/list, resources/list und resources/read können ttlMs und cacheScope mitgeben. Weniger Roundtrips für Tool-Kataloge, die sich selten ändern.

Tasks als Extension (SEP-2663). Langlaufende Arbeit steckt nicht mehr experimentell im Kern, sondern in der Extension io.modelcontextprotocol/tasks, mit tasks/get und tasks/update per Polling. Dazu kommt ein Extensions-Framework, über das auch die servergerenderten UIs der MCP-Apps laufen (io.modelcontextprotocol/ui).

Bei der Autorisierung wird es strenger

Die Auth-Änderungen sind der Teil, den man nicht überlesen sollte, wenn ein eigener Server im Netz steht:

Neu ist außerdem "Enterprise Managed Authorization": MCP-Server lassen sich zentral über einen Identity Provider verwalten, statt dass jeder Nutzer sich einzeln bei jedem Server anmeldet. Das ist die Antwort auf die Frage, wie eine Firma 40 MCP-Server governen soll.

Warum trotzdem heute nichts kaputtgeht

Das klingt nach einem Breaking Change, der ein Wochenende kostet. Ist es aber nicht, jedenfalls nicht sofort. Die Spec definiert eine Kompatibilitätsschicht und unterscheidet drei Sorten von Implementierungen: modern (ab 2026-07-28), legacy (2025-11-25 und älter) und dual-era (beides).

Ein Server darf beide Welten gleichzeitig bedienen, sogar auf demselben Endpoint. Kommt ein Request mit modernem _meta, wird er zustandslos beantwortet. Kommt ein initialize, gelten die alten Regeln. Clients erkennen die Server-Generation über einen Probe-Aufruf: bei stdio ein server/discover, bei Streamable HTTP ein moderner Request, dessen 400 Bad Request ausgewertet wird. Das Ergebnis soll für die Lebensdauer des Serverprozesses beziehungsweise der Origin gecacht werden.

Wichtig für die Praxis ist, welche Kombinationen tatsächlich scheitern:

Die zweite Zeile ist die entscheidende: Solange die Clients dual-era sind, laufen alte Server weiter. Und genau das ist der Plan. Der Blogpost zu den Beta-SDKs formuliert es unmissverständlich: nichts bricht heute, und am 28. Juli bricht auch nichts.

Geregelt ist das Ganze über eine neue formale Feature-Lifecycle- und Deprecation-Policy. Deprecated Features bleiben mindestens zwölf Monate in der Spezifikation, bevor sie entfernt werden dürfen (in Ausnahmefällen mindestens 90 Tage). Aktuell deprecated: Roots, Sampling, Logging und der alte HTTP+SSE-Transport. Alles davon funktioniert weiter.

Was das für euch heißt

Die SDKs sind schon da, und zwar nicht mehr als Beta:

• Python: mcp liegt bei 2.0.0 stabil
• TypeScript: aufgeteilt in @modelcontextprotocol/core, @modelcontextprotocol/server und @modelcontextprotocol/client, jeweils 2.0.0. Das alte Bundle @modelcontextprotocol/sdk läuft auf der 1.x-Linie weiter (aktuell 1.30.0)
• Go und C# sind ebenfalls dabei, Rust hat Beta-Support

Die Prioritäten der Reihe nach:

1. Prüfen, ob euer Code auf Session-IDs baut. Wer Mcp-Session-Id für Zustand, Logging-Korrelation oder Rate Limiting benutzt hat, muss das anders lösen. Das ist die eine Stelle mit echtem Migrationsaufwand.
2. Nichts überstürzen. Bei Python und TypeScript ist der Sprung eine Major Version, bei Go und C# ist der Pfad sanfter. Ein bewusstes Upgrade zum passenden Zeitpunkt schlägt ein hektisches.
3. Die Auth-Punkte einzeln abklopfen, wenn ein eigener MCP-Server erreichbar im Netz steht. Die RFC-9207-Prüfung ist keine Fleißaufgabe, sie schließt eine echte Lücke.
4. Beim Betrieb den Gewinn abholen. Wenn ihr bisher wegen des Sessionzustands eine einzige Instanz gefahren habt oder Sticky Sessions konfigurieren musstet: das kann jetzt weg.

Was MCP überhaupt ist und wie die Bausteine zusammenspielen, steht in MCP: Wie KI-Tools miteinander reden. Die Sicherheitsseite vertieft MCP- und Connector-Sicherheit, die konkrete OAuth-Absicherung zeigt MCP-Server absichern: OAuth mit Spring AI.