Ist MCP jetzt stateless? Was du an deinem MCP-Server ändern musst

Ja. Seit der Spezifikation 2026-07-28 ist MCP auf Protokollebene stateless. Der Initialize-Handshake und Mcp-Session-Id sind entfernt. Jeder Request bringt Protokollversion, Client-Identität und Capabilities selbst mit. Ein Remote Request kann dadurch ohne Sticky Routing bei jeder gesunden Serverinstanz landen.

Eine wichtige Einschränkung bleibt: Stateless MCP bedeutet nicht stateless Software. Dein Warenkorb, Browser-Job, Freigabeprozess oder bezahlter Auftrag darf weiterhin dauerhaften State haben. Dieser State muss jetzt explizit, adressierbar und abgesichert in deiner Anwendung liegen, statt unsichtbar an einer MCP-Transport-Session zu hängen.

Dieser Leitfaden beantwortet die Transport- und Migrationsfrage. Für Permissions und Tenant Isolation nutze unsere separate Enterprise-MCP-Autorisierungsarchitektur. Warum der Schutz tiefer als das Protokoll greifen muss, erklären wir in MCP ist keine vollständige Sicherheitsgrenze.

Wie lautet die kurze Antwort?

MCP 2026-07-28 ist ein Protokoll für stateless, in sich geschlossene Requests. Protokoll-State ist weg. Application State bleibt erlaubt und oft notwendig.

Die offizielle Spezifikation nennt „stateless, self-contained requests“ und Capability Negotiation pro Request als Eigenschaften des Basisprotokolls. Bei Streamable HTTP ist jede Nachricht ein neuer POST. Die Antwort kommt als einzelnes JSON-Objekt oder als SSE-Stream, der nur zu diesem Request gehört. Der frühere GET-Stream, Protokoll-Sessions, Mcp-Session-Id und resumable SSE gehören nicht mehr zu dieser Revision.

Was hat sich mit MCP 2026-07-28 geändert?

Die vollständige Liste der Breaking Changes steht im offiziellen Changelog zu MCP 2026-07-28. Dort findest du auch das neue Feld resultType, das Ende von Stream Resumability, JSON Schema 2020-12, neue Error Codes und die Deprecation von Roots, Sampling, Logging sowie altem HTTP+SSE.

Darf ein stateless MCP-Server noch etwas speichern?

Ja. Ein späterer Request darf nur nicht von unsichtbarem Speicher einer Protokoll-Session abhängen.

Öffnet ein Tool einen Browser und soll ein zweites Tool dieselbe Automation fortsetzen, kann die erste Antwort eine zufällige, opake browser_id liefern. Der Client gibt dieses Handle beim nächsten Call mit. Nach Prüfung von Identität und Ablauf löst der Server das Handle in einem Durable Object, einer Datenbank oder einem passenden Store auf. Der Workflow ist stateful, der MCP Request bleibt in sich geschlossen.

• Ein Request: Halte State in lokalen Variablen und liefere das Ergebnis direkt.
• Mehrere direkte Round Trips: Nutze signiertes oder verschlüsseltes requestState mit input_required. Binde es an Identität, ursprüngliche Operation und Ablaufzeit.
• Laufende Jobs: Nutze die MCP Tasks Extension mit dauerhafter taskId.
• Business-Objekte: Liefere Handles wie order_id, basket_id oder document_id und autorisiere jede spätere Verwendung neu.
• Änderungsbenachrichtigungen: Nutze subscriptions/listen. Der offene SSE-Stream gehört zum Request und ist keine neue Protokoll-Session.

Packe keine Secrets oder veränderbaren Business-Daten in ein lesbares Bearer Handle. Nutze bevorzugt opake IDs oder authentifizierte, verschlüsselte State Tokens mit engen Grenzen für Größe, Audience und Ablauf.

Muss jeder MCP-Server migriert werden?

Jede Implementierung braucht ein Audit, der Aufwand unterscheidet sich aber deutlich.

Ein Server kann im Betrieb zustandslos sein und trotzdem ein Legacy-Protokoll sprechen. Umgekehrt kann er die neue stateless Revision unterstützen und dennoch Application State speichern. Prüfe Wire Behavior und Datenlebenszyklus getrennt.

Was solltest du an deinem eigenen MCP-Server ändern?

1. Finde versteckten Connection State. Suche nach Session Maps, Sticky Cookies, Mcp-Session-Id, wiederverwendeten Transport-Objekten, Tool-Listen pro Verbindung und SSE Event Stores. Ordne alles als Protokoll-State, transienten Request State oder dauerhaften Business State ein.
2. Implementiere moderne Discovery. Dein Server muss server/discover unterstützen. Liefere Versionen, Capabilities, Server Info, Instructions, ttlMs und cacheScope. Nutze selbst gemeldete Server Info nie als Sicherheitsentscheidung.
3. Validiere Metadaten pro Request. Fordere Version und Client-Daten in _meta. Bei HTTP brauchst du MCP-Protocol-Version, Mcp-Method und bei benannten Calls Mcp-Name. Bei Abweichungen zwischen Header und Body muss der Request mit HeaderMismatch scheitern.
4. Modernisiere und cache Ergebnisse. Normale Antworten brauchen resultType: "complete". Halte tools/list deterministisch. Setze ehrliche Werte für ttlMs und cacheScope, besonders wenn Autorisierung die sichtbaren Tools verändert.
5. Ersetze impliziten State durch Handles. Handles müssen unerratbar, an die Identität gebunden, gescoped und widerrufbar sein. Mutationen brauchen Idempotenz, damit ein Retry nicht doppelt bezahlt, sendet oder löscht.
6. Unterstütze beide Epochen bewusst. Ein Dual-Era-Server kann moderne Requests stateless bedienen und Legacy-Clients weiter über initialize aufnehmen. Isoliere diesen Pfad, miss seine Nutzung und definiere ein Enddatum.
7. Teste die Architektur. Schicke aufeinanderfolgende Calls hinter echtem Round-Robin-Routing an verschiedene Instanzen. Teste fehlende und abweichende Header, unbekannte Versionen, abgelaufene Handles, Replay, Abbruch, Retry und Cross-Tenant-Zugriff.

Die Streamable-HTTP-Spezifikation definiert Header und Mismatch-Verhalten. Vor einem harten Cutover solltest du außerdem die offizielle Kompatibilitätsmatrix lesen.

Was haben wir an unserem eigenen Wavect MCP geändert?

Am 31. Juli 2026 haben wir dieselbe Checkliste auf unsere Cloudflare Pages Function angewendet und direkt umgestellt, weil wir keine Legacy Clients erhalten mussten.

• Im Prozess und Protokoll stateless: Der Handler hält keine In-Memory Session Map und akzeptiert jetzt nur noch in sich geschlossene Requests nach 2026-07-28.
• Business State ist explizit: Commerce Tools verwenden Quote IDs, Order IDs, Access Tokens und Idempotency Keys statt Transport-Sessions.
• Moderne Discovery ist live: server/discover liefert Version, Capabilities, Server Info, Instructions und Cache-Metadaten.
• Der HTTP Contract wird erzwungen: Requests benötigen MCP-Protocol-Version, Mcp-Method und bei Tool Calls Mcp-Name. Header und Body werden abgeglichen, Origins explizit geprüft.
• Responses haben die 2026-Form: Discovery, Listen und Tool Calls enthalten resultType. Deterministische Listen liefern zusätzlich ehrliche Cache-Metadaten.
• Der Legacy Lifecycle ist entfernt: initialize, ping und notifications/initialized liefern Method Not Found, statt einen alten Vertrag still weiterzuführen.

„Wir speichern keine MCP-Sessions“ reicht also nicht als Migrationsprüfung. Laufzeit, Protokollversion und Response Schema können unterschiedlich weit sein. Bei unserem Server war das Redesign des Business State klein. Wire Contract, Security Checks und Conformance Tests waren die eigentliche Arbeit.

"Stateless MCP entfernt versteckten Transport-State, nicht dauerhafte Workflows. Mach State explizit, authentifiziert und sicher wiederholbar."

Wie sollte der Production Rollout aussehen?

1. Erfasse aktuelle Client-Versionen, Transportwege, Session Features und Fehlerraten.
2. Schreibe Conformance Tests für moderne Requests und Results, bevor du Production Traffic änderst.
3. Deploye je nach Client-Kontrolle einen Dual-Era-Endpunkt oder einen getrennten modernen Endpunkt.
4. Leite interne und Canary Clients auf den neuen Pfad. Erzwinge verschiedene Instanzen bei aufeinanderfolgenden Calls.
5. Beobachte Versionsfehler, Header Mismatches, Retries, Latenz, doppelte Side Effects und fehlgeschlagene Autorisierung.
6. Veröffentliche Migrationsdatum und Rollback Window. Lösche Legacy Storage nicht nach einem einzelnen SDK-Test.
7. Entferne Sticky Routing und Session Stores erst, wenn Telemetrie keine unterstützten Legacy-Clients mehr zeigt.

Cloudflare beschreibt einen stateless Handler und eine gestufte Migration für Session Features in seinem Migrationsleitfaden für MCP SDK v2. Das Modell ist auch für andere Runtimes hilfreich.

Was solltest du einen MCP-Entwicklungspartner fragen?

• Welche Protokollversionen und Client-Epochen unterstützt der produktive Server?
• Welcher State ist requestlokal, welcher dauerhaft und welcher hängt noch an einer Transport-Session?
• Wie werden Handles an Identität, Tenant, Operation und Ablauf gebunden?
• Wie verhindert Idempotenz doppelte Payments, Writes und externe Side Effects?
• Kann das Team beweisen, dass zwei aufeinanderfolgende Calls auf unterschiedlichen Instanzen funktionieren?
• Wie werden HTTP Header am Gateway und Origin gegen den JSON Body validiert?
• Was wird wie lange gecacht, und können private Tool-Listen in einen Shared Cache gelangen?
• Welche deprecated Features sind noch aktiv, und wie sieht ihr Ersatz aus?
• Welche Evidenz schließt den Legacy-Pfad: Telemetrie, Client-Inventar, Rollback-Test und Abschaltdatum?

Steht im Angebot nur „SDK aktualisieren“, fehlt der Kern. Ein belastbares Deliverable enthält State-Inventar, Kompatibilitätsentscheidung, Threat Model, Migrationstests, Canary-Evidenz und Rollback-Plan.

Häufige Fragen

Ist MCP jetzt vollständig stateless?

Der Protokollkern 2026-07-28 ist stateless. Anwendungen dürfen mit Handles, Storage, Tasks und Request State weiterhin dauerhaften State halten.

Gibt es Streamable HTTP noch?

Ja. Es bleibt der Standard für Remote Server. Jede Nachricht ist aber ein eigener POST; GET-Stream und Protokoll-Session sind entfernt.

Muss ich noch initialize senden?

Nicht bei einem modernen Request. Nutze Metadaten pro Request und optional server/discover. Ein Dual-Era-Server kann initialize für Legacy-Clients weiterhin beantworten.

Brauche ich noch Redis oder Durable Objects?

Nicht für MCP-Protokoll-Sessions. Für Jobs, Orders, Browserinstanzen, Locks, Rate Limits und anderen Application State können sie weiterhin sinnvoll sein.

Kann ich Sticky Sessions sofort entfernen?

Erst wenn moderne Requests über verschiedene Instanzen funktionieren und deine Telemetrie bestätigt, dass kein unterstützter Client mehr vom Legacy-Pfad abhängt.

Primärquellen

• Model Context Protocol Spezifikation 2026-07-28
• MCP 2026-07-28 Changes und Deprecations
• MCP Streamable HTTP Transport
• MCP Server Discovery
• MCP Tools, Caching und Multi Round-Trip Results
• MCP Tasks Extension
• GitHub MCP Server Support für die stateless Spezifikation
• Cloudflare Migration zu stateless MCP Handlern