MCP wird stateless, was die 2026-07-28 Spec ändert und was Du vorher wissen musst

Die Model-Context-Protocol-Leute haben am 21. Mai 2026 den Release Candidate für die Spec-Version 2026-07-28 eingefroren. Final wird sie am 28. Juli. Das ist die größte Änderung am Protokoll seit dem allerersten Launch, und wenn Du selbst MCP-Server betreibst oder gerade L4 und L6 durcharbeitest, lohnt es sich das jetzt zu verstehen und nicht erst wenn alle SDKs umstellen. Sechs Specification Enhancement Proposals arbeiten zusammen, um aus MCP ein zustandsloses Protokoll zu machen. Klingt akademisch, hat aber sehr konkrete Folgen für Deployment, Auth und Deinen Code. Ich gehe die zehn Punkte durch, die wirklich zählen.

Schritt 1, der Kern in einem Satz

MCP ist jetzt stateless auf der Protokoll-Ebene. Bis 2025-11-25 musstest Du eine Session aufbauen, bevor Du überhaupt ein Tool aufrufen konntest. Diese Session band den Client an genau die Server-Instanz, die sie ausgestellt hat. Mit 2026-07-28 ist jeder Request in sich abgeschlossen und kann auf jeder beliebigen Instanz landen.

Das ist der eine Gedanke, von dem alles andere abhängt. Wenn Du ihn verinnerlicht hast, ergeben sich die anderen neun Punkte fast von selbst.

Schritt 2, Handshake und Session sind weg

Der initialize/initialized Handshake wurde gestrichen (SEP-2575). Protokoll-Version, Client-Info und Capabilities, die früher einmal beim Verbindungsaufbau ausgetauscht wurden, reisen jetzt in _meta auf jedem einzelnen Request mit. Wenn ein Client die Server-Fähigkeiten vorab braucht, holt er sie über die neue Methode server/discover.

Der Mcp-Session-Id Header und die Session, die daran hing, sind ebenfalls weg (SEP-2567). So sieht der Unterschied aus. Früher, mit Session:

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"}}}

Jetzt, ein einziger selbsterklärender Request:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Schritt 3, was das für Dein Deployment bedeutet

Hier wird es praktisch. Ein remote MCP-Server brauchte bisher sticky Sessions, einen geteilten Session-Store und teilweise Deep Packet Inspection am Gateway. All das fällt weg. Der gleiche Server läuft jetzt hinter einem ganz normalen Round-Robin-Load-Balancer.

Wenn Du Deinen Server bisher horizontal skaliert hast und Dir die sticky Sessions Bauchschmerzen gemacht haben, ist das die beste Nachricht der ganzen Spec. Du wirfst Infrastruktur raus, statt welche dazuzubauen.

Schritt 4, Zustand behalten ohne Session

Stateless heißt nicht, dass Deine Anwendung keinen Zustand mehr haben darf. Server, die über Aufrufe hinweg Zustand brauchen, machen das jetzt so, wie HTTP-APIs es schon immer gemacht haben. Du gibst aus einem Tool ein explizites Handle zurück, zum Beispiel ein basket_id oder browser_id, und das Modell reicht es bei späteren Aufrufen als ganz normales Argument wieder rein.

Das ist mehr als nur ein Ersatz für Session-State. Das Modell kann diese Handles über mehrere Tools hinweg kombinieren und zwischen Schritten weiterreichen. Der Zustand ist sichtbar für das Modell, statt versteckt in Transport-Metadaten. In der Praxis ist das oft die saubere Lösung.

Schritt 5, neue Routing-Header

Der Streamable-HTTP-Transport verlangt jetzt die Header Mcp-Method und Mcp-Name (SEP-2243). Damit können Load-Balancer, Gateways und Rate-Limiter auf die Operation routen, ohne den Body zu lesen. Wichtig für Dich, wenn Du eigene Infrastruktur baust. Der Server lehnt Requests ab, bei denen Header und Body sich widersprechen. Setz die Header also korrekt, sonst kassierst Du Fehler.

Schritt 6, Listen werden cachebar

List- und Resource-Read-Ergebnisse tragen jetzt ttlMs und cacheScope (SEP-2549), modelliert nach HTTP Cache-Control. Dein Client weiß damit genau, wie lange eine tools/list Antwort frisch ist und ob er sie über mehrere User teilen darf. Ein dauerhaft offener SSE-Stream ist nicht mehr der einzige Weg, um mitzubekommen, dass sich eine Liste geändert hat.

Dazu kommt W3C Trace Context in _meta (SEP-414). Die Key-Namen traceparent, tracestate und baggage sind jetzt fix in der Spec, sodass ein Trace von der Host-App durch den Client, den Server und alles dahinter als ein einziger Span-Baum in einem OpenTelemetry-Backend auftaucht.

Schritt 7, Extensions werden first-class

Extensions gab es schon in 2025-11-25, aber ohne formalen Prozess. SEP-2133 ändert das. Extensions haben jetzt reverse-DNS-IDs, werden über eine extensions Map in den Capabilities ausgehandelt, leben in eigenen ext-* Repositories und versionieren unabhängig von der Spec.

Zwei offizielle Extensions sind direkt dabei. MCP Apps (SEP-1865) lässt Server interaktive HTML-Oberflächen ausliefern, die der Host in einem gesandboxten iframe rendert. Und Tasks, das in 2025-11-25 noch ein experimentelles Core-Feature war, wird zur Extension. Falls Du gegen die alte experimentelle Tasks-API gebaut hast, musst Du migrieren. tasks/list ist raus, weil es sich ohne Sessions nicht sicher scopen lässt. Stattdessen treibst Du einen Task mit tasks/get, tasks/update und tasks/cancel.

Schritt 8, Auth wird strenger

Sechs SEPs härten die Autorisierung, damit sie näher an echten OAuth-2.0- und OpenID-Connect-Deployments liegt. Zwei davon solltest Du kennen.

Clients müssen jetzt den iss Parameter auf Authorization-Responses validieren, nach RFC 9207 (SEP-2468). Das ist eine billige Absicherung gegen eine Klasse von Mix-up-Angriffen, die im MCP-Muster mit einem Client und vielen Servern besonders häufig ist. In einer künftigen Version werden Clients Responses ohne iss ablehnen, also fang jetzt an es mitzuliefern. Außerdem deklarieren Clients ihren application_type bei der Dynamic Client Registration (SEP-837). Das verhindert den häufigen Fall, dass ein Authorization-Server einen Desktop- oder CLI-Client fälschlich als "web" einstuft und seine localhost-Redirect-URI ablehnt.

Schritt 9, Deprecations und ein Fehlercode der sich ändert

Drei Core-Features werden deprecated unter der neuen Lifecycle-Policy (SEP-2577). Roots, Sampling und Logging. Das sind reine Annotation-Deprecations, sie funktionieren weiter, mindestens noch ein Jahr lang. Die empfohlenen Nachfolger sind Tool-Parameter und Resource-URIs statt Roots, direkte Integration mit den LLM-Provider-APIs statt Sampling und stderr beziehungsweise OpenTelemetry statt Logging.

Ein Detail, das Dich beißen kann, wenn Du nicht aufpasst. Der Fehlercode für eine fehlende Resource wechselt vom MCP-eigenen -32002 auf den JSON-RPC-Standard -32602 Invalid Params (SEP-2164). Wenn Dein Client auf den Literal-Wert -32002 matcht, pass das an. Und inputSchema und outputSchema sind jetzt volles JSON Schema 2020-12 (SEP-2106), inklusive oneOf, anyOf, $ref und $defs. Externe $ref URIs darfst Du allerdings nicht automatisch auflösen.

Schritt 10, was Du jetzt konkret tun solltest

Du hast ein Zeitfenster von zehn Wochen zwischen RC und Final. Genau dafür ist es gedacht. Tier-1-SDKs sollen in diesem Fenster Support ausliefern. Wenn Du einen Server betreibst, hol Dir die Draft-Spec und das Changelog gegen 2025-11-25 und teste Deinen Server gegen den RC. Vor allem die drei Stellen, die echte Breaking Changes sind. Der fehlende Handshake, der weggefallene Session-Header und der geänderte Fehlercode.

Wenn Du gerade erst mit MCP anfängst, ist das hier kein Grund zur Panik. Die Grundkonzepte aus L4, Server, Client und Tools, bleiben exakt gleich. Was sich ändert, sitzt eine Ebene tiefer im Transport. Lern erst das Modell, dann die Transport-Details.

Was als nächstes

Wenn Du das Mentalmodell noch nicht sitzen hast, geh zuerst durch Was ist MCP. Wer einen eigenen Server plant, findet den Einstieg in MCP-Server planen. Für den Auth-Teil, der sich mit dieser Spec verschärft, ist das Playbook MCP-Server-Auth mit OAuth 2.1 der nächste Schritt. Und wenn Du fertig bist und veröffentlichen willst, hilft MCP-Server publishen.

Quelle

• Offizielle Ankündigung mit allen SEP-Nummern: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
• Draft-Spec und Changelog gegen 2025-11-25: https://modelcontextprotocol.io