AWS apprend au registre de serveurs MCP à se mettre à jour tout seul : le schéma des outils sans retouches manuelles

Tous les catalogues internes meurent de la même façon. Au début, il est exact ; puis quelqu'un ajoute une nouvelle fonction au service et oublie de corriger l'entrée ; un mois plus tard, tout le monde va chercher l'information dans le code et dans le chat, parce que plus personne ne fait confiance au catalogue. Il en va de même avec un registre de serveurs MCP, mais les conséquences sont plus fâcheuses : un agent peut appeler un outil selon l'ancien schéma et obtenir un comportement inexplicable, sans erreur explicite.

AWS a publié une analyse de la façon d'éviter cela dans l'Agent Registry, qui fait partie d'Amazon Bedrock AgentCore. L'idée est simple : la mise à jour d'une entrée ne doit pas dépendre de la discipline du développeur. C'est l'événement de déploiement lui-même qui doit la déclencher.

Comment ça fonctionne

La chaîne repose sur cinq services et se présente ainsi.

• Le développeur met à jour le serveur MCP, par exemple avec la commande agentcore deploy. Cela appelle l'API UpdateAgentRuntime, et CloudTrail enregistre l'appel comme un management event.
• EventBridge, via une règle (source aws.bedrock-agentcore, nom d'événement UpdateAgentRuntime), transmet l'événement à un bus central. Dans un schéma multicompte, celui-ci se trouve dans le compte du registre.
• La Lambda extrait de l'événement l'ARN du runtime et en déduit l'URL d'appel du serveur MCP. Elle tire la région et l'ID du compte du même ARN.
• La Lambda obtient un jeton OAuth via AgentCore Identity : d'abord un workload token pour elle-même, puis un jeton M2M auprès du credential provider du compte concerné. Il n'y a aucun secret client dans les variables d'environnement.
• La Lambda appelle initialize, puis tools/list, et obtient la liste à jour des outils.
• Elle recherche ensuite l'entrée du registre dont le schéma contient ce même ARN (ou l'ARN encodé, ou l'URL), et compare les listes.

Où se niche l'ingénierie soignée

La comparaison évite les écritures inutiles. Les outils sont triés par nom et réduits à trois champs : name, description et inputSchema. L'écriture dans le registre n'a lieu que si ces champs diffèrent, et les logs conservent la trace de ce qui a été ajouté ou retiré.

Deux autres détails utiles. Chaque compte dispose de son propre credential provider (variable de la forme CREDENTIAL_PROVIDER_{ACCT_ID}), ce qui permet à une seule Lambda de desservir des serveurs de comptes différents. Et avant la requête, le code vérifie que l'URL commence par https://, ce qui écarte des scénarios désagréables comme file://.

Imaginez une équipe paiements qui ajoute à son serveur MCP un outil refund_status. Auparavant, l'équipe support l'aurait appris par le chat une semaine plus tard. Désormais, 5 à 15 minutes après le déploiement, l'entrée du registre contient déjà le nouvel outil avec un schéma à jour, et les logs de la Lambda montrent ce qui a changé.

Les limites à connaître

Premièrement : le service ne crée pas d'entrées. Dans l'exemple, la Lambda met à jour uniquement les entrées déjà enregistrées, créées lors de l'onboarding et contenant l'ARN du runtime dans mcpServer.data. Les entrées au statut DRAFT sont ignorées ; il faut APPROVED. Cela préserve le processus de validation existant, mais l'enregistrement initial devra être automatisé séparément.

Deuxièmement : la latence. CloudTrail livre les événements en 5 à 15 minutes environ, ce qui ne convient pas au scénario « je déploie et j'appelle aussitôt ». Pour un catalogue consulté par des humains et des agents à la recherche d'outils, ce décalage est généralement tolérable.

Troisièmement : le déclencheur est précisément UpdateAgentRuntime. Si l'ensemble d'outils d'un serveur change dynamiquement sans mise à jour du runtime, aucun événement n'est émis, et il faudra synchroniser les entrées selon un calendrier.

Deux remarques aussi sur le code de l'article. La recherche d'entrée parcourt la liste du registre et effectue une requête get distincte pour chaque élément, et le fragment présenté ne gère pas la pagination. Sur quelques dizaines de serveurs, c'est acceptable ; sur des centaines, il vaut mieux ajouter un index ou stocker séparément la correspondance entre ARN et ID d'entrée. Par ailleurs, une partie du code est tronquée dans l'article d'origine : mieux vaut consulter la version complète dans le dépôt de l'exemple.

Que faire en pratique

Si vous construisez un catalogue interne de serveurs MCP, adoptez le patron dans son intégralité : événement de déploiement, puis interrogation de tools/list, puis diff, puis écriture. Il n'est pas lié à AWS : sur n'importe quel cloud, on peut reconstituer la même chose avec un journal d'audit, un bus d'événements et une fonction. La règle d'or : la source de vérité sur le schéma des outils est le serveur en fonctionnement lui-même, et l'entrée du catalogue n'en est qu'un reflet, qu'on ne doit pas laisser à une mise à jour manuelle.