Großes MCP Update: Stateless statt Sessions

Das Model Context Protocol Update 2026 streicht die Sessions ersatzlos aus dem Protokoll. Über MCP greifen KI-Systeme auf Werkzeuge und Daten zu. Die neue Spezifikationsversion trägt den Bezeichner 2026-07-28 und soll nach der offiziellen Roadmap an diesem Dienstag final werden. Damit wird das Protokoll stateless und der bisherige Verbindungsaufbau entfällt vollständig. Für Unternehmen mit eigenen MCP-Servern ist es die größte Umstellung seit Einführung der Authorization.

Model Context Protocol: der Standard hinter den KI-Agenten

Das Model Context Protocol ist ein offener Standard für die Anbindung von KI-Systemen an Werkzeuge und Daten. Anthropic veröffentlichte es am 25. November 2024. Über MCP kann ein Sprachmodell eine Datenbank abfragen, Dateien lesen oder ein Ticketsystem bedienen. Ohne einen solchen Standard braucht jede Kombination aus Modell und Werkzeug eine eigene Schnittstelle.

Die Verbreitung ging schnell und schon im März 2025 übernahm OpenAI MCP für sein Agents SDK, die Responses API und ChatGPT Desktop. Google DeepMind sagte im April 2025 Unterstützung für Gemini zu. Die SDKs für Python und TypeScript kamen im März 2026 zusammen auf rund 97 Millionen Downloads pro Monat. Beim Start Ende 2024 waren es etwa 100.000.

Was das Model Context Protocol Update 2026 technisch ändert

Bisher hielten Client und Server eine Session offen und tauschten zu Beginn einen Handshake aus. Er bestand aus den beiden Methoden initialize und initialized. Danach klammerte ein Header namens Mcp-Session-Id alle folgenden Anfragen zusammen. Genau dieser Zustand fällt jetzt weg und der Handshake verschwindet vollständig aus dem Protokoll, der Session-Header ebenfalls.

Stateless bedeutet, dass sich ein Server pro Anfrage nichts über die vorherige merkt. Die MCP-Spezifikation wird mit dieser Version stateless. Protokollversion, Client-Identität und die Fähigkeiten des Clients reisen deshalb in jeder einzelnen Anfrage im Parameter _meta mit. Die Fähigkeiten des Servers holt sich der Client über die neue Methode server/discover. Jede Anfrage steht für sich und lässt sich auf jede beliebige Server-Instanz leiten.

Das löst ein handfestes Betriebsproblem. Wer MCP-Server bisher hinter einem Load Balancer skalierte, brauchte Sticky Routing. Alle Anfragen einer Verbindung mussten dieselbe Instanz treffen. Alternativ half ein gemeinsamer Speicher für Sessions oder das Auslesen der Nachrichteninhalte am Gateway, aber all das entfällt. Zwei neue Header machen Anfragen von außen lesbar. Mcp-Method liegt jeder Anfrage bei, Mcp-Name kommt hinzu, sobald ein Tool, eine Ressource oder ein Prompt benannt wird. Gateways und Rate-Limiter können danach routen, ohne den Inhalt zu öffnen.

Anwendungszustand bleibt trotzdem möglich und Server geben dafür explizite Handles zurück, etwa eine Warenkorb-ID aus einem Tool-Aufruf. Der Client schickt sie bei der nächsten Anfrage mit. Listenergebnisse wie tools/list bekommen die Attribute ttlMs und cacheScope für das Zwischenspeichern beim Client. Neu sind außerdem Multi-Round-Trip-Requests. Ein Tool kann mitten im Aufruf zusätzliche Angaben nachfordern, der Client antwortet und ruft es erneut auf.

Extensions, veraltete Funktionen und eine härtere Authorization

Die Revision bringt ein Extensions-Framework mit. Erweiterungen tragen Kennungen im reverse-DNS-Format und werden zwischen Client und Server ausgehandelt. Zwei davon gehören offiziell zur Spezifikation, darunter MCP Apps für Server, die interaktive HTML-Oberflächen in einer Sandbox ausliefern. Die Tasks-Extension für lang laufende Aufträge verlässt den experimentellen Kern und wird zur Erweiterung. Ihr Lebenszyklus ist neu und stateless-tauglich, weshalb Nutzer auf Abfragen über tasks/get umstellen müssen. Anthropic-Entwickler Den Delimarsky ordnet Extensions als Testfeld für Funktionen ein, die später in den Kern wandern könnten.

Erstmals gibt es eine formale Feature Lifecycle Policy. Sie regelt in drei Phasen, wie Funktionen veralten und irgendwann verschwinden. Zwischen der Markierung als deprecated und der frühestmöglichen Entfernung müssen mindestens zwölf Monate liegen. Roots, Sampling und Logging sind mit dieser Version als veraltet markiert.

Auch die Authorization wird härter und MCP-Server gelten formal als OAuth-2.1-Resource-Server. Sie prüfen Zugriffstoken eines externen Autorisierungsdienstes, statt Nutzer selbst zu authentifizieren. Sechs Specification Enhancement Proposals betreffen allein diesen Teil. Dazu zählt die Prüfung des Token-Ausstellers nach RFC 9207. Resource Indicators nach RFC 8707 richten sich gegen die Weitergabe von Token an fremde Server. Betreiber müssen künftig einen Endpoint unter .well-known/oauth-protected-resource bereitstellen. Dynamic Client Registration meldet Client-Anwendungen automatisch bei einem Autorisierungsserver an und weicht nun dem neuen CIMD.

Vom Anthropic-Projekt zum Standard der Linux Foundation

MCP gehört seit Ende 2025 nicht mehr Anthropic allein. Am 9. Dezember 2025 übergab das Unternehmen die Governance an die neu gegründete Agentic AI Foundation. Sie ist ein zweckgebundener Fonds unter dem Dach der Linux Foundation. Mitgegründet haben sie Anthropic, Block und OpenAI, unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. Neben MCP brachten die Gründer Blocks Agenten-Werkzeug goose und OpenAIs AGENTS.md ein.

Der Weg zur neuen Version war ungewöhnlich lang. Am 21. Mai 2026 veröffentlichte das MCP-Blog den Release Candidate mit dem Bezeichner 2026-07-28. Ein Release Candidate ist eine Vorabversion, die vor der Freigabe noch geändert werden kann. Derselbe Beitrag nannte den 28. Juli als Termin für die finale Spezifikation. Dazwischen lagen zehn Wochen zur Prüfung durch SDK-Maintainer und Entwickler von Clients. Der GitHub-Tag vom 29. Mai trug ausdrücklich den Status Pre-Release.

Am 29. Juni folgten Beta-SDKs für Python, TypeScript, Go und C#. Der zugehörige Blogpost riet Entwicklern, exakte Versionsnummern festzuschreiben, weil sich öffentliche Schnittstellen bis zur stabilen Freigabe noch ändern können. Die offizielle Spezifikationsseite nannte zuletzt weiterhin die Vorgängerversion 2025-11-25 als Basis. Ob die Hauptdokumentation exakt am Stichtag umgestellt wird, ist offen.

Größter Eingriff in die Spezifikation seit der Authorization

David Soria Parra hat MCP bei Anthropic mitentwickelt und warnte Firmen mit eigener Implementierung vor erheblichem Aufwand. Gegenüber The Register nannte er die Revision sinngemäß die umfassendste Änderung an der Spezifikation seit dem Hinzufügen der Authorization.

Craig McLuckie, Chef des Sicherheitsanbieters Stacklok und Mitschöpfer von Kubernetes, sieht einen Reifeschritt. Der zustandsbehaftete Charakter von MCP sei ein Nebenprodukt seiner Herkunft aus lokalen Entwickler-Werkzeugen, sagte er sinngemäß gegenüber The Register. Heute vermittelten Unternehmen über das Protokoll den Zugriff auf Produktivsysteme, was Sicherheitsteams einen einheitlichen Kontrollpunkt gebe.

Widerspruch gegen die Stateless-Entscheidung selbst kommt bislang kaum auf, aber der Aufwand der Migration sorgt für Reibung. Stacklok weist in seinem Leitfaden für Unternehmen darauf hin, dass Abwärtskompatibilität nicht garantiert ist. Die Übergangsfrist ist kein Freibrief, denn Abwärtskompatibilität trägt nur, wenn beide Seiten dieselbe Protokoll-Ära beherrschen oder bewusst Rückfallpfade einbauen.

Was das Model Context Protocol Update 2026 für Unternehmen bedeutet

Wer eigene MCP-Server betreibt, hat mit dem Model Context Protocol Update 2026 eine Migrationsaufgabe im Kalender. Die Breaking Changes treffen vor allem Transport und Session-Verwaltung. Die Frist ist großzügig, der Aufwand aber real. Drei Punkte gehören deshalb zeitnah auf den Prüfstand.

Betrieb: Hängt die Skalierung an Sticky Sessions, lässt sich diese Krücke nach der Migration abbauen.
Authorization: Metadaten-Endpoint, Prüfung des Ausstellers und der Ersatz für Dynamic Client Registration sind Pflichtarbeiten.
Abhängigkeiten: Wer Roots, Sampling, Logging oder Tasks nutzt, muss den Ersatz einplanen.

Der Nutzen der Umstellung liegt im Betrieb, nicht in besseren Antworten der Modelle. Ein stateless Protokoll passt zu Kubernetes, Serverless-Plattformen und Gateways, wie Plattform-Teams sie ohnehin betreiben. Microsoft beschreibt in einem eigenen Beitrag, was sich dadurch beim Hosting auf App Service ändert. Der Preis ist einmalige Arbeit an jeder selbst gebauten Implementierung. Wer MCP nur über die offiziellen SDKs nutzt, kommt mit einem Versionssprung davon. Wer Transport, Session-Verwaltung oder Auth selbst gebaut hat, sollte den Aufwand jetzt schätzen.

Als Nächstes müssen die Beta-SDKs stabil werden, bis dahin gilt die Empfehlung zu festen Versionsnummern. Offen ist, wie schnell das Ökosystem nachzieht. Die offizielle Registry zählte im Mai 2026 in der Größenordnung von 9.000 bis 10.000 aktuelle Server-Einträge. Wie viele davon inzwischen stateless sprechen, ist nicht bekannt. Die Uhr für Roots, Sampling und Logging läuft ab dieser Version. Verschwinden dürfen sie frühestens nach Ablauf der Frist. Dann zeigt sich, ob die neue Lifecycle-Politik hält, was sie verspricht.