Amazon AWS unterstützt zustandsloses MCP, doch Kompatibilität ist nun der eigentliche Test

Amazon AWS hat AgentCore Gateway zwei Tage, nachdem die größte Architekturüberarbeitung der Spezifikation stabil veröffentlicht wurde, um Unterstützung für MCP 2026-07-28 ergänzt. Ein einziger UpdateGateway-Aufruf kann die neue Protokollversion auf einem bestehenden Gateway aktivieren. Hinter der einfachen Control-Plane-Änderung verbirgt sich jedoch ein anspruchsvollerer Übergang für Clients, Server und Enterprise-Sicherheitsteams.

Die neue Revision des Model Context Protocol entfernt Sitzungen auf Protokollebene und lässt jede Anfrage ihre eigene Version und ihre Client-Fähigkeiten beschreiben. MCP ist ein offener Standard zur Verbindung von AI-Anwendungen mit Tools, Datenquellen und anderen Diensten. Sein zustandsloses Design soll Gateways einfacher skalierbar, routbar und wiederherstellbar machen.

Dieser Vorteil bringt einen Kompatibilitätstest mit sich. Clients müssen neue Anfrage-Metadaten übernehmen, Server Discovery implementieren, und frühere Annahmen über Sitzungen gelten nicht länger. Amazon Bedrock AgentCore Gateway steht nun zwischen diesen beiden Protokoll-Ären, übersetzt Enterprise-Dienste in MCP-Tools und setzt Zugriffskontrollen an einem verwalteten Endpunkt durch.

Die eigentliche Geschichte geht daher über ein Versionskontrollkästchen hinaus. Amazon AWS setzt darauf, dass ein verwaltetes Gateway den Protokollwandel auffangen kann, bevor er jedes Anwendungsteam erreicht. Ob das gelingt, hängt von Versionsaushandlung, korrekter Autorisierung und dem Verhalten gemischter Client-Flotten ab.

Amazon AWS macht aus einer großen MCP-Überarbeitung ein einzelnes Gateway-Update

AWS hat den Infrastruktur-Schritt auf eine API-Operation reduziert, doch Anwendungen müssen das überarbeitete Protokoll weiterhin korrekt sprechen.

Die MCP-Maintainer veröffentlichten die stabile Spezifikation 2026-07-28 am 28. Juli, nach einer Release-Candidate-Phase, die im Mai begann. Das stabile MCP-Release ersetzt mehrere Annahmen, die während des frühen Wachstums des Protokolls etabliert wurden.

AWS folgte mit Unterstützung in Amazon Bedrock AgentCore Gateway. Laut dem AgentCore-Update des Unternehmens können Gateway-Besitzer die neue Revision über UpdateGateway hinzufügen. Die Anfrage aktualisiert die MCP-Protokollkonfiguration des Gateways und seine Liste unterstützter Versionen.

Das relevante Control-Plane-Objekt ist protocolConfiguration.mcp.supportedVersions. AWS dokumentiert dieses Feld als Array von MCP-Versionen, die das Gateway verwenden kann. UpdateGateway gibt den HTTP-Status 202 zurück, wenn der Dienst ein Update annimmt; anschließend durchläuft das Gateway einen Aktualisierungsstatus.

Diese Unterscheidung ist operativ wichtig. Ein angenommener Aufruf bedeutet nicht, dass jeder verbundene Client bereits eine erfolgreiche Anfrage abgeschlossen hat. Teams sollten warten, bis das Gateway in seinen Bereitschaftsstatus zurückkehrt, und dann Konformitäts- und Workload-Tests gegen den tatsächlichen Endpunkt ausführen.

Die Änderung erfordert nicht, dass Unternehmen jede Lambda-Funktion, jeden OpenAPI-Dienst oder jeden Smithy-Dienst hinter ihrem Gateway neu aufbauen. AgentCore Gateway wandelt diese Ressourcen bereits in MCP-kompatible Tools um. Je nach Zielkonfiguration unterstützt es zudem Remote-MCP-Ziele und andere HTTP-Dienste.

Diese Architektur ermöglicht AWS Änderungen an der protokollseitigen Ebene, ohne dass jeder nachgelagerte Geschäftsdienst identisch angepasst werden muss. So kann beispielsweise eine Kundensupport-API eine API bleiben, während das Gateway ihre Operationen als Tools für kompatible Agents bereitstellt.

AgentCore Gateway übernimmt zudem eingehende Authentifizierung, ausgehende Anmeldedaten, Tool-Discovery, Routing und die Durchsetzung von Richtlinien. Diese Kontrollen werden noch wertvoller, wenn ein Endpunkt Dienste mehrerer interner Teams bündelt.

Der UpdateGateway-Aufruf ändert jedoch nur die deklarierte Unterstützung des Gateways. Ein Client, der die Revision 2026 verwendet, muss weiterhin die erforderlichen Metadaten und Header senden. Ein älterer Client muss eine beidseitig unterstützte Revision aushandeln oder einen kompatiblen Fallback-Pfad verwenden.

Das ist die erste Einschränkung hinter der einfachen Upgrade-Botschaft von AWS. Der verwaltete Dienst kann den Plattformaufwand senken, aber er kann ein veraltetes SDK nicht dazu bringen, ein neues Wire-Format auszugeben.

Die zweite Einschränkung betrifft Tests. Gateway-Besitzer müssen Tool-Auflistungen, Tool-Aufrufe, Authentifizierungsfehler, Streaming-Verhalten und Cache-Kontrollen unter jeder unterstützten Version überprüfen. Erfolg mit einem modernen Client belegt keine Kompatibilität in einer gesamten Enterprise-Flotte.

Ein praktischer Rollout beginnt daher mit einer Bestandsaufnahme. Teams müssen feststellen, welche Agent-Anwendungen mit dem Gateway verbunden sind, welche SDK-Versionen sie verwenden und ob diese SDKs MCP 2026-07-28 unterstützen.

Unternehmen, die technische Entscheidungen und Testnachweise in einer durchsuchbaren Engineering-Wissensbasis pflegen, können Ergebnisse nach Client und Protokollversion dokumentieren. Dieser Nachweis wird wichtig, wenn ein Fehler nur in einem Framework oder Bereitstellungskanal auftritt.

AWS hat die Control-Plane-Aktion klein gehalten. Die Überprüfung auf Anwendungsebene bleibt das eigentliche Migrationsprojekt.

Warum zustandsloses MCP die Gateway-Gleichung verändert

Zustandsloses MCP verlagert Kompatibilitätsinformationen in jede Anfrage, vereinfacht horizontales Routing und zwingt zugleich jede Nachricht, für sich allein zu stehen.

Frühere MCP-Revisionen nutzten einen Initialisierungsaustausch, um Protokolldetails und Fähigkeiten festzulegen. Ein Client sendete initialize, der Server antwortete, und der Client schloss die Sequenz mit notifications/initialized ab. Streamable HTTP konnte zudem einen Mcp-Session-Id-Header verwenden, um späteren Datenverkehr einer Sitzung auf Protokollebene zuzuordnen.

Die zentralen MCP-Änderungen entfernen diesen Lebenszyklus in der neuen Revision. Sie entfernen auch die Sitzungskennung auf Protokollebene. Server, die über Aufrufe hinweg Zustand benötigen, müssen explizite Handles ausgeben, die Clients als reguläre Tool-Argumente übergeben.

Jede Anfrage im neuen Stil enthält ihre Protokollversion und Client-Fähigkeiten in _meta. Clients sollten sich dort ebenfalls identifizieren. Server geben ihre Identität in Ergebnis-Metadaten zurück, wodurch jeder Austausch stärker selbsterklärend wird.

Eine neue Methode server/discover ermöglicht es einem Client, unterstützte Versionen, Fähigkeiten und die Serveridentität zu prüfen, bevor weitere Arbeit beginnt. Ein Server, der die Revision 2026-07-28 verwendet, muss diesen Remote-Procedure-Call implementieren.

Dieses Design verändert, woran sich ein Gateway erinnern muss. Es muss nicht länger von einem über eine einzelne Verbindung abgeschlossenen Initialisierungsaustausch abhängen oder späteren Protokollverkehr einer undurchsichtigen MCP-Sitzung zuordnen.

Ein Load Balancer kann einzelne Anfragen routen, ohne Affinität auf Protokollebene aufrechterhalten zu müssen. Eine Gateway-Instanz, die den zehnten Aufruf erhält, kann dieselben wesentlichen Kompatibilitätsinformationen prüfen wie die Instanz, die den ersten erhielt.

Dieses Modell passt zu einem verwalteten Cloud-Gateway. Zustandslose Dienste können über Worker skalieren, fehlerhafte Kapazität ersetzen und Datenverkehr verteilen, ohne vor der Interpretation jeder Anfrage einen MCP-Sitzungsdatensatz wiederherzustellen.

Es verringert auch eine schwierige Diskrepanz zwischen kurzlebiger Cloud-Infrastruktur und verbindungsorientiertem Protokollverhalten. Serverlose Funktionen und verteilte Gateways funktionieren im Allgemeinen am besten, wenn Anfragen die für eine unabhängige Verarbeitung erforderlichen Informationen enthalten.

Zustandslos bedeutet jedoch nicht, dass die Arbeit des Agents keinen Zustand hat. Ein Beschaffungs-Workflow könnte weiterhin Genehmigungsinformationen, eine Transaktionsreferenz oder Daten erfordern, die während eines früheren Austauschs gesammelt wurden. Die Spezifikation verlagert diesen Zustand in explizite Handles auf Anwendungsebene, statt ihn in der Transportsitzung zu verbergen.

Diese Verschiebung kann die Transparenz verbessern. Tool-Argumente und vom Server ausgegebene Handles schaffen klarere Zuständigkeitsgrenzen als aus einer Verbindung abgeleiteter Zustand. Sie erfordern auch sorgfältiges Design, da Clients Anfragen wiederholen oder alte Handles vorlegen können.

Die neue Revision streicht die Wiederaufnahmefähigkeit von Streamable HTTP über Last-Event-ID und Server-Sent-Event-Kennungen. Wenn ein Antwortstream während einer Anfrage abbricht, muss der Client eine neue Anfrage mit einer neuen Anfrage-ID senden.

Diese Regel wirft eine wichtige operative Frage auf. Führt ein Tool eine Seiteneffekt-Operation aus, bevor der Stream fehlschlägt, könnte eine unbedachte Wiederholung die Aktion erneut ausführen, sofern die Anwendung keine Idempotenz implementiert.

Betrachten wir einen Agent, der ein Support-Ticket erstellt. Der Ticket-Dienst könnte den Datensatz erfolgreich speichern, während der Antwortstream verschwindet. Eine Wiederholung sollte einen Idempotenzschlüssel auf Anwendungsebene enthalten oder die vorherige Operation abfragen, bevor ein weiteres Ticket erstellt wird.

AWS kann nicht jedes nachgelagerte Idempotenzproblem an der Protokollgrenze lösen. Gateway-Logs und Traces können die wiederholten Aufrufe zeigen, doch der Zieldienst muss ein sicheres Wiederholungsverhalten definieren.

Die Revision ersetzt zudem separate serverinitiierte Aufrufe durch Multi Round-Trip Requests. Bei diesem Muster gibt ein Server ein input_required-Ergebnis zurück, das die noch benötigten Informationen beschreibt. Der Client wiederholt die ursprüngliche Anfrage mit den angeforderten Antworten.

Dieser Ansatz hält die Kontrolle innerhalb einer Anfrage- und Wiederholungssequenz. Er vermeidet eine unabhängige Server-zu-Client-Anfrage, die über eine Verbindung eintrifft, die möglicherweise einer anderen Gateway-Instanz gehört.

Alle Ergebnisse enthalten nun einen resultType, üblicherweise complete oder input_required. Clients, die mit älteren Servern kommunizieren, müssen einen fehlenden Wert als abgeschlossenes Ergebnis behandeln und bewahren damit eine begrenzte Kompatibilitätsbrücke.

Der Mechanismus begünstigt eindeutig verteilte Infrastruktur. Der Kompromiss besteht darin, dass SDKs und Anwendungen explizitere Metadaten, Wiederholungslogik und Zustandsverwaltung übernehmen müssen.

Der Druck lastet auf SDKs und gemischten Client-Flotten

AgentCore Gateway kann zwei Protokoll-Ären unterstützen, doch jedes Unternehmen muss nachweisen, dass seine Clients die richtige aushandeln.

Das unmittelbare Druckziel ist keine hinter dem Gateway verborgene API. Es ist die Client-Software, die sich mit dem MCP-Endpunkt verbindet.

Ein Client, der die Revision 2026-07-28 angibt, muss bei jeder Anfrage die Protokollversion und seine Fähigkeiten senden. Er muss server/discover, erforderliche Ergebnistypen und die überarbeitete Behandlung mehrstufiger Interaktionen verstehen.

HTTP-Clients müssen außerdem Standard-MCP-Anfrage-Header verwenden, darunter Mcp-Method und Mcp-Name. Diese Header ermöglichen es Infrastruktur, Observability-Systemen und Sicherheitskontrollen, Datenverkehr zu prüfen und zu routen, ohne jeden JSON-RPC-Body zu parsen.

Diese Änderung ist für Gateways, Observability-Systeme und Sicherheitskontrollen nützlich. Sie schafft jedoch auch einen weiteren Validierungspunkt, an dem unvollständige Clients scheitern können, bevor ein Tool ausgeführt wird.

MCP definiert für diese neue Grenze spezifische Fehler. Header-Abweichungen verwenden den Code -32020, fehlende erforderliche Client-Fähigkeiten -32021 und nicht unterstützte Protokollversionen -32022.

Diese Codes geben Plattformteams eine klarere Fehlerklassifikation. Ein Anstieg von -32022-Antworten weist auf Probleme bei der Versionsaushandlung hin, während -32020 auf eine Abweichung zwischen HTTP-Headern und der enthaltenen Anfrage hindeutet.

Der SDK-Übergang wird nicht in allen Sprachen gleichzeitig erfolgen. Offizielle Implementierungen können eine stabile Spezifikation nach unterschiedlichen Zeitplänen übernehmen, und Anwendungen fixieren Bibliotheksversionen oft lange nach Erscheinen eines neuen Releases.

Unternehmen haben auch Clients, die sie nicht vollständig kontrollieren. Ein Mitarbeiter könnte einen genehmigten Desktop-Assistenten, einen internen Command-Line-Agent und eine von einem anderen Team entwickelte IDE-Erweiterung verwenden. Jeder von ihnen kann MCP anders aushandeln.

Die Liste der unterstützten Versionen von AgentCore bietet für diese gemischte Flotte eine Brücke. Das Gateway kann mehr als eine Revision ankündigen, statt alle Clients sofort auf das neue Wire-Format zu zwingen.

Diese Unterstützung sollte als Migrationsmechanismus betrachtet werden, nicht als Beleg für identisches Verhalten. Funktionen, die aus dem 2026er-Kern entfernt wurden, existieren weiterhin in älteren Protokollabläufen. Ein Test, der nach Aushandlung einer älteren Revision besteht, sagt wenig über den zustandslosen Pfad aus.

Roots, Sampling und Logging sind nun veraltet, statt sofort aus der gesamten Spezifikation entfernt zu werden. Neue Implementierungen sollten sie nicht übernehmen, während bestehende Implementierungen eine definierte Übergangsfrist erhalten.

Die neue Richtlinie für den Funktionslebenszyklus von MCP legt ein Mindestfenster von 12 Monaten für Veraltungen fest. Diese Governance-Änderung verschafft Implementierern besser planbare Vorlaufzeit als informelle Formulierungen zur Veraltung.

Das Protokoll schlägt Alternativen vor. Anwendungen können Verzeichnisse über Tool-Parameter oder Ressourcenkennungen statt über Roots übergeben. Server können APIs von Modellanbietern direkt aufrufen, statt sich auf Sampling zu verlassen. Implementierungen können OpenTelemetry oder Standard-Fehlerströme statt des Protokoll-Loggings verwenden.

Diese Ersetzungen verändern die Architektur, nicht nur die Syntax. Ein Server, der zuvor Modellsampling über seinen MCP-Client angefordert hat, benötigt möglicherweise eine direkte Anbieterintegration, separate Zugangsdaten und eine neue Richtlinie zur Kostenkontrolle.

Der Druck erstreckt sich daher auch auf Sicherheits- und Finanzteams. Wenn Modellzugriff von einer Client-Fähigkeit in den Server verlagert wird, ändern sich sowohl der Speicherort der Zugangsdaten als auch die Stelle, an der die Nutzung sichtbar wird.

Gateway-Verantwortliche sollten Clients in drei Gruppen einteilen. Die erste Gruppe unterstützt die 2026er-Revision vollständig. Die zweite funktioniert nur mit einer vorherigen stabilen Version. Die dritte zeigt unklaren Verhalten und muss isoliert werden, bis die Tests abgeschlossen sind.

Die Tests sollten mehr als tools/list abdecken. Eine nützliche Matrix umfasst Erkennung, authentifizierte Tool-Aufrufe, abgelehnte Berechtigungsbereiche, Antwort-Streaming, unterbrochene Anfragen, Listen-Caching und Anwendungen, die zusätzliche Benutzereingaben erfordern.

Teams sollten außerdem die ausgehandelte Version in der Telemetrie überprüfen. Ohne dieses Signal kann eine erfolgreiche Anfrage ein unerwartetes Downgrade auf das frühere Protokoll verbergen.

Die Migration ist erfolgreich, wenn der neue Pfad repräsentative Produktionslasten trägt. Sie ist nicht allein deshalb erfolgreich, weil das Gateway ein aktualisiertes supportedVersions-Feld akzeptiert.

Die Autorisierung wird strenger, während Erweiterungen den Kern verlassen

MCP 2026-07-28 verringert die Unklarheit bei Zugangsdaten und verschiebt optionale Funktionen zugleich in ein geregeltes, ausgehandeltes Erweiterungssystem.

Die überarbeiteten Autorisierungsregeln konzentrieren sich auf Identitätsgrenzen, die riskant werden, wenn Agenten mit vielen Servern verbunden sind. Ein MCP-Client kann Zugangsdaten von mehreren Autorisierungsservern erhalten, die jeweils unterschiedliche Tools und Daten schützen.

Die Spezifikation besagt nun, dass Clients gespeicherte Zugangsdaten an den Aussteller binden müssen, der sie erstellt hat. Ein Client darf Zugangsdaten nicht mit einem anderen Autorisierungsserver wiederverwenden und muss sich erneut registrieren, wenn sich der Aussteller ändert.

Diese Regel befasst sich mit der Verwechslung von Zugangsdaten. Ähnliche Servernamen, Weiterleitungen oder sich ändernde Metadaten sollten nicht dazu führen, dass Client-Zugangsdaten eines Dienstes an eine andere Autorisierungsgrenze gelangen.

Autorisierungsserver sollten zudem einen iss-Wert in ihre Autorisierungsantworten aufnehmen. Wenn dieses Feld vorhanden ist, müssen Clients es mit dem vor dem Austausch des Autorisierungscodes gespeicherten Aussteller abgleichen.

Diese Validierung folgt RFC 9207, einem Standard der Internet Engineering Task Force, der Mix-up-Angriffe auf Autorisierungsserver verhindern soll. Die Prüfung ist wichtig, wenn ein Client mit mehreren Ausstellern interagiert oder Autorisierungsmetadaten dynamisch ermittelt.

Auch die dynamische Client-Registrierung erhält strengere Vorgaben. MCP-Clients müssen einen geeigneten Anwendungstyp angeben, wodurch Konflikte bei Regeln für Weiterleitungs-URIs für native und Webanwendungen verringert werden.

Diese Anforderungen machen nicht jede Bereitstellung automatisch sicher. SDK-Optionen müssen weiterhin korrekt konfiguriert werden, gespeicherte Zugangsdaten benötigen eine korrekte Zuordnung, und Identitätsanbieter müssen konsistente Informationen zum Aussteller zurückgeben.

AgentCore Gateway bietet einen nützlichen Durchsetzungspunkt, da es eingehende Aufrufer authentifizieren und ausgehende Zugangsdaten getrennt verwalten kann. Laut AWS-Dokumentation unterstützt der Dienst benutzerdefinierte JSON Web Token-Autorisierung, AWS Identity and Access Management sowie andere konfigurierte Autorisierungsmodi.

Diese Trennung ist entscheidend. Die Identität, die ein Gateway aufrufen darf, sollte nicht automatisch uneingeschränkte Zugangsdaten für jedes dahinterliegende Ziel erhalten.

AgentCore kann auch eine Policy Engine mit einem Gateway verknüpfen. Die Engine bewertet Tool-Aufrufe von Agenten und entscheidet anhand konfigurierter Richtlinien, ob jede Aktion erlaubt oder verweigert wird.

Das Gateway-Modell macht das Prinzip der geringsten Rechte nicht überflüssig. Eine weitreichend berechtigte Ziel-Zugangsdaten bleiben weitreichend berechtigt, auch wenn sie in einem verwalteten Identitätsdienst gespeichert sind.

Teams sollten Negativfälle ebenso sorgfältig testen wie erfolgreiche Aufrufe. Ein Client mit unzureichendem Berechtigungsbereich sollte eine kontrollierte Autorisierungsantwort erhalten, nicht einen unzusammenhängenden Protokollfehler oder Zugriff auf ein benachbartes Tool.

Das Erweiterungssystem schafft eine parallele Governance-Änderung. Optionale Funktionen können sich nun außerhalb des Kernprotokolls entwickeln und dabei standardisierte Kennungen, Fähigkeitsdeklarationen und Aushandlung verwenden.

Im Erweiterungsframework verwenden offizielle Kennungen das Präfix io.modelcontextprotocol. Drittanbieter sollten eine umgekehrte Domain verwenden, die ihnen gehört, wodurch Kollisionen zwischen unabhängigen Funktionen verringert werden.

Clients geben unterstützte Erweiterungen innerhalb ihrer Fähigkeiten pro Anfrage an. Server geben ihre über server/discover bekannt. Beide Seiten müssen ausdrücklich zustimmen, und Erweiterungen bleiben standardmäßig deaktiviert.

Zu den offiziellen Erweiterungen gehören asynchrone Tasks, interaktive MCP Apps, OAuth-Client-Zugangsdaten und unternehmensverwaltete Autorisierung. Der Kern muss nicht länger jede spezialisierte Funktion aufnehmen, bevor Implementierer sie nutzen können.

Diese Struktur kann die Komplexität des Kerns begrenzen. Sie schafft jedoch auch eine Support-Matrix, die Plattformteams über Clients, Server, Gateways und SDK-Versionen hinweg verfolgen müssen.

Ein Client, der eine Erweiterung für interaktive Schnittstellen unterstützt, sollte dennoch eine aussagekräftige Textantwort verarbeiten können, wenn der Server sich ordnungsgemäß zurückstufen kann. Ein Server, der eine bestimmte Autorisierungserweiterung benötigt, kann stattdessen einen inkompatiblen Client ablehnen.

Die erste Verpflichtung von AgentCore Gateway ist korrektes Kernprotokollverhalten. Unterstützung für die 2026er-Revision sollte nicht als universelle Unterstützung für jede gegenwärtige oder künftige Erweiterung interpretiert werden.

Das ist eine zentrale Unsicherheit in der Ankündigung von AWS. Das Gateway kann Informationen zu Erweiterungsfähigkeiten transportieren, doch Kunden benötigen ausdrückliche Dokumentation und Tests für jede Erweiterung, von der ihr Workflow abhängt.

Die Autorisierungsänderungen und das Erweiterungsframework teilen ein Prinzip. Verborgene Annahmen werden explizit, unabhängig davon, ob sie Aussteller von Zugangsdaten, Client-Fähigkeiten oder optionales Verhalten betreffen.

Diese Explizitheit ist gut für die Unternehmenssteuerung. Sie bedeutet jedoch auch, dass unvollständige Konfigurationen sichtbarer scheitern werden als bei einer permissiven Integration.

Was Amazon-AWS-Kunden noch nachweisen müssen

Die nächsten drei Signale sind Telemetrie zur ausgehandelten Version, die Qualität von Autorisierungsfehlern und Erweiterungsunterstützung unter realen Lasten.

Das erste Signal ist, ob Produktionsclients tatsächlich MCP 2026-07-28 aushandeln. Die Gateway-Konfiguration allein kann diese Frage nicht beantworten.

Teams sollten nach einem schrittweisen Rollout Anfragemetadaten und protokollbezogene Fehler überwachen. Sie sollten Ergebnisse nach Client-Name, Client-Version, Framework und Bereitstellungskanal vergleichen.

Eine sinkende Rate von Fehlern wegen nicht unterstützter Versionen und Header-Abweichungen würde den Managed-Migrationsfall von AWS stärken. Anhaltende Fehler würden zeigen, dass die Einführung von Client-SDKs und nicht die Verfügbarkeit des Gateways weiterhin den Engpass darstellt.

Downgrades verdienen dieselbe Aufmerksamkeit. Ein Client, der stillschweigend auf eine ältere Revision zurückfällt, kann einen Workflow am Laufen halten und zugleich ein ungelöstes Migrationsproblem verbergen.

Organisationen sollten für jeden getesteten Client die erwartete Revision definieren. Warnmeldungen können dann zwischen einem genehmigten Kompatibilitäts-Fallback und einem unbeabsichtigten Downgrade unterscheiden.

Das zweite Signal ist, wie sich Autorisierungsfehler über mehrere Identitätsanbieter und Ziele hinweg verhalten. Teams müssen Änderungen des Ausstellers, ungültige iss-Werte, abgelaufene Tokens, unzureichende Berechtigungsbereiche und versuchte Wiederverwendung von Zugangsdaten testen.

Das sicherste Ergebnis ist eine präzise Verweigerung, bevor das Ziel ausgeführt wird. Protokolle sollten die beteiligte Richtlinien- oder Autorisierungsgrenze identifizieren, ohne Geheimnisse gegenüber dem Aufrufer offenzulegen.

Saubere Negativtests würden die Behauptung stützen, dass AgentCore individuelle Sicherheitsarbeit reduziert. Verwirrende Fehler oder inkonsistente Verarbeitung von Ausstellern würden sie schwächen, insbesondere bei Gateways, die mehrere Geschäftsbereiche umfassen.

Das dritte Signal ist die Interoperabilität von Erweiterungen. Ein Workflow, der Tasks, MCP Apps oder eine Autorisierungserweiterung nutzt, sollte Fähigkeiten prüfen, bevor er erweiterungsspezifisches Verhalten aufruft.

Tests müssen eine ordnungsgemäße Rückstufung einschließen. Ein Client ohne UI-Unterstützung sollte weiterhin nützliche Kerninhalte erhalten, wenn der Server einen Fallback zusagt.

Auch der umgekehrte Fall ist wichtig. Wenn eine Erweiterung für einen sicheren Betrieb zwingend erforderlich ist, sollte der Server die Anfrage klar ablehnen, statt einen teilweisen Workflow zu versuchen.

Unter diesen drei Prioritäten liegen breitere operative Signale. Teams sollten unterbrochene Aufrufe mit Seiteneffekten auf doppelte Aktionen prüfen, da die neue Revision die Wiederaufnahme von Streams entfernt.

Sie sollten auch das Caching untersuchen. Listen- und Ressourcenergebnisse enthalten nun ttlMs, einen in Millisekunden gemessenen Hinweis zur Aktualität, und cacheScope, das öffentliche von privater Cache-Fähigkeit trennt.

Deterministische Tool-Reihenfolge kann das Caching auf Client-Seite und für Modell-Prompts verbessern. Veraltete Tool-Beschreibungen können jedoch dazu führen, dass ein Agent ein überholtes Schema aufruft; daher muss das Cache-Verhalten bei Zielaktualisierungen getestet werden.

Die Observability sollte verteilten Trace-Kontext einschließen. Die Spezifikation dokumentiert _meta-Konventionen für traceparent, tracestate und baggage, die Teams helfen, Arbeit über Clients, Gateways und Ziele hinweg nachzuverfolgen.

Dieses Tracing wird besonders bei Wiederholungen nützlich. Betreiber müssen den ursprünglich fehlgeschlagenen Stream mit der neu ausgegebenen Anfrage verknüpfen, ohne sie als eine einzige JSON-RPC-Request-ID zu behandeln.

Der größte Wert des verwalteten Gateways zeigt sich, wenn diese Themen zusammenlaufen. Ein Endpunkt kann Aufrufer authentifizieren, Richtlinien anwenden, Protokollverkehr übersetzen, Tools auswählen, Ziel-Zugangsdaten einfügen und Prüfungsnachweise erzeugen.

Auch sein Hauptrisiko zeigt sich dort. Ein Gateway wird zu einem Kontrollpunkt mit großer Hebelwirkung, sodass ein Konfigurationsfehler viele Agenten und Dienste gleichzeitig betreffen kann.

Ein sorgfältiger Rollout sollte mit einem unkritischen Gateway oder einer begrenzten Client-Kohorte beginnen. Teams können die neue unterstützte Version hinzufügen, auf den Bereitschaftsstatus warten und eine versionsspezifische Testsuite ausführen.

Die nächste Phase sollte repräsentative zustandsbehaftete Workflows mit expliziten Handles einführen. Sie sollte eine unterbrochene Anfrage und einen sicher wiederholten Seiteneffekt umfassen.

Danach sollten Autorisierungstests mit erfolgreichen und abgelehnten Aufrufen folgen. Von Erweiterungen abhängige Workflows sollten zuletzt hinzukommen, nachdem das Kernprotokollverhalten stabil ist.

Eine Rollback-Planung bleibt notwendig. Die vorherige stabile Revision in der Liste unterstützter Versionen beizubehalten, gibt kompatiblen Clients einen Fallback, während Teams Fehler untersuchen.

Fallback sollte jedoch nicht zu dauerhafter Unklarheit werden. Organisationen benötigen ein Datum zur Überprüfung verbleibender älterer Clients und einen Plan für veraltete Funktionen, die sie weiterhin nutzen.

Entwickler sollten sich darum kümmern, weil die Revision verändert, wo sie Zustand ablegen und wie sie Wiederholungen durchführen. Plattformteams sollten sich darum kümmern, weil Kompatibilität an der Gateway-Grenze beobachtbar wird.

Unternehmenskäufer sollten sich darum kümmern, weil verwaltete Protokollunterstützung doppelte Infrastruktur reduzieren kann. Sie sollten dennoch fragen, welche Erweiterungen, SDKs, Regionen, Identitätskonfigurationen und Zieltypen die Produktionsvalidierung abgeschlossen haben.

Wissensarbeiter werden die Auswirkungen indirekt spüren. Ihre Assistenten können sich möglicherweise mit mehr Tools verbinden und dabei weniger Verbindungsfehler haben – allerdings nur, wenn Identität und Zustimmung über diese Tools hinweg klar bleiben.

Amazon AWS hat den ersten Migrationsschritt ungewöhnlich klein gehalten. Die wichtigere Frage ist, ob Teams jede Anfrage eigenständig gestalten können, ohne Sicherheit, Kompatibilität oder Transparenz einzubüßen.

Beobachten Sie in den nächsten ein bis drei Monaten Daten zu ausgehandelten Versionen, die Qualität von Autorisierungsablehnungen und die Erweiterungskonformität in den wichtigsten SDKs. Diese Signale werden zeigen, ob zustandsloses MCP zu einem Produktionsstandard geworden ist oder lediglich eine Gateway-Funktion bleibt, die auf ihre Clients wartet.

Für Teams, die AgentCore Gateway bereits einsetzen, ist der nächste praktische Schritt ein kontrolliertes Kompatibilitätsaudit. Aktualisieren Sie ein Gateway, testen Sie jeden unterstützten Client, dokumentieren Sie die ausgehandelte Revision und erzwingen Sie die Fehlerfälle, bevor Sie den Zugriff ausweiten.

Diese Belege sind wichtiger als die scheinbare Einfachheit eines einzelnen API-Aufrufs. Amazon AWS stellt nun die Brücke zu MCP 2026-07-28 bereit, doch jede Organisation muss nachweisen, dass ihre Agenten sie sicher überqueren können.