Die Kurzfassung
Das Model Context Protocol hat am 28. Juli 2026 seine Spezifikation 2026-07-28 veröffentlicht und MCP damit von einem zustandsbehafteten, Session-basierten Protokoll in ein zustandsloses Request/Response-Protokoll verwandelt. Der initialize-Handshake und der Header Mcp-Session-Id sind entfallen; jede Anfrage trägt jetzt ihre eigene Protokollversion, Identität und Fähigkeiten. Allein diese Änderung erlaubt es, einen Remote-MCP-Server hinter einem gewöhnlichen Load Balancer oder auf Serverless zu betreiben – ohne Sticky Sessions und gemeinsamen Session-Store.
Dazu kommen Header-basiertes Routing, cachebare Tool- und Ressourcenlisten, ein formales Autorisierungsmodell nach OAuth 2.1 und ein versioniertes Erweiterungs-Framework für Apps und Tasks. Für Teams, die KI-Agenten bauen, liegt der Nutzen im Betrieb: Das Bindegewebe zwischen Ihren Modellen und Ihren Werkzeugen lässt sich jetzt günstiger skalieren und leichter absichern.
Was hat die Spezifikation 2026-07-28 konkret geändert?
Das Model Context Protocol ist der offene Standard, über den KI-Modelle an externe Werkzeuge, Daten und Systeme angebunden werden – die Schicht, mit der ein Agent eine Datenbank abfragt, eine API aufruft oder ein Dokument liest. Es hat sich rasant verbreitet: Die Verantwortlichen des Protokolls melden knapp 400 Millionen SDK-Downloads pro Monat, etwa eine Vervierfachung innerhalb eines Jahres; die SDKs für TypeScript und Python haben jeweils mehr als eine Milliarde Downloads insgesamt überschritten, und allein im Connector-Verzeichnis von Claude sind über 950 MCP-Server gelistet. Erreicht ein Standard diese Größenordnung, ist eine Version, die seinen Kern umbaut, keine Fußnote.
Das Release 2026-07-28 bündelt mehrere Änderungen: einen zustandslosen Protokollkern, „Multi Round-Trip Requests“, die vom Server initiierte Aufrufe mit offenem Stream ersetzen, Header-basiertes Routing, cachebare Listenergebnisse, ein an OAuth ausgerichtetes Autorisierungsmodell und ein versioniertes Erweiterungs-Framework, das MCP Apps und Tasks aus dem Kern herauslöst. Die Tier-1-SDKs – TypeScript, Python, Go und C# – implementieren es bereits, ein Rust-SDK ist in der Beta. Die Maintainer selbst beschreiben den Umbau als Abschied von „a lot of things that made MCP“ zu dem, was es war – darin liegen zugleich das Versprechen und die Warnung.
Warum ist die Zustandslosigkeit die eigentliche Schlagzeile?
Die zentrale Änderung: MCP verzichtet auf Sessions auf Protokollebene. Das alte Modell begann mit einem initialize/initialized-Handshake und führte jede weitere Nachricht über eine Mcp-Session-Id. Ein Client und eine bestimmte Serverinstanz mussten also für die gesamte Dauer der Konversation aneinander gebunden bleiben. Im neuen Modell beschreibt sich jede Anfrage selbst: Sie trägt Protokollversion, Client-Identität und Fähigkeiten in den Metadaten und lässt sich daher eigenständig verarbeiten, ohne Erinnerung an das Vorherige.
Das klingt akademisch, bis man es in Produktion betreibt. Ein Remote-MCP-Server, der bisher Sticky Sessions, einen gemeinsamen Session-Store und Deep Packet Inspection am Gateway brauchte, kann jetzt hinter einem einfachen Round-Robin-Load-Balancer stehen, Traffic anhand des Headers Mcp-Method routen und Clients tools/list so lange cachen lassen, wie das ttlMs des Servers es erlaubt. Zustandslosigkeit ist genau die Eigenschaft, mit der gewöhnliche Webdienste horizontal über eine Flotte von Instanzen skalieren – und sie öffnet die Tür dafür, MCP-Server auf Serverless- und Edge-Plattformen zu betreiben. Für ein Agenten-Backend, das sich in Tausende Tool-Aufrufe auffächert, ist das der Unterschied zwischen einem maßgeschneiderten, schwer zu betreibenden Dienst und einem, den Ihr Cloud- und DevOps-Team bereits zu führen weiß.
Wie wird die Autorisierung erwachsen?
Die zweite Änderung, die für alle zählt, die an echte Kunden ausliefern, ist die Autorisierung. Die Spezifikation 2026-07-28 richtet MCP an OAuth 2.0 und OIDC aus, wie sie in Produktion eingesetzt werden: Server agieren als OAuth-2.1-Resource-Server, die Issuer-Validierung nach RFC 9207 wird Pflicht, und Client-Zugangsdaten werden an ihre ausstellende Instanz gebunden, sodass sie sich nicht gegen einen anderen Server wiederverwenden lassen. Dynamic Client Registration ist zugunsten von Client ID Metadata Documents veraltet, und ein neuer Parameter application_type verhindert, dass CLI- und Desktop-Clients wegen Localhost-Redirects abgewiesen werden.
Einfach gesagt: Ein MCP-Server lässt sich jetzt an den Identity Provider anbinden, den ein Unternehmen ohnehin betreibt – Microsoft Entra, Okta und Co. –, ohne den maßgeschneiderten Klebecode, den frühere Deployments brauchten. Genau dieses Kriterium prüfen regulierte Käufer zuerst. Ein Team im FinTech- oder HealthTech-Umfeld kann einen Agenten erst dann auf interne Systeme loslassen, wenn Zugriffe prüfbar und an die Unternehmensidentität gebunden sind. Ein Autorisierungsmodell, das die vorhandene Sprache des Unternehmens spricht, räumt also ein echtes Hindernis aus dem Weg, Agenten in die Nähe sensibler Daten zu bringen.
Was bedeutet das für Softwareteams in der EU und im DACH-Raum?
Ohne den Spezifikationsjargon ist das Release 2026-07-28 ein Reifemeilenstein: MCP entwickelt sich von einem cleveren lokalen Protokoll zu verteilter Infrastruktur, die sich wie jeder andere Dienst ausrollen lässt. Für Teams, die Agenten in ein bestehendes Produkt einweben – Arbeit, die in der GenAI-Integration gelingt oder scheitert, nicht beim Austausch einer einzelnen API –, sinken damit zwei Kosten zugleich. Der zustandslose Kern senkt den Betriebsaufwand für Agenten-Tooling im großen Maßstab, und das OAuth-Modell verringert die Reibung bei Sicherheit und Compliance, wenn dieses Tooling an echte Systeme angeschlossen wird.
Lesen Sie den Kompatibilitätshinweis aber ehrlich, denn genau hier gehen Migrationen schief. Die Revision 2026-07-28 ist die größte, die MCP je vorgenommen hat, und Server der neuen Generation sind mit älteren Clients womöglich nicht kompatibel, sofern nicht eine Seite bewusst einen Fallback oder eine Übersetzung implementiert. Roots, Sampling und Logging sind veraltet – mit einem Supportfenster von mindestens 12 Monaten –, und der Legacy-Transport HTTP+SSE läuft aus. Hängen Ihre Agenten an einem dieser Bausteine oder betreiben Sie eine Mischung aus Client- und Serverversionen, bricht ein naives Upgrade still und leise Dinge. Richtig ist eine schrittweise Migration, die am Edge beide Protokollgenerationen am Leben hält, bis alles umgezogen ist.
Es gibt auch eine strategische Lesart für Teams, die entscheiden müssen, worauf sie setzen. MCP ist ursprünglich bei Anthropic entstanden, inzwischen aber ein offener Standard mehrerer Anbieter, und konkurrierende Agentenprotokolle bringen sich in Stellung. Eine Spezifikation, die MCP wirklich produktionstauglich macht – zustandslos, cachebar, OAuth-nativ –, ist ein Versuch, der Standard zu bleiben. Für die meisten Teams lautet die pragmatische Antwort nicht, einen Gewinner zu küren, sondern die Tool-Calling-Schicht abstrahiert zu halten: So können Sie das neue MCP jetzt einführen, ohne festzusitzen, falls sich die Standardlandschaft erneut verschiebt.
Wie setzen Sie das noch in diesem Quartal um?
Behandeln Sie das als Infrastrukturmigration mit Rollback-Plan, nicht als Versionssprung am selben Tag. Hier die umsetzbare Version.
- MCP-Landschaft erfassen. Listen Sie jeden MCP-Server und -Client auf, den Sie betreiben – intern wie von Drittanbietern –, und halten Sie fest, welche Protokollgeneration jeder heute unterstützt.
- Auf ein Tier-1-SDK wechseln. Aktualisieren Sie auf die Builds der SDKs für TypeScript, Python, Go oder C#, die 2026-07-28 unterstützen, und pinnen Sie Versionen, damit Upgrades bewusst erfolgen.
- Beide Generationen am Edge am Leben halten. Setzen Sie am Gateway eine Kompatibilitäts- oder Übersetzungsschicht ein, damit neue Server und alte Clients koexistieren, bis alle Seiten migriert sind – nicht umschalten und hoffen.
- Autorisierung an Ihren IdP anbinden. Konfigurieren Sie MCP-Server als OAuth-2.1-Resource-Server gegen Entra, Okta oder Ihren bestehenden Anbieter und validieren Sie Issuer nach RFC 9207.
- Den zustandslosen Pfad unter Last testen. Weisen Sie nach, dass Anfragen hinter einem Standard-Load-Balancer korrekt geroutet werden, prüfen Sie, ob Ihr
ttlMs-Caching für Ihre Daten unbedenklich ist, und stellen Sie sicher, dass veraltete Funktionen, auf die Sie angewiesen sind, im Supportfenster weiter funktionieren. - Eine verantwortliche Person benennen. Agenten-Infrastruktur entwickelt sich inzwischen so schnell wie die Modelle. Bestimmen Sie jemanden, der Spezifikation, SDK-Releases und Abkündigungsfristen verfolgt, statt einen Bruch erst in Produktion zu entdecken.
Nichts davon ist Rechtsberatung, und der genaue Aufwand hängt davon ab, wie viel Ihres Stacks bereits MCP spricht. Das strategische Signal ist aber klar: Die Werkzeugschicht unter KI-Agenten wird zu standardisierter, skalierbarer Infrastruktur – und im Vorteil sind Teams, die sie auch so behandeln und auf Deployment und Identität hin entwickeln, statt jeder neuen Fähigkeit hinterherzulaufen.
Häufig gestellte Fragen
Was hat sich mit der MCP-Spezifikation 2026-07-28 geändert?
Die am 28. Juli 2026 veröffentlichte Spezifikation 2026-07-28 des Model Context Protocol ersetzt das bidirektionale, zustandsbehaftete Protokoll durch einen zustandslosen Request/Response-Kern. Der initialize-Handshake und der Header Mcp-Session-Id entfallen; jede Anfrage trägt ihre eigene Protokollversion, Client-Identität und Fähigkeiten. Neu sind Header-basiertes Routing über Mcp-Method und Mcp-Name, cachebare Antworten auf tools/list, prompts/list und resources/list mit ttlMs, eine strengere Autorisierung nach OAuth 2.1 und ein versioniertes Erweiterungs-Framework für Apps und Tasks.
Warum ist ein zustandsloses MCP für Teams mit KI-Agenten wichtig?
Zustandslosigkeit nimmt Remote-MCP-Servern den Betriebsaufwand. Ohne Protokoll-Sessions kann jede Anfrage auf jeder Serverinstanz landen. Ein Server läuft damit hinter einem einfachen Round-Robin-Load-Balancer oder auf Serverless- und Edge-Plattformen, statt Sticky Sessions und einen gemeinsamen Session-Store zu benötigen. Agenten-Backends lassen sich so günstiger skalieren und einfacher betreiben, und Gateways können anhand von Headern routen und drosseln, ohne JSON-Bodys zu parsen.
Bricht die neue MCP-Spezifikation meine bestehenden Server und Clients?
Das kann passieren. Die Revision 2026-07-28 ist die bislang größte Änderung an MCP, und Server auf der neuen Revision sind mit älteren Clients womöglich nicht kompatibel, sofern nicht eine Seite einen Fallback oder eine Übersetzungsschicht implementiert. Roots, Sampling und Logging sind als veraltet markiert, mit einem Supportfenster von mindestens 12 Monaten; auch der Legacy-Transport HTTP+SSE ist veraltet. Planen Sie eine Migration statt eines Umschaltens: Unterstützen Sie am Edge beide Protokollgenerationen, bis alle Clients und Server umgezogen sind.
Wie ändert sich die MCP-Autorisierung mit der Spezifikation 2026-07-28?
Die Autorisierung orientiert sich jetzt an OAuth 2.0 und OIDC, wie sie in Produktion eingesetzt werden. MCP-Server agieren als OAuth-2.1-Resource-Server, die Issuer-Validierung nach RFC 9207 ist Pflicht, und Dynamic Client Registration ist zugunsten von Client ID Metadata Documents veraltet. In der Praxis lässt sich ein MCP-Server so an Enterprise-Identity-Provider wie Microsoft Entra oder Okta anbinden – ohne die Umwege, die frühere Deployments brauchten.
Was sollten Teams vor der Einführung der MCP-Spezifikation 2026-07-28 tun?
Erfassen Sie alle MCP-Server und -Clients, die Sie betreiben, klären Sie, welche Protokollgeneration jeder unterstützt, und aktualisieren Sie auf die Tier-1-SDKs (TypeScript, Python, Go oder C#). Setzen Sie am Gateway eine Kompatibilitätsschicht ein, damit alte und neue Clients während der Migration koexistieren, binden Sie die Autorisierung an Ihren bestehenden Identity Provider an und testen Sie den zustandslosen Pfad unter Last hinter einem Standard-Load-Balancer. Behandeln Sie das Ganze als Infrastrukturmigration mit Rollback-Plan, nicht als Upgrade am selben Tag.
Quellen
Model Context Protocol — The 2026-07-28 Specification, 28 July 2026 (primary source)
The Register — Model Context Protocol prepares to break with its stateful past, 23 July 2026
Anthropic — MCP 2026-07-28 spec: stateless core, coming to Claude, July 2026