Introduction
L'adoption rapide des agents IA chez Uber a fondamentalement transformé la façon dont les équipes interagissent avec le code, les données et les systèmes opérationnels. Les premières intégrations ponctuelles avec le MCP (Model Context Protocol) ont rapidement démontré leur valeur : les agents sont devenus nettement plus performants dès lors qu'ils ont pu accéder au contexte métier en temps réel, interroger les services internes et exécuter des actions concrètes pour le compte des utilisateurs. Ces premiers succès ont confirmé que le MCP constituait une abstraction puissante pour concevoir des systèmes agentiques au sein d'Uber.
Cependant, à mesure que l'adoption s'accélérait, des défis majeurs ont émergé. Chaque équipe développait ses propres intégrations de manière isolée, ce qui a entraîné une fragmentation des outils et une duplication de l'infrastructure. Les outils MCP étaient difficiles à découvrir, complexes à exploiter de manière fiable et étroitement couplés à des services ou à des implémentations d'agents spécifiques. Si ces approches fonctionnaient à petite échelle, elles ne répondaient plus aux besoins d'Uber lorsque des centaines d'équipes ont commencé à explorer les workflows agentiques. Sans architecture unifiée, le passage à l'échelle du MCP aurait accru la complexité opérationnelle, les risques de sécurité et les frictions pour les développeurs, limitant ainsi son impact.
Pour libérer tout le potentiel du MCP à l'échelle d'Uber, il nous fallait une solution centralisée et évolutive, capable de standardiser les interactions entre les agents IA et les systèmes back-end existants, tout en préservant la flexibilité des équipes. Cette solution devait abstraire les différences de protocoles (HTTP, gRPC™, TChannel), garantir une sécurité et une observabilité cohérentes, et faciliter la création, la découverte et la réutilisation des outils MCP dans toute l'entreprise.
C'est pour répondre à ce besoin que nous avons conçu la MCP Gateway. Il s'agit d'un microservice fondamental qui orchestre toutes les interactions MCP chez Uber, en servant de couche de routage et d'orchestration entre les agents IA, les services back-end existants et les serveurs MCP natifs. En centralisant la logique MCP au sein d'une passerelle unique, nous offrons un modèle d'exécution homogène pour les interactions agent-service, tout en évitant aux équipes de devoir réinventer l'infrastructure de base. Les API existantes peuvent être exposées sans effort sous forme d'outils MCP, gouvernées et exploitées depuis un point unique, puis consommées par plusieurs agents de manière uniforme. La MCP Gateway a ouvert la voie à un développement d'agents IA évolutif, rapide et cohérent au sein d'Uber, et héberge aujourd'hui plus de 800 serveurs MCP et plus de 5 000 outils.
Figure 1 : MCP Gateway (les API en tant qu'outils).
Dans cet article, nous passons en revue la conception de la MCP Gateway, en abordant la couche Proxy (traduction du MCP vers les protocoles existants et inversement), la couche Discovery (registre MCP et exploration des API) ainsi que son plan de contrôle (création et configuration).
La passerelle
La MCP Gateway repose sur une architecture de microservices, où la passerelle agit comme le point d'intégration central entre les systèmes dotés d'IA et les services back-end d'Uber. La plateforme se compose de deux éléments principaux : le registre MCP (MCP Registry), qui fait office de plan de contrôle, et la passerelle proxy (Proxy Gateway), qui constitue le plan de données.
Le registre MCP maintient un catalogue de centaines de serveurs MCP adossés à des services internes, ainsi que de milliers d'outils MCP. Ces outils vont de définitions no-code, qui exposent des API existantes sous forme d'outils MCP, à des implémentations entièrement natives conçues spécifiquement selon la spécification MCP. Ce registre représente la source de vérité unique pour la découverte, la propriété et l'activation des outils à travers tout l'écosystème.
La passerelle proxy est chargée d'exécuter les requêtes MCP au moment de l'exécution (runtime). Elle traduit les appels du protocole MCP en requêtes HTTP, gRPC ou TChannel, les transmet au service back-end approprié, puis convertit les réponses en résultats compatibles MCP. Cette couche de traduction permet aux agents IA d'interagir avec les systèmes existants via une interface MCP cohérente, sans nécessiter la moindre modification des services sous-jacents.
Plan de contrôle
Uber utilise une architecture de microservices et exploite des milliers de services internes qui exposent des API via HTTP, gRPC et TChannel. Ces API fournissent un contexte précieux à un système d'IA, mais demander aux équipes de créer manuellement un serveur MCP serait lent et fastidieux. Pour résoudre ce problème, nous avons développé AutoCrawler, un outil qui analyse en continu le registre IDL d'Uber à la recherche d'API, les traduit et les met à jour dans le registre. Il interroge également les serveurs MCP natifs pour les y ajouter.
AutoCrawler : le moteur de découverte
AutoCrawler est un système de workflow distribué propulsé par Cadence, abonné au registre IDL d'Uber et aux signaux des services internes. Selon une planification fixe, une tâche cron déclenche un workflow Cadence qui détecte les nouveaux services, les API et les modifications de schémas.
Pour chaque entité découverte, AutoCrawler se charge de :
- Créer ou mettre à jour les représentations des serveurs MCP
- Générer ou récupérer les définitions et les schémas des outils
- Enregistrer les outils dans le registre MCP, désactivés par défaut
Cette base commune permet à la découverte MCP de passer à l'échelle sur des milliers de services, sans que les équipes responsables de ces derniers ne deviennent un goulot d'étranglement.
Figure 2 : AutoCrawler.
Découverte pour les services basés sur des IDL
Pour les services back-end traditionnels définis via des IDL Protobuf ou Thrift, AutoCrawler génère les serveurs et les outils MCP directement à partir du registre IDL. Pour chaque groupe d'API de service, AutoCrawler exécute les étapes suivantes :
- Création ou mise à jour du serveur MCP : crée ou met à jour un serveur MCP virtuel correspondant au service découvert.
- Analyse des définitions IDL : analyse les fichiers protobuf ou Thrift associés pour extraire les noms de méthodes, les schémas de requête et de réponse, ainsi que les commentaires de documentation.
- Génération des descriptions d'outils : utilise un LLM pour générer des descriptions d'outils MCP enrichies et adaptées aux agents, à partir des schémas et commentaires extraits.
- Traduction des schémas : convertit les schémas protobuf ou Thrift en schémas JSON-RPC 2.0 compatibles MCP.
- Création ou mise à jour des outils MCP : enregistre ou met à jour les outils MCP générés dans le registre MCP, désactivés par défaut.
Découverte pour les serveurs natifs
Outre les services basés sur des IDL, la MCP Gateway prend également en charge les serveurs MCP natifs, c'est-à-dire les services qui implémentent directement le protocole MCP et exposent des outils optimisés pour les agents.
MCPFx est le framework utilisé par Uber pour créer des serveurs MCP natifs. Chacun de ces serveurs émet une métrique de heartbeat signalant sa présence et sa disponibilité. AutoCrawler surveille en continu ces signaux pour découvrir automatiquement les nouveaux serveurs MCP natifs. Lorsqu'un tel serveur est détecté, AutoCrawler suit un parcours de découverte différent :
- Il effectue un appel listTools au serveur MCP natif pour récupérer les outils qu'il expose explicitement, ainsi que leurs schémas.
- Il crée un serveur MCP proxy virtuel dans le registre MCP contenant tous les outils découverts et leurs schémas, désactivés par défaut.
Serveurs MCP tiers
La MCP Gateway sert de couche d'orchestration centralisée pour toutes les interactions MCP chez Uber, offrant une prise en charge transparente des intégrations tierces telles que Jira et Google.
Le provisionnement des serveurs MCP tiers repose sur la coopération de deux composants clés :
- MCP Gateway : relaie le jeton utilisateur de l'appelant vers l'aval tout en appliquant les capacités essentielles de la passerelle, notamment l'autorisation, la limitation de débit (rate limiting) et l'anonymisation des données sensibles.
- Service MCP tiers : échange le jeton utilisateur interne contre un jeton d'authentification tiers correspondant avant d'envoyer la requête au serveur MCP externe.
Création et activation
Même si nous pouvons créer des serveurs MCP sans impliquer l'équipe responsable du service, la propriété et le contrôle du serveur MCP doivent lui revenir. Un principe de conception fondamental de la MCP Gateway est que la découverte n'implique pas l'exposition. Chaque serveur et outil MCP démarre dans un état désactivé et doit être explicitement examiné puis activé par l'équipe propriétaire. Les responsables de services peuvent examiner et affiner les définitions d'outils générées avant de les activer.
Toute modification de la description d'un outil génère un diff de configuration qui doit être approuvé par les propriétaires du serveur. Ces derniers peuvent approuver et déployer le changement de configuration et, si nécessaire, revenir à une version antérieure connue.
Figure 3 : Interface du registre MCP.
Figure 4 : Interface des outils MCP.
Plan de données
Le plan de données de la MCP Gateway est le service d'exécution principal chargé de traiter les requêtes MCP. Il consomme en continu les configurations des serveurs et des outils depuis le plan de contrôle et actualise son état en mémoire à intervalle régulier. Ainsi, les changements de configuration, comme les mises à jour d'outils ou les modifications d'activation, prennent effet en temps réel sans nécessiter de redémarrage ni de redéploiement du service.
À partir de cette configuration, le plan de données matérialise dynamiquement des serveurs MCP virtuels. Pour chaque serveur virtuel, la passerelle expose un point de terminaison unique /<service-name>/mcp qui sert de porte d'entrée pour l'exécution par les agents IA. Les requêtes entrantes sont acheminées vers les gestionnaires de serveurs correspondants via un serveur proxy intégré.
Figure 5 : Plan de données de la MCP Gateway.
Traduction de protocole et exécution
La traduction de protocole au sein de la MCP Gateway est gérée par les gestionnaires de serveurs (server handlers) de la passerelle proxy. Chaque gestionnaire connaît les outils et les services en aval, ce qui lui permet de router et d'exécuter correctement les requêtes MCP au moment de l'exécution.
Sécurité
La MCP Gateway intègre nativement l'autorisation et l'anonymisation pour tous les serveurs, avec une granularité au niveau de l'outil. Elle s'appuie sur le système de contrôle d'accès interne d'Uber pour appliquer différentes politiques Charter configurées en fonction des acteurs appelants détectés (humains, services et agents). Les politiques Charter sont créées au niveau du serveur, avec des dérogations facultatives au niveau de l'outil si nécessaire.
La MCP Gateway assure également l'anonymisation immédiate de toute donnée personnelle (PII) ou sensible contenue dans les réponses des outils.
Services en aval basés sur des IDL
Pour les outils adossés à des services back-end existants, le gestionnaire de serveur maintient un mappage en mémoire décrivant la destination en aval, comme la configuration d'un point de terminaison HTTP ou les procédures gRPC/TChannel.
Lorsqu'une requête MCP arrive, le gestionnaire :
- Traduit la charge utile JSON entrante dans le format de transmission approprié.
- Sérialise la requête en octets Protobuf ou Thrift.
- Transmet la requête au service en aval.
- Convertit les réponses en octets Protobuf ou Thrift en JSON compatible MCP et les renvoie à l'agent appelant.
La requête en aval proprement dite est exécutée via Muttley, le sidecar de service mesh d'Uber qui fonctionne aux côtés de tous les services back-end. En déléguant l'exécution des requêtes à Muttley, la MCP Gateway bénéficie automatiquement des capacités de routage inter-services existantes.
Serveurs MCP natifs
Les serveurs MCP natifs sont également enregistrés en tant que serveurs virtuels dans le registre MCP, qui agit comme un proxy vers le serveur d'origine. Au moment de l'exécution, les requêtes MCP natives sont transmises de manière transparente au serveur en aval, et les réponses sont relayées à l'appelant.
Les avantages de la passerelle
En développant la MCP Gateway, Uber a mis en place une approche unifiée et évolutive pour construire des systèmes agentiques. Les bénéfices les plus marquants sont les suivants :
- Découverte et installation simplifiées
- Approche no-code pour les API existantes
- Observabilité et sécurité intégrées
- Propriété et gouvernance centralisées
Étendre la passerelle
Le passage à l'échelle de la MCP Gateway à des centaines de serveurs et des milliers d'outils a mis en lumière des problèmes inexistants à petite échelle, notamment le gonflement du contexte et des coûts excessifs.
Découverte au moment de l'exécution
Le MCP ne prévoit pas nativement de recherche interserveurs. Un agent doit déjà savoir à quel serveur s'adresser avant de pouvoir demander quels outils sont disponibles. Configurer un agent pour utiliser un serveur MCP nécessite de câbler explicitement l'URL du serveur, les identifiants et la liste des outils. Répéter cette opération pour des centaines de serveurs n'est pas viable, car tout ce contexte saturerait rapidement la limite de fenêtre du modèle. Nous avons résolu ce problème grâce aux éléments suivants :
- Omni MCP – Un serveur proxy unique qui permet aux clients MCP d'accéder à n'importe quel serveur de la MCP Gateway selon un schéma de découverte progressive, ce qui optimise également le contexte et les tokens grâce à une découverte incrémentale. Omni MCP expose ces outils :
- discover_server – découvrir un serveur MCP en fonction de l'intention de la requête
- discover_tools – rechercher les outils d'un serveur
- get_tool_schema – obtenir le schéma JSON d'un outil
- invoke_tool – appeler un outil
Ensemble, ces outils permettent une découverte incrémentale et un accès à tous les serveurs MCP, avec un contrôle d'accès intégré et l'ensemble des fonctionnalités de la passerelle.
- Projection de réponse – La MCP Gateway propose également la projection de réponse (Response Projection), un modèle d'appel inspiré de GraphQL pour les outils MCP. Il fonctionne en injectant un nouveau champ dans le schéma de requête de l'outil, indiquant à la passerelle de ne demander que les champs nécessaires, et non la totalité. Le LLM lit et injecte les champs sous forme de tableau de chemins imbriqués correspondant uniquement aux champs requis. La passerelle réduit ensuite la réponse au moment de l'exécution en ne conservant que les champs projetés. Cela nous a permis d'étendre la compatibilité des schémas d'API pour le MCP à l'échelle de l'entreprise.
- Code Mode – Les agents de codage opèrent souvent dans des environnements shell où écrire la sortie d'un outil directement dans des fichiers est plus efficace que de charger des réponses complètes dans le contexte du modèle. Le Code Mode répond à ce besoin via aifx, l'interface CLI d'Uber pour les opérations agentiques, en routant les appels MCP via la passerelle sans nécessiter l'installation d'un serveur MCP. Il aide les agents à trouver les bons outils MCP pour une tâche donnée, même si la définition MCP n'est pas présente dans le contexte. aifx expose trois commandes :
- aifx mcp list – lister les serveurs MCP disponibles
- aifx mcp search – rechercher des outils sur tous les serveurs MCP
- aifx mcp call – appeler un outil MCP via la MCP Gateway
Les agents peuvent enchaîner ces commandes en une seule instruction et écrire la sortie dans des fichiers, que les agents de système de fichiers parcourent ensuite sélectivement avec grep pour ne charger dans le contexte que ce dont ils ont besoin. Le Code Mode est désormais la norme chez Uber pour l'utilisation des outils MCP par les agents de codage.
Conclusion
La création de la MCP Gateway a radicalement transformé le fonctionnement des agents IA chez Uber. Ce qui n'était au départ qu'un problème de fragmentation – des dizaines d'équipes connectant indépendamment des intégrations MCP avec des outils hétérogènes, aucune garantie de sécurité partagée et une infrastructure dupliquée – est devenu une plateforme unifiée et évolutive, à laquelle n'importe quelle équipe peut se connecter en quelques minutes.
L'idée centrale qui a guidé notre conception était simple : les API existantes constituent le moyen le plus rapide de fournir des outils à un agent. Plutôt que de demander aux équipes de réécrire leurs services pour un monde agentique, la MCP Gateway s'adapte à leur réalité : elle traduit les appels HTTP, gRPC et TChannel en interactions compatibles MCP de manière transparente, via Muttley, sans aucune modification des services en aval.
Si vous concevez des systèmes agentiques à grande échelle, la partie la plus difficile n'est pas l'IA. C'est la construction du tissu conjonctif – la découverte, la sécurité, la fiabilité – qui rend les agents suffisamment dignes de confiance pour agir au nom de vrais utilisateurs dans un environnement de production. La MCP Gateway est notre réponse à ce défi, et nous espérons que les choix de conception présentés ici seront utiles à ceux qui font face aux mêmes enjeux.
Remerciements
Crédits de la photo de couverture : image générée avec ChatGPT par OpenAI ; aucune image externe, logo ou ressource tierce n'a été utilisé.
gRPC est une marque déposée de la Linux Foundation.
Restez informé des dernières nouveautés d'Uber Engineering : suivez-nous sur LinkedIn pour découvrir nos articles de blog et nos analyses les plus récents.
