Die MCP-Spezifikation bricht mit ihrer Vergangenheit — was Betreiber jetzt umbauen müssen

/01Was am 28.07.2026 gebrochen ist

MCP ist ein offener Standard, über den ein LLM-Client — üblicherweise ein Agent oder eine Entwicklungsumgebung — Werkzeuge, Ressourcen und Prompt-Vorlagen eines Servers zur Laufzeit entdeckt und aufruft. Was am 28. Juli 2026 erschienen ist, ist keine neue Funktion obendrauf, sondern eine neue Fassung dieser Spezifikation selbst — die Nachfolgerin der Fassung vom 25. November 2025. Die vorherige Version stand auf einem zustandsbehafteten Fundament: eine Verbindung, eine Sitzung, ein Handshake davor. Die neue Fassung reißt genau dieses Fundament heraus und ersetzt es durch zustandslose, in sich abgeschlossene Anfragen.

Zur Abgrenzung: Dieser Artikel behandelt die Protokollmigration selbst — welche Felder, Header und Abläufe sich zwischen den beiden Spezifikationsständen ändern und was das für einen bestehenden Server bedeutet. Wie ein Tool-Gateway vor mehreren MCP-Servern aufgebaut wird, behandelt der Schwesterartikel MCP in Produktion — dort geht es um die Betriebsarchitektur, hier um das Protokoll darunter. Beides hängt zusammen, ist aber nicht dasselbe: Ein sauber gebautes Gateway kann trotzdem gegen eine veraltete Protokollversion sprechen, wenn niemand die Migration nachzieht.

Wichtig ist auch die Abgrenzung zu einem verwandten, aber anderen Standard: MCP verbindet ein Modell mit einem Werkzeug oder einer Datenquelle. A2A regelt dagegen, wie zwei Agenten miteinander verhandeln — Aufgaben abgeben, Zwischenstände melden, Ergebnisse zurückgeben. Ein Agent, der MCP spricht, hat noch keine Fähigkeit, mit einem anderen Agenten zu verhandeln, und umgekehrt. Die Migration in diesem Artikel betrifft ausschließlich MCP.

/02Sessions verschwinden: das zustandslose Protokoll

Der größte einzelne Einschnitt der neuen Spezifikation betrifft den Verbindungsaufbau. Bislang begann jede MCP-Verbindung mit einem initialize/initialized-Handschlag, der Protokollversion und Fähigkeiten einmalig aushandelte; danach identifizierte der Mcp-Session-Id-Header jede folgende Anfrage als Teil dieser einen Sitzung. Beides ist jetzt entfernt. Jede Anfrage trägt ihre Protokollversion und ihre Client-Fähigkeiten selbst mit — im Feld _meta, unter den Schlüsseln io.modelcontextprotocol/protocolVersion und io.modelcontextprotocol/clientCapabilities. Passt die Version nicht, liefert der Server einen definierten Fehler (UnsupportedProtocolVersionError) statt eines stillen Fehlschlags.

Der Effekt lässt sich an einem Satz aus der Ankündigung festmachen: Jede Anfrage kann jetzt auf jeder Serverinstanz hinter einem einfachen Round-Robin-Load-Balancer landen, ohne dass die Instanzen sich einen gemeinsamen Speicher teilen müssen. Für einen horizontal skalierten Betrieb ist das ein handfester Vorteil — es entfällt die Sticky Session, die bislang jede Anfrage einer Verbindung an dieselbe Instanz binden musste. Für einen Server, der intern noch auf die Sitzung als Speicherort für Zustand setzt, ist es dagegen eine Bruchstelle: Zustand über mehrere Aufrufe hinweg lässt sich nicht mehr implizit an der Verbindung festmachen, sondern muss explizit als vom Server ausgestelltes Handle transportiert werden — als ganz normales Werkzeugargument, nicht als Protokollfeature.

Die letzte Zeile ist im Betrieb die unbequemste. SSE-Wiederaufnahme und Nachrichten-Zustellung über Last-Event-ID sind gestrichen. Bricht der Antwort-Stream mitten in einer laufenden Anfrage ab, ist die Anfrage verloren — der Client muss sie mit einer neuen Request-ID neu stellen, nicht an der alten Position fortsetzen. Wer bislang auf Wiederaufnahme als Ausfallsicherung gesetzt hat, muss diese Logik jetzt auf Client-Seite selbst nachbauen.

/03Multi Round-Trip Requests statt Zwischenrufen

Das zweite große Muster betrifft alles, was bislang mitten in einer Anfrage eine Rückfrage an den Client stellte — ein Server, der Verzeichnisse braucht (roots/list), eine Modellantwort anfordert (sampling/createMessage) oder eine Nutzerentscheidung einholt (elicitation/create). Diese drei serverinitiierten Zwischenrufe verlangten bislang eine offen gehaltene Verbindung, über die der Server mittendrin eine eigene Anfrage an den Client schicken konnte.

Das neue Muster heißt Multi Round-Trip Requests, kurz MRTR. Statt einer eingebetteten Rückfrage liefert der Server ein reguläres Ergebnis zurück — mit dem neuen Pflichtfeld resultType auf dem Wert "input_required" statt "complete". Im Feld inputRequests stehen die Informationen, die noch fehlen. Der Client sammelt die Antworten und stellt denselben ursprünglichen Aufruf erneut, diesmal mit inputResponses im Gepäck. Aus Sicht der Transportebene ist damit jede Zwischenfrage wieder eine ganz normale, in sich abgeschlossene Anfrage — konsequent zur Zustandslosigkeit aus Abschnitt /02.

Das betrifft auch, wie Human-in-the-Loop in der Praxis umgesetzt wird. Elicitation — die Rückfrage an einen Menschen vor einer heiklen Aktion — bleibt als Fähigkeit erhalten, aber ihr bisheriges Abschlusssignal, die Benachrichtigung notifications/elicitation/complete, ist gestrichen. Der Client erfährt den Ausgang jetzt über die Wiederholung der ursprünglichen Anfrage, nicht über eine separate Meldung. Wer eine Elicitation über mehrere Wiederholungen hinweg zuordnen muss, kodiert dafür eine eigene Kennung im Feld requestState — das Protokoll selbst stellt dafür keine Kennung mehr bereit.

/04Pflicht-Header: Mcp-Method und Mcp-Name

Neu auf jeder Streamable-HTTP-POST-Anfrage sind zwei Header: Mcp-Method nennt die aufgerufene Methode, Mcp-Name das betroffene Werkzeug oder die Ressource. Beide sind jetzt Pflicht, nicht optional. Der praktische Grund: Ein Tool-Gateway, ein Rate-Limiter oder eine Web Application Firewall kann damit auf Basis der Header routen und messen, statt bei jeder Anfrage den JSON-Rumpf zu parsen. Ergänzend erlaubt die Spezifikation jetzt auch benutzerdefinierte Header aus Werkzeugparametern über das Präfix x-mcp-header.

POST /mcp HTTP/1.1
Mcp-Method: tools/call
Mcp-Name: rechnung_pruefen
Content-Type: application/json

{"jsonrpc":"2.0","id":42,"method":"tools/call",
 "params":{"name":"rechnung_pruefen","arguments":{"belegnr":"RE-2026-4471"}},
 "_meta":{
   "io.modelcontextprotocol/protocolVersion":"2026-07-28",
   "io.modelcontextprotocol/clientInfo":{"name":"hostspezial-agent","version":"3.1"}
 }}

Für einen bestehenden Server heißt das zweierlei. Erstens: Middleware, die bisher aus dem JSON-Rumpf ableiten musste, welches Werkzeug gerade läuft, kann diese Ableitung ersatzlos streichen — die Header liefern die Information direkt und günstiger. Zweitens: Ein Server, der die Header nicht setzt, riskiert an genau der Stelle Probleme, an der Betreiber sie am wenigsten brauchen können — bei Gateways und Prüfstellen, die inzwischen auf die Header statt auf Rumpf-Parsing eingestellt sind. Ergänzend gilt jetzt außerdem: Server sollten Werkzeuge aus tools/list in einer deterministischen Reihenfolge zurückgeben — nicht zufällig sortiert —, damit clientseitiges Caching und die Trefferquote im Prompt-Cache des Modells nicht bei jedem Aufruf neu anlaufen.

/05Cachebare Listen: ttlMs und cacheScope

Die vier Listenaufrufe tools/list, prompts/list, resources/list und resources/templates/list sowie resources/read tragen jetzt zwei Pflichtfelder aus dem neuen Interface CacheableResult: ttlMs ist ein Frische-Hinweis in Millisekunden, der einem Client sagt, wie lange er eine Antwort ohne erneuten Abruf verwenden darf. cacheScope steht auf "public" oder "private" und legt fest, ob ein zwischengeschalteter Dienst — etwa ein Gateway — die Antwort für mehrere Clients gemeinsam zwischenspeichern darf oder nicht. Beide Felder ergänzen die bestehenden listChanged-Benachrichtigungen, sie ersetzen sie nicht: Eine Änderung wird weiterhin aktiv gemeldet, ttlMs regelt nur, wie lange ein Client ohne Meldung vertrauen darf.

Ergänzend hat sich ein Fehlercode verschoben, der in bestehenden Implementierungen gerne hartkodiert vorkommt: Der Fehler „Ressource nicht gefunden" trägt jetzt -32602 (Invalid Params) statt zuvor -32002 — Angleichung an die JSON-RPC-Spezifikation selbst. Wer diesen Code irgendwo im Fehlerhandling auf der Client-Seite abfragt, muss die Abfrage anpassen. Gleichzeitig definiert die Spezifikation erstmals eine Zuteilungspolitik für den JSON-RPC-Server-Fehlerbereich: Die Codes -32000 bis -32019 bleiben implementierungsspezifisch und Bestandsschutz für vorhandene SDKs, -32020 bis -32099 sind der MCP-Spezifikation vorbehalten. Die drei in einem früheren Entwurf eingeführten Codes wurden entsprechend umnummeriert — wer sich an konkrete Zahlenwerte gebunden hat statt an die benannten Fehlertypen, muss auch hier nacharbeiten.

/06Autorisierung: RFC 9207 und CIMD statt Dynamic Client Registration

Bei der OAuth-Autorisierung verschärft die neue Fassung eine konkrete Lücke. Autorisierungsserver sollen den iss-Parameter gemäß RFC 9207 in ihrer Antwort mitliefern, und ein MCP-Client muss einen vorhandenen iss-Wert gegen den erwarteten Aussteller prüfen, bevor er den Autorisierungscode einlöst. Der Effekt: Ein sogenannter Authorization-Server-Mix-up — bei dem ein Code versehentlich beim falschen Aussteller eingelöst wird, weil zwei Server dieselbe Client-Konfiguration teilen — wird strukturell erschwert. Ergänzend müssen Client-Zugangsdaten jetzt fest an den ausstellenden Server gebunden werden: Sie dürfen nicht bei einem anderen Autorisierungsserver wiederverwendet werden, und wechselt der zuständige Server, ist eine erneute Registrierung Pflicht statt einer stillen Weiterverwendung der alten Zugangsdaten.

Der zweite Umbau betrifft die Registrierung selbst. Dynamic Client Registration nach RFC 7591 gilt jetzt als veraltet — zugunsten von Client ID Metadata Documents, kurz CIMD. Statt sich bei jedem Autorisierungsserver einzeln mit einer Registrierungsanfrage anzumelden, verweist ein Client auf ein von ihm selbst gehostetes Metadaten-Dokument, aus dem der Autorisierungsserver seine Client-Identität liest. Dynamic Client Registration bleibt nutzbar, ausdrücklich als Rückfalloption für Autorisierungsserver, die CIMD noch nicht unterstützen — ein festes Enddatum nennt die Spezifikation dafür nicht. Zusätzlich verlangt die Fassung jetzt, bei der Registrierung einen passenden application_type anzugeben, um Konflikte bei OIDC-Redirect-URIs zu vermeiden, wie sie insbesondere bei lokal laufenden Clients auftraten.

Für die eigene Betriebspraxis gehört das in denselben Zusammenhang wie strukturierte Agent-Identitäten statt geteilter Admin-Zugänge: Ein Client, der über CIMD eine feste, überprüfbare Identität trägt, lässt sich beim Aussteller ebenso eindeutig einem Zweck zuordnen wie ein Dienstkonto mit engem Scope. Details zur Kontenseite dieses Gedankens stehen im Artikel Agent Identity.

/07Der Deprecation-Fahrplan: Roots, Sampling, Logging, HTTP+SSE

Die Spezifikation führt erstmals eine formale Feature-Lifecycle-Richtlinie mit drei Zuständen — Active, Deprecated, Removed — und einem verbindlichen Mindestzeitraum von zwölf Monaten zwischen Deprecated und Removed. Vier Merkmale wechseln mit dieser Fassung in den Zustand Deprecated.

Bei Logging lohnt der genaue Blick: Statt eines eigenen Protokoll-Levels je Anfrage (logging/setLevel, jetzt ebenfalls gestrichen) empfiehlt die Spezifikation den Wechsel auf OpenTelemetry als Protokollierungsweg — konsistent mit der bereits an anderer Stelle dokumentierten Konvention, Trace-Kontext über die Felder traceparent, tracestate und baggage im _meta-Objekt zu propagieren. Wer für seinen MCP-Server bereits eine Observability-Kette betreibt, muss also nicht zwei Wege parallel pflegen — Log-Level-Steuerung über das Protokoll fällt weg, strukturierte Nachvollziehbarkeit über Tracing bleibt und wird sogar expliziter dokumentiert.

Merksatz für die Planung: Zwölf Monate sind ein Mindestzeitraum, keine Zusage auf Verlängerung. Wer Roots oder Sampling heute produktiv nutzt, sollte die Migration jetzt einplanen, nicht erst, wenn die Frist absehbar wird.

/08Wo es hakt: die Fallstricke der Migration

Fünf Punkte tauchen in der Praxis regelmäßig auf, sobald ein bestehender Server auf die neue Fassung umgestellt wird.

Zustand, der bisher an der Sitzung hing, braucht jetzt einen expliziten Ort

Ein Server, der intern etwa einen laufenden Datenbank-Cursor oder einen Zwischenschritt an die Sitzung gebunden hat, verliert diesen impliziten Speicherort ersatzlos. Die Migration ist hier keine Zeile Konfiguration, sondern echte Umbauarbeit: Der Zustand muss als serverseitig ausgestelltes Handle modelliert und über gewöhnliche Werkzeugargumente transportiert werden.

Gemischte Client- und Serverflotten während der Übergangszeit

Ein Client der neuen Fassung muss Ergebnisse älterer Server, die kein resultType-Feld setzen, als "complete" behandeln — das ist in der Spezifikation als Pflichtregel für den Übergang festgehalten. Das funktioniert, so lange man diese Regel kennt und implementiert; wer sie übersieht, riskiert stillschweigend falsch interpretierte Ergebnisse gemischter Serverlandschaften.

Prompt Injection bleibt eine Aufgabe des Betriebs, nicht des Protokolls

MRTR ändert, wie eine Rückfrage transportiert wird — nicht, ob eine Werkzeug-Rückgabe vertrauenswürdig ist. Eine Rückgabe aus einem Tool-Aufruf landet weiterhin im Kontextfenster des Modells und kann dort wie eine Anweisung wirken, wenn sie nicht aktiv als reine Daten markiert wird. Das ist dieselbe Angriffsfläche wie vor der Migration, nur mit einem neuen Transportmechanismus obendrüber — sie verschwindet mit dem Protokoll-Update nicht.

Abgebrochene Streams sind jetzt endgültig

Ohne SSE-Wiederaufnahme verliert ein Client bei einem Verbindungsabbruch mitten in einer laufenden Anfrage genau diese Anfrage. Wer bislang auf automatische Wiederaufnahme vertraut hat, muss jetzt selbst erkennen, wann ein Stream endgültig tot ist, und die ursprüngliche Anfrage mit neuer Request-ID erneut stellen — inklusive der Frage, ob eine bereits teilweise ausgeführte, nicht-idempotente Aktion dabei versehentlich doppelt läuft.

Backward-Compat-Pfade sind Übergangslösungen, keine Dauerlösung

Dynamic Client Registration bleibt nutzbar, das HTTP+SSE-Fallback bleibt vorerst funktionsfähig, Roots und Sampling laufen mindestens ein Jahr weiter. Alle drei Pfade sind aber ausdrücklich als Rückfall markiert, nicht als gleichwertige Alternative. Wer sie als dauerhafte Lösung einplant, baut auf einem Fundament, dessen Abbautermin bereits angekündigt ist, auch wenn er noch nicht feststeht.

/09Jetzt umbauen oder abwarten: die Entscheidung

Ehrlich: Nicht jeder Server muss diese Woche umgebaut werden. Die Frage, wie dringend die Migration ist, hängt an drei Punkten.

• Setzt der Server aktiv auf Roots oder Sampling? Dann beginnt die Uhr jetzt — zwölf Monate sind kein langer Zeitraum, wenn die Umstellung echte Architekturarbeit bedeutet, etwa die direkte Anbindung an eine LLM-Provider-API statt des bisherigen Umwegs über den Client.
• Läuft der Server hinter einem Gateway mit mehreren Instanzen oder ist er planmäßig einzeln, klar begrenzt im Einsatz? Für Betrieb hinter einem Lastausgleich lohnt sich die Umstellung auf das zustandslose Modell schon aus Skalierungsgründen — unabhängig von der Deprecation-Frist. Für einen einzelnen, intern genutzten Server mit einer festen Verbindung ist der Druck geringer.
• Wie stark hängt die Autorisierung an Dynamic Client Registration? Wer ohnehin mehrere Autorisierungsserver anbindet, sollte CIMD jetzt einplanen — der Umstieg ist eine einmalige Umstellung der Registrierung, keine laufende Wartungslast wie ein liegen gelassenes Deprecation-Feature.

Die meisten KMU-Betriebe, die einen einzelnen internen MCP-Server ohne Roots oder Sampling fahren, haben bis zur Mindestfrist Luft — sollten die Migration aber als festen Punkt im nächsten Wartungsfenster einplanen, nicht als „läuft ja noch" liegen lassen. Wer dagegen mehrere MCP-Server produktiv mit echtem Datenzugriff betreibt, für den ist die Protokollmigration ohnehin Teil derselben Aufgabe wie der Aufbau eines Tool-Gateways aus dem Schwesterartikel — beides gehört in dasselbe Projekt, nicht in zwei getrennte.

/10Häufige Fragen