MCP 2026-07-28: Was die zustandslose Spezifikation für bestehende MCP-Server bedeutet

Am 28. Juli 2026 ist die MCP-Spezifikation 2026-07-28 erschienen. Laut dem offiziellen Release-Blog wird das Model Context Protocol damit „from a bidirectional stateful protocol into a request/response stateless protocol“ umgebaut. Das klingt nach einem Thema für Protokoll-Entwickler. Für jeden, der einen MCP-Server betreibt, ist es aber eine konkrete Aufgabe: Der Handshake fällt weg, die Session-ID fällt weg, und Server müssen eine neue Methode anbieten.

Was MCP ist und wie es in Agentensysteme passt, erkläre ich hier nicht, dafür gibt es die Glossareinträge zu MCP und KI-Agent. Ich beantworte drei Fragen. Was ändert sich technisch? Muss ein bestehender Server migriert werden? Und was weiß man heute über n8n, das selbst als MCP-Server arbeiten kann? Wo eine Aussage nur meine Einschätzung oder nicht erprobt ist, steht das dabei.

Mich betrifft die Revision an zwei Stellen. Ich betreibe eine selbst gehostete MCP-Plattform in Python, die über Streamable HTTP mit OAuth hinter Caddy und Cloudflare läuft. Und eine Wissensbasis stellt ihre Suche über den MCP Server Trigger von n8n als lesendes Werkzeug bereit. Beim ersten System entscheidet mein eigener Code, beim zweiten n8n. Für diesen Beitrag wurde die neue Version außerdem an einem minimalen Testserver mit dem aktuellen Python SDK durchgespielt. Die Ergebnisse stehen weiter unten.

Was ändert sich mit MCP 2026-07-28 auf einen Blick?

Mit der Spezifikation 2026-07-28 wird MCP zustandslos: Handshake und Mcp-Session-Id entfallen, jeder Server muss server/discover und resultType liefern, Rückfragen laufen als Multi Round-Trip Requests, und Roots, Sampling, Logging, HTTP+SSE sowie Dynamic Client Registration sind deprecated. Fünf Änderungen betreffen bestehende Server direkt. So fassen es der Release-Blog vom 28.07.2026 und der offizielle Changelog zusammen. Stand dieses Beitrags ist der 21.10.2026.

1. Kein Handshake, keine Session. initialize, notifications/initialized und der Header Mcp-Session-Id entfallen (SEP-2575, SEP-2567).
2. Neue Pflichten für Server. Jeder Server muss server/discover implementieren. Jedes Result trägt das Pflichtfeld resultType.
3. Rückfragen ohne eigene Server-Anfragen. Multi Round-Trip Requests ersetzen die Anfragen, die bisher der Server an den Client schickte: Sampling, Elicitation und Roots (SEP-2322).
4. Neue Header und Cache-Felder. POST-Anfragen über Streamable HTTP tragen Mcp-Method und, je nach Methode, Mcp-Name (SEP-2243). Listen-Antworten und resources/read brauchen ttlMs und cacheScope (SEP-2549).
5. Deprecations mit Frist. Roots, Sampling, Logging, der HTTP+SSE-Transport und Dynamic Client Registration sind deprecated. Die neue Feature-Lifecycle-Policy sieht in der Regel mindestens zwölf Monate Übergang vor, für HTTP+SSE gilt eine Sonderfrist.

Was bedeutet „zustandslos“ bei MCP konkret?

Ein MCP-Server muss sich zwischen zwei Anfragen nichts mehr über den Client merken. Laut Changelog entfallen dafür der Handshake aus initialize und notifications/initialized (SEP-2575) sowie der Header Mcp-Session-Id (SEP-2567). Stattdessen trägt jede Anfrage Protokollversion und Client-Capabilities selbst im Feld _meta (Schlüssel io.modelcontextprotocol/protocolVersion und io.modelcontextprotocol/clientCapabilities). Zustandslos ist dabei das Protokoll, nicht zwingend die Anwendung: Braucht ein Server Zustand über mehrere Aufrufe hinweg, soll er laut Changelog eigene Handles ausgeben, die der Client als normale Tool-Argumente zurückschickt.

Bisher war die Reihenfolge fest: erst der Handshake, dann die eigentlichen Anfragen. Bei Streamable HTTP hielt die Session-ID diese Anfragen zusammen. Wer serverseitig etwas an die Sitzung gehängt hat, etwa die beim Start gemeldeten Fähigkeiten des Clients, verliert diesen Anker. Nach der neuen Spezifikation steht alles Nötige in der einzelnen Anfrage.

Mit 2026-07-28 entfällt außerdem die Wiederaufnahme abgebrochener SSE-Streams über Last-Event-ID. Bricht eine Verbindung ab, geht die laufende Anfrage verloren, und der Client muss sie als neue Anfrage mit neuer Request-ID stellen (Changelog). Wer lange laufende Werkzeuge anbietet, sollte deshalb prüfen, ob eine wiederholte Anfrage Schaden anrichten kann. Ein Werkzeug, das eine E-Mail verschickt, sollte sie beim zweiten Aufruf nicht noch einmal senden.

Meine Einschätzung, nicht gemessen: Für Remote-Server liegt der größte Gewinn im Betrieb. Ohne Session-ID muss ein Load Balancer eine Anfrage nicht mehr an die Instanz binden, die die Sitzung kennt. Das hilft aber nur, wenn der Server nicht selbst Zustand hält, zum Beispiel einen Cache pro Nutzer im Arbeitsspeicher.

Bei der Prüfung hilft eine Unterscheidung: Zustand im Agenten ist nicht dasselbe wie Zustand im MCP-Server. Mein Sprachagent Hermes hält Gesprächskontext und ein Langzeitgedächtnis, aber im Agenten selbst. Die Werkzeuge erreicht er als Client über MCP. Von der Spezifikation betroffen ist nur, was ein MCP-Server pro Session speichert.

Was kommt mit MCP 2026-07-28 neu dazu?

Die Revision bringt vier neue Pflichten und einen neuen Ablauf für Rückfragen.

server/discover als Pflichtmethode

Laut Changelog muss jeder Server server/discover implementieren, die Spezifikation schreibt dafür „MUST“. Im Testlauf weiter unten (Python SDK 2.3.0) enthielt die Antwort resultType, supportedVersions, ttlMs, cacheScope und capabilities. Die vollständige Struktur steht in der Spezifikation. Wer sein SDK aktualisiert, sollte prüfen, ob das SDK die Methode automatisch bereitstellt oder ob sie im eigenen Code fehlt.

resultType in jedem Ergebnis

Alle Results tragen das Pflichtfeld resultType. Es hat einen von zwei Werten: complete für ein fertiges Ergebnis oder input_required, wenn der Server noch etwas vom Client braucht. Ein Server, der Ergebnisse ohne dieses Feld liefert, entspricht der Version 2026-07-28 nicht.

Multi Round-Trip Requests statt Anfragen vom Server

Bisher konnte ein Server mitten in einem Werkzeugaufruf selbst Anfragen an den Client schicken: sampling/createMessage, elicitation/create oder roots/list. Das setzte eine offene, zweiseitige Verbindung voraus. Mit den Multi Round-Trip Requests (SEP-2322) dreht sich das um. Der Server antwortet mit resultType: "input_required". Der Client wiederholt die ursprüngliche Anfrage und liefert die fehlenden Angaben in inputResponses mit.

Das betrifft vor allem Rückfragen an den Nutzer. Wer vor einer Aktion eine Bestätigung über Elicitation einholt, also einen Human in the Loop eingebaut hat, muss diesen Ablauf umbauen. Die Rückfrage ist dann keine eigene Server-Anfrage mehr, sondern Teil der Antwort.

Nicht betroffen sind Freigaben, die ganz außerhalb von MCP laufen, etwa als Nachricht im Team-Chat oder über einen eigenen Freigabeschritt mit Passkey, der vor der eigentlichen Aktion liegt.

Neue Header bei Streamable HTTP: Mcp-Method und Mcp-Name

POST-Anfragen über Streamable HTTP tragen den Header Mcp-Method und, je nach Methode, Mcp-Name (SEP-2243). Mcp-Method spiegelt die Methode und gilt für alle Anfragen. Mcp-Name spiegelt den Werkzeug-, Prompt- oder Ressourcennamen und ist bei tools/call, resources/read und prompts/get vorgeschrieben. Den Zweck nennt die Spezifikation selbst: Load Balancer, Gateways und Monitoring sollen Anfragen routen und prüfen können, ohne den JSON-Body zu parsen. Senden muss die Header der Client. Der Server muss prüfen, ob sie zum Body passen, und lehnt Abweichungen mit 400 Bad Request ab.

Cachebare Listen und feste Reihenfolge

Listen-Antworten (tools/list, prompts/list, resources/list, resources/templates/list) und resources/read brauchen jetzt die Felder ttlMs und cacheScope (SEP-2549). ttlMs sagt in Millisekunden, wie lange ein Client die Antwort als frisch betrachten darf. cacheScope ("public" oder "private") legt fest, ob auch geteilte Zwischenstationen sie cachen dürfen. Außerdem sollen Tools in deterministischer Reihenfolge kommen. Laut Changelog hilft das Prompt-Caches. Wechselt die Reihenfolge der Werkzeuge bei jeder Anfrage, ändert sich auch der Prompt, der ans Modell geht.

Was läuft aus, und wie lange funktioniert es noch?

Fünf Funktionen sind deprecated, dazu kommen zwei Werte des Sampling-Felds includeContext. Laut Release-Blog funktionieren Roots, Sampling und Logging aber noch „for at least twelve months“. Die neue Feature-Lifecycle-Policy legt für jede Deprecation ein Fenster von mindestens zwölf Monaten fest, gezählt ab dem Release der Revision, die die Funktion als deprecated markiert (Changelog, Feature-Lifecycle-Policy). Konkret heißt das laut Deprecated-Registry: Roots, Sampling und Logging dürfen frühestens in einer Revision entfallen, die am oder nach dem 28.07.2027 erscheint. Für den HTTP+SSE-Transport gilt laut Deprecated-Registry eine Ausnahme, weil er schon seit Version 2025-03-26 deprecated ist. Niemand muss also sofort umbauen.

Elicitation steht nicht auf der Liste, läuft aber ebenfalls über den neuen Ablauf mit input_required. Wer Elicitation nutzt, muss also umbauen, auch wenn die Funktion selbst bleibt. Solange Roots und Sampling nicht entfernt sind, laufen auch ihre Anfragen über Multi Round-Trip Requests.

Was ändert sich bei der Authentifizierung?

Zwei Punkte betreffen OAuth. Erstens ist Dynamic Client Registration zugunsten von Client ID Metadata Documents (CIMD) deprecated. DCR bleibt für Autorisierungsserver ohne CIMD-Unterstützung vorerst verfügbar. Zweitens sollen Autorisierungsserver den iss-Parameter nach RFC 9207 in ihre Antworten aufnehmen, und Clients müssen einen vorhandenen iss prüfen (SEP-2468). Die zweite Änderung trifft vor allem Client-Entwickler. Wer einen Remote-Server mit eigenem Autorisierungsserver betreibt, sollte prüfen, ob dieser CIMD unterstützt und iss mitsendet. Wie Berechtigungsgrenzen und OAuth 2.1 grundsätzlich zusammenspielen, beschreibt der Abschnitt zur Authentifizierung am MCP-Server.

Muss mein MCP-Server migriert werden?

Ja, wenn er die Version 2026-07-28 sprechen soll. Laut Changelog muss dann jeder Server server/discover und resultType umsetzen und darf sich nicht mehr auf Handshake oder Session-ID verlassen. Wie viel darüber hinaus zu tun ist, hängt vom Transport ab und davon, welche Funktionen der Server nutzt.

Für lokale Server über stdio fällt die Prüfung kürzer aus. Die Header-Regeln beziehen sich laut Changelog auf POST-Anfragen über Streamable HTTP. Handshake, server/discover und resultType betreffen aber auch lokale Server. Ein Beispiel für solche lokalen Server sind die Reverse-Engineering-Werkzeuge aus dem Beitrag Reverse Engineering mit Claude.

Für meine eigenen Systeme sieht die Einordnung so aus (Stand: Fallstudien auf dieser Website):

Ältere Clients müssen nicht abgehängt werden. Laut Spezifikation (Versioning) darf ein Server Clients mit Handshake und Clients mit Version 2026-07-28 parallel bedienen. Der Testlauf unten bestätigt das für das Python SDK.

Wie weit sind die offiziellen SDKs?

Laut Release-Blog unterstützen die Tier-1-SDKs für TypeScript, Python, Go und C# die Version 2026-07-28 ab dem Tag des Releases. Für C# und Python liegen konkrete Release-Hinweise vor. Bei beiden ändert sich das Verhalten so, dass bestehender Code ohne Anpassung brechen kann.

C#: zustandslos als Standard

Das offizielle C# SDK v2.0 erschien am 28.07.2026. Laut Microsoft .NET Blog steht HttpServerTransportOptions.Stateless dort standardmäßig auf true. Im zustandslosen Modus werfen ElicitAsync, SampleAsync und RequestRootsAsync eine Ausnahme. Ein Server, der eine dieser Methoden aufruft und nach dem Update die Standardeinstellung übernimmt, bricht also an genau dieser Stelle.

Python: neuer Klassenname, 2.x ist Standard

Mit dem Python SDK v2.0 heißt FastMCP jetzt MCPServer. Die Umbenennung kam mit der Beta v2.0.0b1 vom 30.06.2026 (Release-Hinweis). Seit der stabilen Version v2.0.0 vom 28.07.2026 installiert pip install mcp laut Release-Hinweis 2.x, auch in Pipelines ohne Versionsgrenze. Wer noch bei 1.x bleiben will, muss die Version begrenzen.

TypeScript und Go

Das Go SDK unterstützt 2026-07-28 ab Version v1.7.0 vom 28.07.2026 (Releases). Beim TypeScript SDK ließ sich die erste Version mit Unterstützung nicht eindeutig belegen. Aktuell war am 21.10.2026 die Version 2.3.1 vom 05.10.2026 (Releases).

Ein Unterschied zwischen den SDKs wird beim Update leicht übersehen: Im C# SDK ist der zustandslose Modus Standard. Im Python SDK 2.3.0 steht stateless_http dagegen standardmäßig auf False. Was das praktisch bedeutet, zeigt der Testlauf.

In welcher Reihenfolge lässt sich ein MCP-Server migrieren?

Die folgende Reihenfolge leite ich aus dem Changelog ab. Erprobt ist sie nicht.

1. Bestandsaufnahme. Transport und genutzte Funktionen anhand der Tabelle oben erfassen.
2. SDK-Version pinnen. Den Release-Hinweis des SDK lesen, besonders bei Betas.
3. Zustand entfernen. Alles lösen, was am Handshake oder an der Session-ID hängt.
4. Rückfragen umbauen. Sampling, Elicitation und Roots auf input_required und inputResponses umstellen.
5. Pflichtfelder prüfen. server/discover, resultType, ttlMs und cacheScope in echten Antworten kontrollieren, nicht nur im Code.
6. Gegen einen echten Client testen, der 2026-07-28 spricht.

Testlauf: Wie verhält sich ein MCP-Server mit Version 2026-07-28 in der Praxis?

Eine Migration meiner Produktivsysteme beschreibe ich hier nicht. Stattdessen zeigt ein Testlauf mit einem minimalen Server, was ein Client mit Version 2026-07-28 tatsächlich sendet und zurückbekommt. Getestet wurde am 21.10.2026 lokal mit dem Python SDK mcp 2.3.0 und einem einzigen Werkzeug, per curl über Streamable HTTP.

Kurzergebnis: Ein Server mit dem Python SDK 2.3.0 lehnt Anfragen ohne io.modelcontextprotocol/clientCapabilities in _meta mit 400 ab, prüft die Header Mcp-Method und Mcp-Name gegen den Body (Fehlercode -32020) und beantwortet zugleich einen klassischen initialize mit 2025-11-25. Alte und neue Clients laufen also parallel.

Die Discovery-Anfrage kommt ohne Handshake aus. Version und Client-Fähigkeiten stehen in _meta, die Methode zusätzlich im Header:

curl -s http://127.0.0.1:8765/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: server/discover" \
  -d '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
       "io.modelcontextprotocol/protocolVersion":"2026-07-28",
       "io.modelcontextprotocol/clientCapabilities":{}}}}'

Die Antwort (gekürzt) enthält die neuen Pflichtfelder:

{"result":{"resultType":"complete","supportedVersions":["2026-07-28"],
  "ttlMs":0,"cacheScope":"private",
  "capabilities":{"tools":{"listChanged":true}}}}

Fünf Beobachtungen aus dem Testlauf:

1. Beide Schlüssel in _meta sind Pflicht. Mit nur der Protokollversion antwortete der Server mit 400 und dem Hinweis, dass io.modelcontextprotocol/clientCapabilities fehlt.
2. Die Header werden geprüft. Ein tools/call mit falschem Mcp-Name oder ganz ohne Mcp-Method lehnte der Server mit 400 und Fehlercode -32020 ab. Wer einen Reverse Proxy oder ein Gateway vor dem Server hat, sollte prüfen, dass beide Header durchkommen.
3. Alt und neu laufen parallel. Derselbe Server beantwortete einen klassischen initialize mit 2025-11-25. Ein Update auf das neue SDK schließt ältere Clients also nicht automatisch aus.
4. stateless_http betrifft nur alte Clients. Im Standardmodus des Python SDK bekam der alte Handshake weiterhin eine mcp-session-id. Anfragen im Format 2026-07-28 liefen in beiden Modi ohne Session.
5. Der GET-Endpoint antwortet noch. Ein GET /mcp öffnete im SDK weiterhin einen Stream, obwohl die Spezifikation ihn durch subscriptions/listen ersetzt. Vermutlich dient das älteren Clients, belegt ist es nicht.

Das ist ein Labortest, kein Produktivbetrieb. Er zeigt das Verhalten eines SDK, nicht das jedes Clients.

Was heißt MCP 2026-07-28 für n8n?

Eine Aussage von n8n zur Unterstützung von 2026-07-28 gibt es in der n8n-Doku und den Release Notes bis Version 2.44 vom 13.10.2026 nicht, der neuesten am 21.10.2026 gelisteten Version. Die Doku des MCP Server Triggers nennt weiterhin SSE und Streamable HTTP als Transporte. Für den Betrieb mit mehreren Replicas gilt unverändert eine Vorgabe, die auf Sitzungen beruht.

Die Doku verlangt, dass bei mehreren Webhook-Replicas alle Anfragen an /mcp* an ein einzelnes, eigenes Replica gehen. Sonst, so die Doku, „your SSE and streamable HTTP connections will frequently break or fail to reliably deliver events“. Laut Release Notes erhielt der MCP Server Trigger mit n8n 2.36 vom 18.08.2026 ein Feld „Instructions“. Dessen Text sendet n8n „as part of the initialize response“. Drei Wochen nach dem Release der neuen Spezifikation nutzte n8n den Handshake also noch.

Meine Einschätzung: Die Replica-Vorgabe ist genau die Art Session-Bindung, die eine zustandslose Spezifikation unnötig machen soll. Ob und wann n8n den Trigger umstellt, lässt sich daraus nicht ableiten. Wie man n8n als MCP-Server einrichtet und hinter einem Reverse Proxy betreibt, steht im eigenen Beitrag. Grundlagen zu n8n gibt es im Glossar.

Ob eine eigene n8n-Instanz die neue Version schon spricht, lässt sich ohne Umbau prüfen. Laut Spezifikation dient server/discover genau dafür als Kompatibilitätsprobe. Die Anfrage aus dem Testlauf oben geht an die Produktions-URL des MCP Server Triggers, bei aktivierter Authentifizierung mit dem passenden Header. Liefert der Trigger ein Result mit supportedVersions, spricht er 2026-07-28. Kommt ein Fehler, arbeitet er noch mit dem Handshake, und Clients verbinden sich über den alten Weg.

Wie geht es nach 2026-07-28 weiter?

Am 22.08.2026 hat das MCP-Projekt eine neue Roadmap mit fünf Prioritäten veröffentlicht. Termine für den nächsten Release nennt sie nicht. Für Server-Betreiber sind zwei Punkte besonders interessant: ein HTTP-nativer Transport, der auch lokale Server abdeckt, und Agentenidentität.

Die fünf Prioritäten:

1. Agentic Messaging, also serverseitige Events (Webhooks und Channels) und die Weiterentwicklung der Tasks-Erweiterung
2. HTTP-nativer Transport, vereinheitlicht und gehärtet, auch für lokale Server (laut Roadmap „Streamable HTTP over stdio“)
3. Agentenidentität, laut Roadmap „built on existing standards rather than pasted API keys and long-lived tokens“. Genannt werden DPoP (RFC 9449) und Workload Identity Federation
4. Verbesserte Primitive, unter anderem einheitliche Tool-Ergebnisse und Progressive Discovery für große Tool-Kataloge
5. Developer Experience der SDKs

Kommt ein gemeinsamer HTTP-Transport für lokal und remote, könnte der Unterschied zwischen stdio- und Remote-Servern aus der Tabelle oben kleiner werden. Das ist Spekulation, solange es keine Spezifikation dazu gibt. Für die Migration heute spielt die Roadmap keine Rolle. Sie zeigt aber, dass die Zustandslosigkeit ein erster Schritt ist.

Wo hilft die zustandslose Spezifikation im Betrieb wirklich?

Am meisten bringt die neue Version dort, wo heute Sitzungen den Betrieb erschweren. Die Replica-Vorgabe von n8n ist so ein Fall. Ohne Session-ID darf jede Instanz jede Anfrage beantworten, sofern der Server selbst keinen Zustand hält. Ein Load Balancer braucht dann keine Bindung an eine Instanz.

Komplizierter wird es bei Rückfragen und Abbrüchen. Wer heute über Elicitation eine Bestätigung einholt, baut den Ablauf auf input_required um. Und weil abgebrochene Anfragen neu gestellt werden, sollten Werkzeuge mit Wirkung nach außen eine Wiederholung erkennen.

Eile ist nicht nötig. Das Zwölf-Monats-Fenster gilt (Ausnahme: HTTP+SSE), und alte Clients lassen sich parallel bedienen. Zwei Dinge würde ich trotzdem jetzt prüfen: welche Standardeinstellung das eigene SDK nach dem Update setzt, und ob Proxy und Gateway die neuen Header durchreichen.

Wer tiefer einsteigen will: Die Grundlagen stehen im Glossar unter Model Context Protocol. Wie ein MCP-Server mit begrenzten Rechten in n8n entsteht, zeigt n8n als MCP-Server. Wie Agenten über MCP mehrere Datenquellen kombinieren, beschreibt Agentic RAG mit MCP.