Amazon AWS prend en charge MCP sans état, mais la compatibilité est désormais le véritable enjeu

Amazon AWS a ajouté la prise en charge de MCP 2026-07-28 à AgentCore Gateway deux jours après que la plus importante révision architecturale de la spécification a atteint sa version stable. Un seul appel UpdateGateway peut activer la nouvelle version du protocole sur une passerelle existante. Toutefois, cette simple modification du plan de contrôle masque une transition plus difficile pour les clients, les serveurs et les équipes de sécurité en entreprise.

La nouvelle révision de Model Context Protocol supprime les sessions au niveau du protocole et impose que chaque requête décrive sa propre version ainsi que les capacités du client. MCP est une norme ouverte qui connecte les applications d’IA à des outils, des sources de données et d’autres services. Sa conception sans état devrait faciliter la mise à l’échelle, le routage et la reprise des passerelles.

Cet avantage s’accompagne d’un test de compatibilité. Les clients doivent adopter de nouvelles métadonnées de requête, les serveurs doivent implémenter la découverte, et les anciennes hypothèses liées aux sessions ne s’appliquent plus. Amazon Bedrock AgentCore Gateway se situe désormais entre ces deux ères du protocole, en convertissant les services d’entreprise en outils MCP tout en appliquant des contrôles d’accès sur un point de terminaison géré.

L’enjeu dépasse donc largement une simple case de version à cocher. Amazon AWS parie qu’une passerelle gérée peut absorber les évolutions du protocole avant qu’elles n’atteignent chaque équipe applicative. La réussite de cette approche dépendra de la négociation des versions, de l’exactitude de l’autorisation et du comportement de flottes de clients hétérogènes.

Amazon AWS transforme une réécriture majeure de MCP en une seule mise à jour de passerelle

AWS a réduit l’étape d’infrastructure à une seule opération d’API, mais les applications doivent toujours communiquer correctement avec le protocole révisé.

Les mainteneurs de MCP ont publié la spécification stable 2026-07-28 le 28 juillet, après une période de release candidate entamée en mai. La version stable de MCP remplace plusieurs hypothèses établies durant les premières phases de croissance du protocole.

AWS a ensuite ajouté cette prise en charge dans Amazon Bedrock AgentCore Gateway. Selon la mise à jour d’AgentCore, les propriétaires de passerelles peuvent ajouter cette nouvelle révision via UpdateGateway. La requête met à jour la configuration du protocole MCP de la passerelle et la liste des versions prises en charge.

L’objet pertinent du plan de contrôle est protocolConfiguration.mcp.supportedVersions. AWS documente ce champ comme un tableau des versions MCP que la passerelle peut utiliser. UpdateGateway renvoie le statut HTTP 202 lorsque le service accepte une mise à jour, puis la passerelle passe par un état de mise à jour.

Cette distinction est importante sur le plan opérationnel. L’acceptation d’un appel ne signifie pas que chaque client connecté a mené une requête à bien. Les équipes doivent attendre que la passerelle retrouve son état prêt, puis exécuter des tests de conformité et de charge sur le point de terminaison réel.

Ce changement n’oblige pas les organisations à reconstruire chaque fonction Lambda, service OpenAPI ou service Smithy derrière leur passerelle. AgentCore Gateway convertit déjà ces ressources en outils compatibles MCP. Il prend également en charge les cibles MCP distantes et d’autres services HTTP, selon la configuration de la cible.

Cette architecture permet à AWS de modifier la couche exposée au protocole sans exiger de changements identiques dans chaque service métier en aval. Une API de support client peut, par exemple, rester une API, tandis que la passerelle expose ses opérations comme des outils à des agents compatibles.

AgentCore Gateway gère également l’authentification entrante, les identifiants sortants, la découverte des outils, le routage et l’application des politiques. Ces contrôles gagnent en valeur lorsqu’un même point de terminaison dessert des services détenus par plusieurs équipes internes.

Pourtant, l’appel UpdateGateway ne modifie que la prise en charge déclarée par la passerelle. Un client utilisant la révision 2026 doit toujours envoyer les métadonnées et en-têtes requis. Un client plus ancien doit négocier une révision mutuellement prise en charge ou emprunter un chemin de repli compatible.

C’est la première contrainte derrière le message de mise à niveau simplifiée d’AWS. Le service géré peut réduire le travail de plateforme, mais il ne peut pas faire en sorte qu’un SDK obsolète émette un nouveau format sur le réseau.

La deuxième contrainte concerne les tests. Les propriétaires de passerelles doivent vérifier la liste des outils, les appels d’outils, les échecs d’authentification, le comportement du streaming et les contrôles de cache pour chaque version prise en charge. La réussite avec un client moderne ne prouve pas la compatibilité de l’ensemble d’une flotte d’entreprise.

Un déploiement pragmatique commence donc par un inventaire. Les équipes doivent identifier quelles applications d’agents se connectent à la passerelle, quelles versions de SDK elles utilisent et si ces SDK prennent en charge MCP 2026-07-28.

Les organisations qui consignent les décisions techniques et les preuves de test dans une base de connaissances d’ingénierie interrogeable peuvent enregistrer les résultats par client et par version de protocole. Ce registre devient important lorsqu’un échec ne survient que dans un seul framework ou canal de déploiement.

AWS a réduit l’action du plan de contrôle. La vérification au niveau des applications reste le véritable projet de migration.

Pourquoi MCP sans état change la donne pour les passerelles

MCP sans état place les informations de compatibilité dans chaque requête, simplifiant le routage horizontal tout en imposant à chaque message de se suffire à lui-même.

Les révisions antérieures de MCP utilisaient un échange d’initialisation pour établir les détails et les capacités du protocole. Un client envoyait initialize, le serveur répondait, puis le client achevait la séquence avec notifications/initialized. Streamable HTTP pouvait également utiliser un en-tête Mcp-Session-Id pour associer le trafic ultérieur à une session au niveau du protocole.

Les principaux changements de MCP suppriment ce cycle de vie dans la nouvelle révision. Ils suppriment également l’identifiant de session au niveau du protocole. Les serveurs qui ont besoin de conserver un état entre les appels doivent émettre des handles explicites que les clients transmettent comme arguments ordinaires d’outils.

Chaque requête de nouveau style porte sa version de protocole et les capacités du client dans _meta. Les clients doivent également s’y identifier. Les serveurs renvoient leur identité dans les métadonnées de résultat, rendant chaque échange plus auto-descriptif.

Une nouvelle méthode server/discover permet à un client d’inspecter les versions prises en charge, les capacités et l’identité du serveur avant toute autre opération. Un serveur utilisant la révision 2026-07-28 doit implémenter cet appel de procédure distante.

Cette conception modifie ce qu’une passerelle doit mémoriser. Elle n’a plus besoin de dépendre d’un échange d’initialisation achevé via une seule connexion ni d’associer le trafic ultérieur du protocole à une session MCP opaque.

Un répartiteur de charge peut router des requêtes distinctes sans préserver d’affinité au niveau du protocole. Une instance de passerelle qui reçoit le dixième appel peut inspecter les mêmes informations essentielles de compatibilité que celles reçues par la première instance.

Ce modèle convient à une passerelle cloud gérée. Les services sans état peuvent évoluer sur plusieurs workers, remplacer les capacités défaillantes et distribuer le trafic sans restaurer un enregistrement de session MCP avant d’interpréter chaque requête.

Il réduit également un décalage délicat entre une infrastructure cloud éphémère et un comportement de protocole orienté connexion. Les fonctions serverless et les passerelles distribuées fonctionnent généralement mieux lorsque les requêtes contiennent les informations nécessaires à un traitement indépendant.

Toutefois, sans état ne signifie pas que le travail de l’agent est dépourvu d’état. Un flux d’achat peut toujours nécessiter des informations d’approbation, une référence de transaction ou des données recueillies lors d’un échange antérieur. La spécification déplace cet état vers des handles explicites au niveau applicatif au lieu de le masquer dans la session de transport.

Ce changement peut améliorer la visibilité. Les arguments d’outils et les handles émis par le serveur établissent des limites de responsabilité plus claires qu’un état déduit d’une connexion. Ils exigent également une conception rigoureuse, car les clients peuvent réessayer des requêtes ou présenter d’anciens handles.

La nouvelle révision abandonne la reprise de Streamable HTTP via Last-Event-ID et les identifiants d’événements envoyés par le serveur. Si un flux de réponse se rompt au cours d’une requête, le client doit envoyer une nouvelle requête avec un nouvel identifiant de requête.

Cette règle soulève une question opérationnelle importante. Si un outil produit un effet de bord avant l’échec du flux, une nouvelle tentative aveugle pourrait répéter l’action, à moins que l’application n’implémente l’idempotence.

Prenons l’exemple d’un agent qui crée un ticket de support. Le service de tickets peut enregistrer correctement le ticket alors que le flux de réponse disparaît. Une nouvelle tentative devrait comporter une clé d’idempotence au niveau applicatif ou vérifier l’opération précédente avant de créer un autre ticket.

AWS ne peut pas résoudre tous les problèmes d’idempotence en aval à la frontière du protocole. Les journaux et traces de la passerelle peuvent montrer les appels répétés, mais le service cible doit définir un comportement de réessai sûr.

La révision remplace aussi les appels distincts initiés par le serveur par des requêtes Multi Round-Trip. Dans ce modèle, un serveur renvoie un résultat input_required décrivant les informations dont il a encore besoin. Le client réessaie la requête d’origine avec les réponses demandées.

Cette approche maintient le contrôle au sein d’une séquence de requête et de nouvelle tentative. Elle évite qu’une requête indépendante du serveur vers le client arrive via une connexion qu’une autre instance de passerelle pourrait ne pas posséder.

Tous les résultats incluent désormais un resultType, généralement complete ou input_required. Les clients qui communiquent avec des serveurs plus anciens doivent traiter une valeur absente comme un résultat terminé, préservant ainsi un pont de compatibilité limité.

Le mécanisme favorise clairement les infrastructures distribuées. En contrepartie, les SDK et les applications doivent adopter des métadonnées, une logique de réessai et une gestion de l’état plus explicites.

La pression se porte sur les SDK et les flottes de clients mixtes

AgentCore Gateway peut prendre en charge deux ères du protocole, mais chaque organisation doit prouver que ses clients négocient la bonne version.

La cible immédiate de cette pression n’est pas une API cachée derrière la passerelle. C’est le logiciel client qui se connecte au point de terminaison MCP.

Un client déclarant la révision 2026-07-28 doit envoyer la version du protocole et ses capacités à chaque requête. Il doit comprendre server/discover, les types de résultats requis et la gestion révisée des interactions en plusieurs étapes.

Les clients HTTP doivent également utiliser les en-têtes de requête MCP standard, notamment Mcp-Method et Mcp-Name. Ces en-têtes permettent à l’infrastructure d’inspecter et de router le trafic sans analyser chaque corps JSON-RPC.

Ce changement est utile pour les passerelles, les systèmes d’observabilité et les contrôles de sécurité. Il crée également un nouveau point de validation où des clients incomplets peuvent échouer avant qu’un outil ne s’exécute.

MCP définit des erreurs spécifiques pour cette nouvelle frontière. Les incohérences d’en-têtes utilisent le code -32020, l’absence de capacités client requises utilise -32021, et les versions de protocole non prises en charge utilisent -32022.

Ces codes donnent aux équipes de plateforme une taxonomie des échecs plus claire. Une hausse des réponses -32022 indique un problème de négociation de version, tandis que -32020 signale une divergence entre les en-têtes HTTP et la requête incluse.

La transition des SDK ne se produira pas simultanément dans tous les langages. Les implémentations officielles peuvent adopter une spécification stable selon des calendriers différents, et les applications figent souvent leurs versions de bibliothèques bien après l’apparition d’une nouvelle version.

Les entreprises disposent également de clients qu’elles ne contrôlent pas entièrement. Un employé peut utiliser un assistant de bureau approuvé, un agent interne en ligne de commande et une extension d’IDE développée par une autre équipe. Chacun peut négocier MCP différemment.

La liste des versions prises en charge par AgentCore offre un pont à cette flotte hétérogène. La passerelle peut annoncer plusieurs révisions au lieu de forcer tous les clients à adopter immédiatement le nouveau format sur le réseau.

Ce support doit être considéré comme un mécanisme de migration, et non comme la preuve d’un comportement identique. Les fonctionnalités retirées du cœur 2026 existent toujours dans les anciens flux de protocole. Un test réussi après négociation d’une révision plus ancienne ne dit pas grand-chose du chemin sans état.

Roots, Sampling et Logging sont désormais dépréciés plutôt que immédiatement supprimés de l’ensemble de la spécification. Les nouvelles implémentations devraient éviter de les adopter, tandis que les implémentations existantes bénéficient d’une période de transition définie.

La nouvelle politique de cycle de vie des fonctionnalités de MCP établit une période minimale de dépréciation de 12 mois. Ce changement de gouvernance donne aux implémenteurs un préavis plus prévisible que des formulations informelles de dépréciation.

Le protocole propose des alternatives. Les applications peuvent transmettre des répertoires via des paramètres d’outils ou des identifiants de ressources au lieu de Roots. Les serveurs peuvent appeler directement les API des fournisseurs de modèles au lieu de s’appuyer sur Sampling. Les implémentations peuvent utiliser OpenTelemetry ou les flux d’erreur standard au lieu du protocole Logging.

Ces substitutions modifient l’architecture, et pas seulement la syntaxe. Un serveur qui demandait auparavant l’échantillonnage de modèle via son client MCP peut avoir besoin d’une intégration directe avec un fournisseur, d’identifiants distincts et d’une nouvelle politique de contrôle des coûts.

La pression s’étend donc aux équipes de sécurité et de finance. Déplacer l’accès au modèle d’une capacité client vers le serveur change l’emplacement des identifiants et celui où l’usage apparaît.

Les responsables de passerelles devraient classer les clients en trois groupes. Le premier prend pleinement en charge la révision 2026. Le deuxième ne fonctionne qu’avec une version stable antérieure. Le troisième présente un comportement incertain et doit être isolé jusqu’à la fin des tests.

Les tests devraient couvrir plus que tools/list. Une matrice utile inclut la découverte, les appels d’outils authentifiés, les portées refusées, le streaming des réponses, les requêtes interrompues, la mise en cache des listes et les applications nécessitant des informations supplémentaires de l’utilisateur.

Les équipes devraient également vérifier la version négociée dans la télémétrie. Sans ce signal, une requête réussie pourrait masquer une rétrogradation inattendue vers le protocole antérieur.

La migration réussit lorsque le nouveau chemin prend en charge des charges de production représentatives. Elle ne réussit pas simplement parce que la passerelle accepte un champ supportedVersions mis à jour.

L’autorisation se renforce à mesure que les extensions quittent le cœur

MCP 2026-07-28 réduit l’ambiguïté des identifiants tout en déplaçant les capacités optionnelles vers un système d’extensions gouverné et négocié.

Les règles d’autorisation révisées se concentrent sur les frontières d’identité qui deviennent risquées lorsque les agents se connectent à de nombreux serveurs. Un client MCP peut obtenir des identifiants auprès de plusieurs serveurs d’autorisation, chacun protégeant différents outils et données.

La spécification indique désormais que les clients doivent lier les identifiants stockés à l’émetteur qui les a créés. Un client ne doit pas réutiliser des identifiants auprès d’un autre serveur d’autorisation, et il doit s’enregistrer à nouveau lorsque l’émetteur change.

Cette règle traite la confusion d’identifiants. Des noms de serveurs similaires, des redirections ou des métadonnées changeantes ne devraient pas amener les identifiants client d’un service à franchir une autre frontière d’autorisation.

Les serveurs d’autorisation devraient également inclure une valeur iss dans leurs réponses d’autorisation. Lorsque ce champ est présent, les clients doivent le valider par rapport à l’émetteur enregistré avant d’échanger le code d’autorisation.

Cette validation suit la RFC 9207, une norme de l’Internet Engineering Task Force conçue pour empêcher les attaques de confusion de serveurs d’autorisation. Cette vérification est importante lorsqu’un client interagit avec plusieurs émetteurs ou découvre dynamiquement les métadonnées d’autorisation.

L’enregistrement dynamique des clients reçoit également des recommandations plus strictes. Les clients MCP doivent spécifier un type d’application approprié, réduisant les conflits autour des règles d’URI de redirection pour les applications natives et web.

Ces exigences ne rendent pas automatiquement chaque déploiement sécurisé. Les options des SDK doivent toujours être correctement configurées, les enregistrements d’identifiants stockés exigent un indexage approprié, et les fournisseurs d’identité doivent renvoyer des informations d’émetteur cohérentes.

AgentCore Gateway fournit un point d’application utile, car il peut authentifier les appelants entrants et gérer séparément les identifiants sortants. La documentation AWS indique que le service prend en charge l’autorisation personnalisée par JSON Web Token, AWS Identity and Access Management et d’autres modes d’autorisation configurés.

Cette séparation est essentielle. L’identité autorisée à appeler une passerelle ne devrait pas recevoir automatiquement des identifiants sans restriction pour chaque cible située derrière elle.

AgentCore peut également associer un moteur de politiques à une passerelle. Ce moteur évalue les appels d’outils des agents et décide si chaque action est autorisée ou refusée selon les politiques configurées.

Le modèle de passerelle n’élimine pas le besoin de moindre privilège. Un identifiant cible doté de portées étendues reste doté de portées étendues, même s’il est stocké dans un service d’identité géré.

Les équipes devraient tester les cas négatifs avec autant de soin que les appels réussis. Un client doté d’une portée insuffisante devrait recevoir une réponse d’autorisation contrôlée, et non une erreur de protocole sans rapport ou un accès à un outil voisin.

Le système d’extensions crée un changement de gouvernance parallèle. Les fonctionnalités optionnelles peuvent désormais évoluer hors du protocole central tout en utilisant des identifiants standardisés, des déclarations de capacités et la négociation.

Dans le cadre des extensions, les identifiants officiels utilisent le préfixe io.modelcontextprotocol. Les tiers devraient utiliser un domaine inversé qui leur appartient, ce qui réduit les collisions entre fonctionnalités sans lien.

Les clients annoncent les extensions prises en charge dans leurs capacités par requête. Les serveurs annoncent les leurs via server/discover. Les deux côtés doivent explicitement y adhérer, et les extensions restent désactivées par défaut.

Les extensions officielles incluent les Tasks asynchrones, les MCP Apps interactives, les identifiants client OAuth et l’autorisation gérée par l’entreprise. Le cœur n’a plus besoin d’absorber chaque fonctionnalité spécialisée avant que les implémenteurs puissent l’utiliser.

Cette structure peut limiter la complexité du cœur. Elle crée aussi une matrice de support que les équipes de plateforme doivent suivre entre clients, serveurs, passerelles et versions de SDK.

Un client prenant en charge une extension d’interface interactive devrait tout de même gérer une réponse textuelle utile lorsque le serveur peut se dégrader proprement. Un serveur exigeant une extension d’autorisation particulière peut plutôt refuser un client incompatible.

La première obligation d’AgentCore Gateway est de garantir un comportement correct du protocole central. La prise en charge de la révision 2026 ne doit pas être interprétée comme une prise en charge universelle de toute extension présente ou future.

C’est une incertitude majeure dans l’annonce d’AWS. La passerelle peut transporter des informations de capacité d’extension, mais les clients ont besoin d’une documentation explicite et de tests pour toute extension dont dépend leur flux de travail.

Les changements d’autorisation et le cadre d’extensions partagent un même principe. Les hypothèses implicites deviennent explicites, qu’elles concernent les émetteurs d’identifiants, les capacités des clients ou les comportements optionnels.

Cette explicitation est bénéfique pour le contrôle en entreprise. Elle signifie aussi qu’une configuration incomplète échouera de manière plus visible que dans le cadre d’une intégration permissive.

Ce que les clients Amazon AWS doivent encore démontrer

Les trois prochains signaux sont la télémétrie de version négociée, la qualité des échecs d’autorisation et la prise en charge des extensions sous des charges réelles.

Le premier signal est de savoir si les clients de production négocient effectivement MCP 2026-07-28. La configuration de la passerelle seule ne peut pas répondre à cette question.

Les équipes devraient surveiller les métadonnées de requêtes et les erreurs liées au protocole après un déploiement progressif. Elles devraient comparer les résultats selon le nom du client, sa version, le framework et le canal de déploiement.

Une baisse du taux d’erreurs de version non prise en charge et d’incompatibilité d’en-têtes renforcerait l’argument d’AWS en faveur d’une migration gérée. Des erreurs persistantes montreraient que l’adoption des SDK clients, et non la disponibilité de la passerelle, reste le goulot d’étranglement.

Les rétrogradations méritent autant d’attention. Un client qui revient silencieusement à une révision plus ancienne peut maintenir un flux de travail en fonctionnement tout en masquant un problème de migration non résolu.

Les organisations devraient définir la révision attendue pour chaque client testé. Les alertes peuvent alors distinguer un repli de compatibilité approuvé d’une rétrogradation involontaire.

Le deuxième signal concerne le comportement des échecs d’autorisation entre plusieurs fournisseurs d’identité et cibles. Les équipes doivent tester les changements d’émetteur, les valeurs iss invalides, les jetons expirés, les portées insuffisantes et les tentatives de réutilisation d’identifiants.

Le résultat le plus sûr est un refus précis avant l’exécution de la cible. Les journaux devraient identifier la politique ou la frontière d’autorisation concernée sans exposer de secrets à l’appelant.

Des tests négatifs propres étayeraient l’affirmation selon laquelle AgentCore réduit le travail de sécurité personnalisé. Des échecs confus ou une gestion incohérente des émetteurs l’affaibliraient, surtout pour les passerelles couvrant plusieurs unités opérationnelles.

Le troisième signal est l’interopérabilité des extensions. Un flux de travail utilisant Tasks, MCP Apps ou une extension d’autorisation devrait vérifier les capacités avant d’invoquer un comportement spécifique à l’extension.

Les tests doivent inclure une dégradation élégante. Un client sans prise en charge d’interface utilisateur devrait tout de même recevoir un contenu central utile lorsque le serveur promet une solution de repli.

Le cas inverse est tout aussi important. Si une extension est obligatoire pour une opération sûre, le serveur devrait rejeter clairement la requête au lieu de tenter un flux de travail partiel.

D’autres signaux opérationnels plus larges sous-tendent ces trois priorités. Les équipes devraient surveiller les appels interrompus ayant des effets de bord pour détecter les actions dupliquées, car la nouvelle révision supprime la reprise de flux.

Elles devraient aussi examiner la mise en cache. Les résultats de listes et de ressources incluent désormais ttlMs, un indicateur de fraîcheur mesuré en millisecondes, et cacheScope, qui distingue la possibilité de mise en cache publique de la mise en cache privée.

L’ordre déterministe des outils peut améliorer la mise en cache côté client et celle des prompts de modèles. Toutefois, des descriptions d’outils obsolètes peuvent conduire un agent à appeler un schéma dépassé ; le comportement du cache doit donc être testé lors des mises à jour des cibles.

L’observabilité devrait inclure le contexte de traçage distribué. La spécification documente les conventions _meta pour traceparent, tracestate et baggage, aidant les équipes à suivre le travail entre clients, passerelles et cibles.

Ce traçage devient particulièrement utile lors des tentatives. Les opérateurs doivent relier le flux initial en échec à la requête nouvellement émise sans les traiter comme un seul identifiant de requête JSON-RPC.

La valeur la plus forte de la passerelle gérée apparaît lorsque ces préoccupations convergent. Un seul point de terminaison peut authentifier les appelants, appliquer des politiques, traduire le trafic de protocole, sélectionner des outils, injecter des identifiants cibles et produire des éléments de preuve d’audit.

Son principal risque apparaît également à cet endroit. Une passerelle devient un point de contrôle à fort effet de levier ; une erreur de configuration peut donc affecter simultanément de nombreux agents et services.

Un déploiement prudent devrait commencer par une passerelle non critique ou une cohorte limitée de clients. Les équipes peuvent ajouter la nouvelle version prise en charge, attendre l’état prêt et exécuter une suite de tests spécifique à cette version.

L’étape suivante devrait introduire des flux de travail avec état représentatifs utilisant des handles explicites. Elle devrait inclure une requête interrompue et un effet de bord relancé en toute sécurité.

Les tests d’autorisation devraient suivre avec des appels réussis comme refusés. Les flux de travail dépendants d’extensions devraient être introduits en dernier, une fois le comportement du protocole central stabilisé.

La planification du retour arrière reste nécessaire. Conserver la précédente révision stable dans la liste des versions prises en charge offre une solution de repli aux clients compatibles pendant que les équipes enquêtent sur les défauts.

Cependant, le repli ne devrait pas devenir une ambiguïté permanente. Les organisations doivent fixer une date pour examiner les clients plus anciens restants et établir un plan pour les fonctionnalités dépréciées qu’elles utilisent encore.

Les développeurs devraient s’en préoccuper, car cette révision modifie l’endroit où ils placent l’état et la manière dont ils effectuent les nouvelles tentatives. Les équipes de plateforme devraient s’en préoccuper, car la compatibilité devient observable à la frontière de la passerelle.

Les acheteurs d’entreprise devraient s’en préoccuper, car la prise en charge gérée du protocole peut réduire les infrastructures dupliquées. Ils devraient néanmoins demander quelles extensions, quels SDK, quelles régions, quelles configurations d’identité et quels types de cibles ont achevé une validation en production.

Les travailleurs du savoir en ressentiront les effets indirectement. Leurs assistants pourront se connecter à davantage d’outils avec moins d’échecs de connexion, mais seulement si l’identité et le consentement restent clairs d’un outil à l’autre.

Amazon AWS a rendu la première étape de migration inhabituellement légère. La question la plus importante est de savoir si les équipes peuvent rendre chaque requête autonome sans sacrifier la sécurité, la compatibilité ou la visibilité.

Au cours des un à trois prochains mois, surveillez les données de version négociée, la qualité des refus d’autorisation et la conformité des extensions dans les principaux SDK. Ces signaux indiqueront si MCP sans état est devenu une norme de production ou s’il reste une fonctionnalité de passerelle en attente de ses clients.

Pour les équipes qui utilisent déjà AgentCore Gateway, la prochaine action concrète consiste à mener un audit de compatibilité contrôlé. Mettez à jour une passerelle, testez chaque client pris en charge, consignez la révision négociée et provoquez les cas d’échec avant d’élargir l’accès.

Ces éléments comptent davantage que la simplicité apparente d’un appel d’API. Amazon AWS fournit désormais le pont vers MCP 2026-07-28, mais chaque organisation doit démontrer que ses agents peuvent le franchir en toute sécurité.