Die Revision 2026-07-28 des Model Context Protocol streicht die Sitzung samt Handshake und macht abgerissene Streams unwiederbringlich. Für Betreiber eines MCP-Servers ist das kein Detailwechsel, sondern ein Umbau der Betriebsarchitektur. Im Gegenzug bekommt das Protokoll erstmals eine verbindliche Frist, wie lange Abgekündigtes noch trägt.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Neun Major-Änderungen führt das Änderungsprotokoll der neuen MCP-Spezifikation auf, und gleich die erste löscht das Fundament der bisherigen Architektur.[1] Der Header Mcp-Session-Id ist verschwunden, zusammen mit dem Sitzungsbegriff auf Protokollebene. Jede Anfrage steht ab sofort für sich allein.
Das Wichtigste in Kürze
- Sitzungen und der Header
Mcp-Session-Identfallen ersatzlos, Listen-Endpunkte antworten nicht mehr verbindungsabhängig. - Der
initialize-Handshake ist weg, Protokollversion und Client-Fähigkeiten reisen in jeder einzelnen Anfrage mit. - Roots, Sampling und Logging gelten als abgekündigt, bleiben aber vorerst voll funktionsfähig.
- Eine neue Lifecycle-Regel garantiert mindestens zwölf Monate zwischen Abkündigung und Entfernung.
Warum verschwindet die Sitzung aus dem Protokoll?
Ohne Sitzung hält kein Server mehr Zustand zwischen zwei Aufrufen. Protokollversion, Client-Kennung und Fähigkeiten reisen im Feld _meta jeder Anfrage mit, dazu kommt der Aufruf server/discover, den jeder Server anbieten muss.
Der praktische Gewinn zeigt sich am Lastverteiler. Eine Sitzung hat jede Folgeanfrage an dieselbe Instanz gebunden, weil nur dort der Zustand lag. Ohne diese Bindung landet jeder POST auf einer beliebigen Instanz, und serverlose Betriebsmodelle werden praktikabel.
Genauso aufschlussreich ist die Begründung der neuen Pflicht-Header. Mcp-Method und Mcp-Name spiegeln Feldwerte aus dem Nachrichtenkörper in HTTP-Header, damit Zwischenstationen wie Load Balancer, Gateways und Observability-Werkzeuge Anfragen routen und prüfen können, ohne den JSON-Körper zu lesen.[2] MCP verhält sich damit weniger wie ein Sitzungsprotokoll und mehr wie eine gewöhnliche Web-API hinter vorhandener Infrastruktur. Dass sich die Anbindung an eigene Systeme so weit standardisieren lässt, war vor zwei Jahren noch offen.
Was ersetzt Streams, Ping und Logging?
Der GET-Endpunkt und resources/subscribe weichen dem neuen subscriptions/listen. Die Aufrufe ping, logging/setLevel und notifications/roots/list_changed entfallen vollständig, die Protokollstufe steht jetzt pro Anfrage im Feld _meta.
Drei Funktionen tragen zusätzlich den Status abgekündigt: Roots, Sampling und Logging. Die Spezifikation nennt dazu jeweils einen Migrationspfad, etwa Verzeichnisse als Werkzeugparameter statt Roots und die direkte Anbindung an eine Anbieter-Schnittstelle statt Sampling.[1]
Operativ am unangenehmsten ist der Verlust der Wiederaufnahme. Der Header Last-Event-ID und die SSE-Ereigniskennungen sind gestrichen, ein abgerissener Antwortstrom nimmt die laufende Anfrage mit, und der Client muss sie als neue Anfrage mit neuer Kennung wiederholen. Agentenabläufe, die eine solche Wiederholung nicht idempotent verkraften, buchen im Zweifel zweimal. Wie schnell ein Protokolldetail zum Sicherheitsproblem wird, hat der Reihentest öffentlich erreichbarer MCP-Server gezeigt.
Drei Transport-Generationen in zwanzig Monaten
Ein Protokoll, das binnen zwanzig Monaten dreimal seinen Transport umbaut, schuldet den Betreibern genau das, was ihm bisher gefehlt hat: eine Zusage, wie lange das Alte noch trägt.
— Markus Seyfferth, Chefredakteur Dr. Web
Was heißt das für Betreiber im DACH-Raum?
Server, die nur die neue Revision sprechen, sollen GET und DELETE mit 405 beantworten, Mcp-Session-Id und Last-Event-ID ignorieren und Anfragen mit abweichenden Headern mit Status 400 und dem Fehlercode -32020 zurückweisen.
Für europäische Betreiber liegt der eigentliche Hebel in der Kontrollstelle davor. Sobald Methode und Werkzeugname als Header am Gateway ankommen, lassen sich Mandantentrennung, Ratenbegrenzung und revisionssichere Protokollierung dort durchsetzen, wo sie unter NIS2 ohnehin geprüft werden, statt in jedem einzelnen Server. Denselben Weg über eine zentrale Instanz hat MCP zuvor schon bei der Rechteverwaltung eingeschlagen.
Neu ist außerdem eine Planungsgrundlage. Die zugleich beschlossene Lifecycle-Regel schreibt mindestens zwölf Monate zwischen Abkündigung und frühestmöglicher Entfernung fest; nur bei einem belegten Sicherheitsrisiko darf diese Frist verkürzt werden, und dann bleiben mindestens 90 Tage.[3] Betreiber, die bisher jede Revision als Bruchrisiko einkalkuliert haben, bekommen damit erstmals einen Zeithorizont.
Prüfen Sie deshalb zuerst, ob Ihre Server noch Sitzungskennungen ausstellen und ob Ihre Clients einen abgerissenen Strom sauber wiederholen. Beides entscheidet darüber, ob der Umstieg ein Konfigurationsschritt bleibt oder zu einem Projekt wird.
Quellen
[1] Model Context Protocol: „Key Changes“, Spezifikation 2026-07-28
[2] Model Context Protocol: „Streamable HTTP“, Transport-Binding der Spezifikation 2026-07-28
[3] Model Context Protocol: „Feature Lifecycle and Deprecation Policy“
Mehr Newshunger?
- MCP und MCP-Server: Was steckt hinter dem Standard, der KI mit Ihren Systemen verbindet?
- Jeder vierzehnte MCP-Server fällt durch: Wie unsicher die Infrastruktur für KI-Agenten wirklich ist
- Schluss mit dem OAuth-Klickmarathon: MCP bekommt zentrale Rechteverwaltung
- Apple kündigt MCP-Server für Safari an
- So macht „Mcpsnoop“ KI-Traffic sichtbar
- Alle Nachrichten aus dem Bereich Künstliche Intelligenz
