La conception à deux plans de la passerelle MCP détermine à la fois sa capacité à monter en charge et la manière dont les équipes l’utilisent. Le plan de contrôle (MCP Registry) héberge le catalogue de référence des serveurs MCP virtuels et les manifestes d’outils ; le plan de données (Proxy Gateway) exécute les requêtes et conserve en mémoire une représentation des serveurs activés. Cette séparation permet de déployer instantanément les changements de configuration sans redéploiement et d’automatiser la découverte, tout en laissant aux humains la responsabilité de l’application des règles et de la gestion. Pour les équipes d’exploitation, elle réduit la maintenance en regroupant l’infrastructure MCP répétitive dans un service géré unique, connecté au maillage de services existant.

AutoCrawler est le moteur de découverte qui évite de devoir rédiger manuellement un nombre exponentiel de définitions. Il analyse en continu les registres IDL et les signaux de présence des serveurs MCP natifs, interprète les fichiers protobuf/Thrift, génère des schémas compatibles JSON-RPC et crée des entrées de serveurs MCP virtuels désactivées par défaut. Point important, AutoCrawler enrichit les descriptions des outils à l’aide de résumés générés par des LLM et évite de mobiliser les équipes : les responsables des services vérifient et activent les éléments lorsqu’ils sont prêts. Concrètement, les entreprises peuvent ainsi constituer rapidement des catalogues d’outils pour leurs agents, tout en conservant les étapes de validation et les contrôles de responsabilité.

Centraliser l’autorisation et le masquage dans la passerelle simplifie la gestion des risques. Uber applique des politiques de charte au niveau des serveurs, avec la possibilité de définir des exceptions pour chaque outil. Le système interne de contrôle des accès évalue les acteurs à l’origine des appels (personnes, services ou agents), et les données renvoyées font l’objet d’un masquage des informations personnelles. Pour les intégrations tierces, la passerelle relaie les jetons des utilisateurs, que le service externe échange, ce qui préserve la traçabilité. Cette approche réduit les écarts de niveau de sécurité entre les équipes et garantit des pistes d’audit cohérentes, tout en rapprochant l’application des règles de l’exécution.

Les ajouts opérationnels d’Uber répondent aux difficultés liées à la découverte et au contexte des modèles. Omni MCP fournit des primitives de découverte (discover_server, discover_tools, get_tool_schema, invoke_tool) afin que les agents puissent découvrir et appeler les outils progressivement. Response Projection permet aux invites des LLM de spécifier uniquement les champs nécessaires, puis la passerelle réduit les réponses en conséquence, ce qui diminue la consommation de jetons. Code Mode, accessible par la CLI aifx, permet aux agents de programmation d’enchaîner des commandes de liste, de recherche et d’appel, puis d’écrire les résultats sur disque ; les agents qui exploitent ensuite le système de fichiers ne chargent que les données nécessaires. Ces pratiques sont des leviers concrets pour maîtriser les coûts et améliorer la fiabilité des chaînes d’agents en production.

Une approche privilégiant la passerelle réduit les efforts redondants, mais concentre les risques opérationnels : une mauvaise configuration ou un bogue de la passerelle peut affecter de nombreux outils. Il est donc essentiel de définir clairement les responsabilités : la découverte peut être automatisée, mais l’activation doit rester du ressort des équipes de service. Parmi les autres limites figurent la dérive des schémas pour les services fondés sur des IDL, les cas particuliers de traduction des protocoles et les coûts résiduels dus aux écarts de projection. Les entreprises devraient associer la passerelle à une intégration continue robuste, à des workflows d’approbation, à des déploiements progressifs et à une bonne observabilité afin de limiter les défaillances systémiques.