L’adoption rapide des agents d’intelligence artificielle chez Uber a montré le potentiel du protocole MCP (Model Context Protocol). Au début, les intégrations étaient ad hoc, mais cette approche a vite créé une fragmentation des outils et des infrastructures, rendant le système difficile à gérer à l’échelle de centaines d’équipes.

Pour que le MCP atteigne son plein potentiel, il fallait une solution centralisée. Uber a donc développé le MCP Gateway, un microservice fondamental qui sert de couche d’orchestration et de routage entre les agents IA et les systèmes backend existants. Ce Gateway permet d’exposer des API existantes comme des outils MCP sans que les équipes aient à réinventer l’infrastructure de base.

Cette plateforme centralisée gère actuellement plus de 800 serveurs MCP et un catalogue dépassant les 5 000 outils. Son architecture repose sur deux composantes principales : le MCP Registry, qui agit comme le plan de contrôle, et le Proxy Gateway, qui constitue le plan de données.

Le MCP Registry centralise la connaissance : il maintient le catalogue des serveurs et des outils. Ce catalogue n’est pas rempli manuellement. Uber a mis en place AutoCrawler, un système de workflow distribué basé sur Cadence. Ce dernier scanne en continu le registre des IDL (Interface Definition Language) pour détecter les nouvelles APIs et les changements de schémas.

Pour les services traditionnels définis via Protobuf ou Thrift IDLs, AutoCrawler extrait les métadonnées. Il utilise ensuite un grand modèle de langage pour générer des descriptions d’outils adaptées aux agents, avant de traduire les schémas en JSON-RPC 2.0 compatible MCP. Ces outils sont enregistrés par défaut en mode désactivé, attendant une validation par l’équipe propriétaire.

Le Gateway ne gère pas que les services basés sur IDL. Il supporte aussi les serveurs MCP natifs, construits avec le framework interne MCPFx. AutoCrawler surveille les signaux de vie (heartbeats) de ces serveurs pour les intégrer automatiquement au registre.

Le Proxy Gateway, lui, est le traducteur en temps réel. Il prend une requête MCP et la convertit en un appel HTTP, gRPC ou TChannel adapté au service backend, puis inverse le processus pour renvoyer une réponse utilisable par l’agent IA. Cette couche de traduction permet aux agents d’interagir avec les systèmes existants via une interface MCP uniforme.

L’approche a déjà suscité des réactions dans la communauté. Ajay Sharma, ingénieur principal chez Microsoft CoreAI, a commenté que ce type de solution est « une recette pour l’ordre face au chaos que les LLMs engendrent » (LinkedIn).

Au-delà de la simple traduction de protocoles, le Gateway impose des mécanismes de gouvernance. Il intègre le système de contrôle d’accès interne d’Uber pour garantir l’autorisation au niveau du serveur et de l’outil. Il prend également en charge le masquage des informations personnellement identifiables (PII) dans les réponses. Pour les intégrations tierces, comme Jira ou Google, un service dédié échange les jetons d’authentification internes contre les jetons requis par ces plateformes.

Pour éviter que le contexte des agents ne soit surchargé par des milliers d’outils, Uber a développé Omni MCP. Ce système permet une découverte incrémentielle : l’agent ne charge pas tout d’un coup, mais peut chercher des serveurs spécifiques, récupérer des schémas individuels et invoquer uniquement les fonctions nécessaires. De plus, la Projection de Réponse permet à l’agent de demander des champs précis au lieu de recevoir des paquets de données complets.

Le fait que les changements de configuration puissent se propager au plan de données sans nécessiter de redémarrage ou de nouveau déploiement, grâce à l’automatisation d’AutoCrawler, simplifie grandement le cycle de vie de ces outils IA.

Sources

• Designing MCP Gateway Uber’s MCP Management Platform, uber.com
• Uber Builds MCP Gateway to Govern Access to 800+ Servers and 5,000+ AI Agent Tools, InfoQ, 2 novembre 2026