MCP 28.07.2026: Überarbeitung von Apps, Tasks und Gateway-Governance nach der größten Protokolländerung seit dem Start

Ende Juli veröffentlichten wir unsere Analyse zur Steuerung von MCP-Apps und -Tasks am Gateway – und das Protokoll lieferte prompt eine Fortsetzung. Am 28. Juli 2026 wurde die finale Spezifikation des Model Context Protocol planmäßig veröffentlicht, nachdem die Maintainer sie in ihrer Release-Candidate-Beschreibung – den acht Wörtern, die wir hier einmal zitieren – als „die größte Überarbeitung des Protokolls seit dem Start“ bezeichneten (die offizielle RC-Ankündigung). Dieser Umfang rechtfertigt das Label. Der Kern wird zustandslos: Protokoll-Sessions und der Mcp-Session-Id-Header entfallen, der Initialisierungs-Handshake wurde gestrichen, Anfragen werden über Mcp-Method- und Mcp-Name-Header geroutet, Ergebnisse von Listen- und Ressourcen-Lesezugriffen enthalten Cache-Hinweise, und Anwendungen, die einen zustandsübergreifenden Kontext benötigen, können explizite Handles erstellen – eine basket_id, eine ticket_id –, die von Tools zurückgegeben und als normale Argumente übergeben werden. Ein Muster, das die Maintainer gegenüber transportverborgenem Zustand empfehlen, da das Modell das Handle sehen und zwischen Tools weiterreichen kann (die Release Notes). Ein formales Extensions-Framework hält Einzug, mit Reverse-DNS-Identifikatoren und unabhängig versionierten Repositories – und die beiden Funktionen, die wir in unserem Juli-Beitrag analysiert haben, gehören zu den ersten offiziellen Bestandteilen: MCP Apps (server-gerenderte interaktive UI, in einer Sandbox auf dem Host, deren App-initiierte Tool-Aufrufe den regulären tools/call-Pfad durchlaufen) und Tasks, die aus dem experimentellen Kern in io.modelcontextprotocol/tasks überführt wurden, mit einem neu gestalteten, auf Polling basierenden Lebenszyklus – tasks/get, tasks/update, kooperatives tasks/cancel –, was eine explizite Breaking Change für alle darstellt, die auf Basis der experimentellen API vom 25.11.2025 entwickelt haben (WorkOS-Migrationsanalyse; BOVOs Hinweise zu Breaking Changes). Die Autorisierung wurde im Hinblick auf gängige OAuth/OIDC-Praktiken über sechs SEPs hinweg verschärft, Dynamic Client Registration wurde zugunsten von CIMD als veraltet markiert, und das Protokoll erhält einen formalen Deprecation-Lebenszyklus: Roots, Sampling, Logging und DCR können frühestens mit einer Revision entfernt werden, die am oder nach dem 28. Juli 2027 veröffentlicht wird, während der Legacy-HTTP+SSE-Transport – bereits seit 2025 als veraltet markiert – dem separat veröffentlichten Übergangsplan der Lifecycle-Policy folgt (das Verzeichnis veralteter Funktionen). Die Einführung erfolgte vom ersten Tag an: Alle vier Tier-1-SDKs unterstützten die neue Spezifikation bereits zum Release. AWS, Google Cloud, Microsoft und Cloudflare gehörten zu den Unterstützern zum Start, und Claude sowie Claude Desktop zählen zu den Hosts, die bereits MCP-Apps rendern (der Release-Beitrag; die Apps-Dokumentation). Die These unseres Beitrags vom Juli – dass Apps und Tasks jeweils eine Governance-Oberfläche eröffnen, die das Gateway schließen muss – hat die Überarbeitung unverändert überstanden. Die finale Spezifikation fügt jedoch Nuancen hinzu, die wir damals noch nicht hatten. Drei davon verändern, wie ein Unternehmen sein eigenes MCP-Portfolio in diesem Quartal bewerten sollte. Dieser Beitrag ist die versprochene Nachbetrachtung: Was hat sich zwischen der Spezifikation, auf der unser Beitrag basierte, und der nun veröffentlichten Version geändert? Ein Vorher-Nachher-Diagramm und die neue Governance-Arbeit, die durch jede Änderung entsteht.

1. Vorher und Nachher: Was sich tatsächlich geändert hat

Unser Beitrag vom Juli basierte auf dem Stand vom 25.11.2025: ein zustandsbehaftetes Protokoll (Sticky Sessions, ein Initialisierungs-Handshake, Session-ID-Header, die Gateways nachverfolgen mussten), Tasks als experimentelles Kernfeature, MCP-Apps, die sich separat als Erweiterung unter einem noch informellen Erweiterungsprozess entwickelten, Benachrichtigungen über einen veralteten HTTP-GET-Stream und ein Autorisierungsmodell, das sich noch auf Dynamic Client Registration konzentrierte. Die finale Version vom 28.07.2026 ersetzt jeden dieser Pfeiler, und die praktischen Auswirkungen auf die Produktionstopologie sind unmittelbar: Ein entfernter MCP-Server, der bisher Sticky Sessions und einen gemeinsamen Session-Speicher benötigte, kann nun hinter einem einfachen Round-Robin-Load-Balancer mit cachebaren Tool-Listen betrieben werden – das Protokoll wurde für die gängige HTTP-Infrastruktur optimiert, was auf der Transportebene genau das bedeutet, was man unter „Enterprise-Ready“ versteht (die RC-Ankündigung). Das Diagramm und die Tabelle unten zeigen die Änderungen auf einen Blick; drei Zeilen verdienen die von uns gesetzte Markierung. Der Umzug von Tasks in die Erweiterung ist ein Breaking Change – die experimentelle API vom 25.11.2025, die unser Beitrag beschrieb, wird nicht weitergeführt, und interne Server, die darauf basieren, müssen jetzt überprüft werden. Die Deprecations sind moderat, aber zeitlich festgelegt, mit feature-spezifischen Fristen – unter dem neuen Lebenszyklus Aktiv→Veraltet→Entfernt bleiben Roots, Sampling, Logging und DCR für mindestens zwölf Monate funktionsfähig und können frühestens mit einer Revision entfernt werden, die am oder nach dem 28. Juli 2027 veröffentlicht wird. Der veraltete HTTP+SSE-Transport, der bereits seit 2025 als veraltet gilt, folgt der Übergangsregel der Lifecycle-Richtlinie und sollte anhand seines separat veröffentlichten Zeitplans für die Entfernung verfolgt werden (das normative Verzeichnis veralteter Funktionen). Und die Härtung der Authentifizierung liegt teilweise auf der Client- Seite – die Abwehr von Mix-up-Angriffen, die in den Sicherheitsanalysen priorisiert wird (SEP-2468), ist eine Aufgabe des Clients. Das ist wichtig für die Frage, wer im Unternehmen dies tatsächlich implementiert – ein Punkt, auf den Abschnitt 3 zurückkommt.

2. Drei Nuancen, die wir unserer Analyse vom Juli hinzufügen würden

Wo Anwendungen Kontinuität benötigen, ersetzen explizite Handles den verborgenen Transportzustand – und sie befinden sich im Transkript. Der elegante Schachzug des zustandslosen Designs besteht darin, dass Kontext, den ein Server beibehalten möchte, nun als explizites Handle übertragen wird, das das Modell als gewöhnliches Argument zurückgibt. Dies ist ein Muster, das die Entwickler gegenüber transportverborgenem Zustand empfehlen, da das Modell das Handle sehen, darüber nachdenken und es zwischen Tools weitergeben kann (die offiziellen Release-Notes). Die Governance-Nuance, die unser Beitrag vom Juli nicht erfassen konnte: Ein Handle im Modellkontext ist ein fähigkeitsähnliches Artefakt im Klartext – eine basket_id oder ticket_id, die einen aktiven serverseitigen Zustand benennt, für alles sichtbar ist, was das Transkript lesen kann, und je nach Implementierung über eine Kompaktierung hinweg dauerhaft ist oder nicht. Ob ein erfasstes Handle wiederverwendbar ist, hängt vom Server ab: Ein Handle wird sicherheitskritisch, wenn der bloße Besitz ausreicht, um den serverseitigen Zustand wiederherzustellen oder zu verändern. Server sollten es daher als opak behandeln, jede Verwendung gegenüber dem aktuellen Principal autorisieren, keine Geheimnisse darin einbetten und es gemäß den Richtlinien protokollieren oder schwärzen. Handles reihen sich somit in die Liste der Dinge ein, die bei der Trace-Verfolgung auf Anforderungsebene an Principals gebunden werden sollten: Wer hat dieses Handle erstellt, unter wessen Autorität, und präsentiert der Aufrufer es innerhalb des Workflows, für den es erstellt wurde? Tasks machen die zeitliche Gültigkeit von einem theoretischen Problem zu einem geplanten Verhalten. Unsere Arbeit zur Autorisierungspropagierung hat gezeigt, dass lange Workflows ihre Berechtigungen überdauern; die formalisierte Tasks-Erweiterung macht dies zur erwarteten Form – die Arbeit wird serverseitig fortgesetzt, während der Client tasks/get abfragt – sodass die Frage „Ist die Autorisierung, die diese Aufgabe gestartet hat, bei Abschluss noch gültig?“ nun einen standardisierten Ort hat, an dem sie gestellt werden kann, jedoch in der Erweiterung selbst keine vorgeschriebene Antwort erhält. Die Hygiene des asynchronen Musters ist daher Anwendungsarbeit: Implementierungen sollten eine Verknüpfung zwischen jeder Aufgabe und dem Principal sowie dem Autorisierungskontext, unter dem sie erstellt wurde, beibehalten, den Aufwand der Aufgabe zuordnen und den Widerruf auf laufende Arbeiten übertragen – wobei zu beachten ist, dass tasks/cancel kooperativ ist, der Server also die Absicht anerkennt, aber nicht verpflichtet ist, sie zu stoppen (die Tasks-Erweiterung). Apps sind eine Phishing-Angriffsfläche mit einem rettenden Aspekt. Die Sicherheitsanalysen haben recht damit, dass serverseitig gerenderte UI innerhalb eines vertrauenswürdigen Client-Chroms einen auf den Benutzer abzielenden Phishing-Weg schafft – das Problem der vertrauenswürdigen Schnittstelle (Akamais Bewertung) – und sie haben recht damit, dass der gerenderte Inhalt als nicht vertrauenswürdig behandelt und in einer Sandbox isoliert werden muss. Der rettende Aspekt ist architektonischer Natur, mit einer Grenze, die präzise gezogen werden sollte: Eine App und ihr Host kommunizieren über einen JSON-RPC-Dialekt von MCP via postMessage, bei dem einige Nachrichten gewöhnliche MCP-Operationen wie tools/call sind und die meisten app-spezifische ui/*-Nachrichten (die Apps-Dokumentation). Tool-Aufrufe, die eine App anfordert, werden vom Host als gewöhnliche tools/call-Anfragen weitergeleitet – der Klick, der eine serverseitige Aktion auslöst, ist also kein Seitenkanal; er erreicht dieselbe Governance-Ebene wie ein direkter Aufruf, wo Zustimmung, Richtlinien und Audit bereits existieren. Der ui/*-Datenverkehr hingegen verlässt niemals den Rendering-Client, der seine eigenen Sandbox- und Allow-List-Verpflichtungen beibehält. Die Tool-Call-Oberfläche wird zum Engpass geleitet; die UI-Oberfläche bleibt am Rand – und beide müssen an ihren jeweiligen Stellen reguliert werden.

3. Das Migrationsquartal: Wo sich das Gateway bezahlt macht

Hier kommt TrueFoundry ins Spiel, und die endgültige Spezifikation schärft die Rolle, die unser Beitrag vom Juli zugewiesen hat, anstatt sie zu verändern: das MCP-Gateway: Wenn das Protokoll selbst migriert, wird die Ebene, die jeder geroutete MCP-Aufruf durchläuft, zu drei Dingen gleichzeitig. Das Inventar. Die erste Frage bei jeder Migration – wer betreibt was – lässt sich nicht durch Umfragen, sondern durch die Analyse des Datenverkehrs beantworten, da moderne MCP-Anfragen bei jedem Aufruf ihre Protokollversion, Client-Identität, Fähigkeiten und Methoden-Metadaten übermitteln. Dies in ein Migrationsinventar zu verwandeln, ist eine Aufgabe der Protokollierung und Berichterstattung, kein bereits existierendes Häkchen: Die aktuelle öffentliche Metrik-Dokumentation von TrueFoundry deckt MCP-Server, Tools, Methoden, Aufrufer, Latenz, Fehler und den Traffic-Mix ab – das Attributions-Substrat. Die Beibehaltung und Bereitstellung von Protokollversions-, Client- und Session-Header-Feldern aus den Anfragedatensätzen ist das erste Konfigurationsziel für dieses Quartal. Der Implementierungspunkt für alle. Die clientseitige Härtung der Spezifikation – Issuer-Validierung (SEP-2468), Bindung von Anmeldeinformationen an den Issuer, der CIMD-Übergang weg von DCR – ist Arbeit, die jeder MCP-Consumer sonst separat und uneinheitlich implementieren müsste. Da das Gateway als nachgelagerter MCP-Client der Infrastruktur fungiert und die Anforderungen vom 28.07.2026 umsetzt, kann es diese Haltung zentralisieren, sodass jeder dahinterliegende Agent davon profitiert – dieselbe Konsolidierungslogik, die unsere OAuth-auf-MCP-Ebene Analyse für die Token-Handhabung entwickelt hat, und eine natürliche Ergänzung zu den Okta- und Azure AD-Integrationen sowie dem zentralen Anmeldeinformationsmanagement die TrueFoundry heute dokumentiert; die Unterstützung für jede neue Spezifikationsanforderung sollte anhand der bereitgestellten Gateway-Version überprüft werden. Der Ort, an dem die neuen Oberflächen Richtlinien erhalten. Hier zählt die dokumentierte/empfohlene Linie, also ziehen wir sie. TrueFoundry dokumentiert derzeit die zentrale MCP-Authentifizierung, Zugriffskontrollen auf Server- und Tool-Ebene, Tool-Freigaben, Leitplankenvor und nach Tool-Aufrufen, Request-Tracing und MCP-Metriken – Kontrollen, die für jeden Tool-Aufruf gelten, der das Gateway passiert, einschließlich Aufrufen, die eine MCP-App über ihren Host initiiert. App-Sandboxing und das Rendern von Allow-Listen finden auf der Ebene des Rendering-Clients statt; Identität für den Aufgabenlebenszyklus, Budget-Attribution pro Aufgabe, Widerruf laufender Arbeiten und die Bindung von Handles an Principals sind die Governance-Kontrollen, die diese Revision empfiehlt – eine Referenzarchitektur, auf der auf diesem dokumentierten Substrat aufgebaut werden kann, keine ausgelieferten Einzelfunktionen. Nichts davon erforderte eine Änderung der Spezifikation – was die stille Bestätigung ist, die man klar aussprechen sollte: Die Revision vom 28.07.2026 hat die Sicherheitsgrenzen des Protokolls erheblich verschoben (Sitzungen entfallen, Authentifizierung verlagert, neue Erweiterungsoberflächen), und eine Infrastruktur, deren Governance auf der Gateway-Ebene angesiedelt war, begegnet dem Großteil der Änderungen durch Konfiguration, während eine Infrastruktur, deren Governance in der sitzungsbasierten Logik pro Server und im Authentifizierungscode pro Client lag, nun ihre Kontrollen zusammen mit ihrem Protokoll migrieren muss. Das gesamte Wertversprechen der Governance am Flaschenhals besteht darin, dass der Flaschenhals die Spezifikationsversionen überdauert, die ihn durchlaufen – und dies ist die erste MCP-Revision, die groß genug ist, um dies auf die Probe zu stellen.

4. Grenzen, klar benannt

Quellen und Einschränkungen. Die Änderungen an der Spezifikation – der zustandslose Kern, das Erweiterungs-Framework, die Neugestaltung der Tasks und deren Status als Breaking Change, die App-Mechanik, die Autorisierungs-SEPs, Veraltungen, Zeitpläne und Fakten zur Einführung – entsprechen den offiziellen MCP-Release-Posts, den Spezifikationsseiten und dem Register für veraltete Funktionen. Die zitierten Analysen (WorkOS, Stacktree, Akamai, AAIF, BOVO) dienen der Interpretation, der Migrationserfahrung und als Sicherheitskommentar; alles wurde paraphrasiert, mit einem Zitat von unter fünfzehn Wörtern, das den Betreuern zugeschrieben wird. Die Spezifikation ist zum Zeitpunkt dieses Schreibens erst gut eine Woche alt; Implementierungsdetails werden sich in den kommenden Monaten festigen. Leser sollten die offizielle Spezifikation und das Changelog als maßgeblich gegenüber jeder Zusammenfassung betrachten, einschließlich unserer eigenen. Unser Beitrag vom Juli wird erneut aufgegriffen, nicht widerrufen – seine Governance-Rahmenbedingungen gelten weiterhin; wo dieser Beitrag abweicht, ist dieser Beitrag aktuell. Unser Interesse ist offengelegt: Wir verkaufen die MCP-Gateway-Schicht, von der dieser Beitrag behauptet, dass sie die Migration begünstigt, und der Anspruch ist entsprechend begrenzt – das Gateway steuert den Traffic, der es tatsächlich durchläuft, konsolidiert clientseitige Verpflichtungen, wo es als MCP-Client der Umgebung fungiert, und beobachtet, was es routet; es aktualisiert keine Server für Sie, macht die Tasks-Migration für Umgebungen, die die experimentelle API übernommen haben, nicht optional, sieht keinen ui/*-Traffic des App-Hosts und ersetzt nicht die Sandboxing-Arbeit, die Apps am Rendering-Client erfordern. Zwei ehrliche Einschränkungen. Erstens: Die Sicherheitsverbesserungen der Spezifikation sind real und auf Protokollebene angesiedelt – die Fixierung der Session-ID auf Protokollebene und die Angriffsfläche für Hijacking wurden vollständig entfernt. Server-initiierte Anfragen können nun nur noch gestellt werden, während der Server eine Client-Anfrage verarbeitet, sodass jede Anforderung auf etwas zurückzuführen ist, das der Benutzer oder sein Agent gestartet hat – was bedeutet, dass einige der Dinge, die Gateways kompensiert haben, nun einfach behoben sind; eine faire Bilanz zeigt, dass sich die Aufgabenliste der Ebene verschoben hat, sie ist nicht nur gewachsen. Zweitens: Die Governance von Erweiterungen ist noch jung: Welche Erweiterungen ein Unternehmen pro Team zulässt, ist eine Richtlinienebene, die das Framework schafft und für die noch niemand ausgereifte Praktiken hat – wir gehen davon aus, dass wir auch darauf zurückkommen werden. Was die Woche klar zu sagen erlaubt: Das Protokoll hat gerade seinen Anspruch erhoben, Infrastruktur zu sein – zustandslos, erweiterbar, datierte Veraltungen, unternehmensgerechte Autorisierung – und Protokolle auf Infrastrukturniveau verdienen eine Governance auf Infrastrukturniveau. Das ist die These, die unser Beitrag vom Juli vertrat und die die Spezifikation vom Juli dankenswerterweise gerade erweitert hat.

Referenzen

• Primärquellen – MCP-Betreuer, „The 2026-07-28 Specification“ (zustandsloser Kern; Header-Routing; Cache-Hinweise; Autorisierungsänderungen; Tasks und SEP-2663; Abonnements/Listen; Veraltungen; Day-One-SDK-Status und Launch-Unterstützungen); der Release-Candidate-Post (die zitierte Charakterisierung; die sechs Autorisierungs-SEPs; MRTR und SEP-2260; das Handle-Muster; zustandslose Topologie); das normative Register für veraltete Funktionen (Entfernungsberechtigung pro Funktion, einschließlich des separaten Zeitplans für HTTP+SSE); MCP-Apps-Dokumentation (der JSON-RPC-Dialekt, ui/*-Nachrichten, Sandbox-Modell, Client-Unterstützung); die Tasks-Erweiterung (Lebenszyklus, tasks/update, kooperative Abbruchsteuerung). Analysen — WorkOS (Migrationsanalyse); Stacktree (Changelog-Details; Adoptions- und Connector-Zahlen); Akamai Sicherheitsforschung (neue Missbrauchsmöglichkeiten); AAIF-Migrationsleitfaden; BOVO (Erfahrungen bei der Unternehmensmigration).
• TrueFoundry-Dokumentation — MCP Gateway (offizielles Architekturdiagramm); MCP-Authentifizierung & Sicherheit; Guardrails, einschließlich Tool-Call-Flow (offizielles Diagramm); Budgets; Analysen.
• Dieser Blog – die Analyse vom Juli, die dieser Beitrag erneut aufgreift; OAuth und Token-Management auf der MCP-Ebene; MCP-Gateway vs. Proxy vs. Router; MCP-Transporte im Unternehmen; Tool-Poisoning und Gateway-Abwehr; das zentrale MCP-Register.

Es wird ein direktes Zitat mit weniger als fünfzehn Wörtern verwendet, das im Text den Betreuern des Protokolls über die zitierte Ankündigung des Release-Kandidaten zugeschrieben wird; alle Spezifikationsdetails sind aus den offiziellen Beiträgen, Spezifikationsseiten und zitierten Analysen paraphrasiert, wobei die eine Woche alte endgültige Spezifikation und ihr Änderungsprotokoll maßgeblich für diese Zusammenfassung sind. Dieser Beitrag greift unsere Analyse vom Juli erneut auf und aktualisiert sie, anstatt sie zu widerrufen. Unser kommerzielles Interesse an der MCP-Gateway-Ebene wird im Text offengelegt, und die sicherheitstechnischen Verbesserungen des Protokolls werden als solche gewürdigt. Die Funktionen von TrueFoundry werden auf Basis der zum Zeitpunkt der Erstellung aktuellen öffentlichen Dokumentation dargestellt, wobei dokumentierte Features von empfohlenen Governance-Mustern unterschieden werden; die Produktbilder stammen aus der eigenen Dokumentation von TrueFoundry und wurden mit Quellenangabe reproduziert.

‍