Introducción
La rápida adopción de agentes de IA en Uber cambió por completo la forma en que los equipos interactúan con el código, los datos y los sistemas operativos. Las primeras integraciones improvisadas con MCP (Model Context Protocol) demostraron un valor claro: los agentes se volvieron muchísimo más capaces cuando pudieron acceder al contexto del negocio en tiempo real, consultar servicios internos y ejecutar acciones significativas en nombre de los usuarios. Estos primeros logros validaron a MCP como una abstracción poderosa para construir sistemas agénticos dentro de Uber.
Sin embargo, a medida que la adopción se aceleró, surgieron desafíos importantes. Cada equipo construía sus propias integraciones de forma independiente, lo que generó fragmentación en las herramientas e infraestructura duplicada. Las herramientas de MCP eran difíciles de descubrir, complicadas de operar de manera confiable y estaban fuertemente acopladas a servicios o implementaciones de agentes específicos. Aunque estos enfoques funcionaban a pequeña escala, no cubrían las necesidades de Uber cuando cientos de equipos empezaron a explorar flujos de trabajo agénticos. Sin una arquitectura unificada, escalar MCP habría aumentado la complejidad operativa, el riesgo de seguridad y la fricción para los desarrolladores, limitando su impacto final.
Para aprovechar todo el potencial de MCP a la escala de Uber, necesitábamos una solución centralizada y escalable que estandarizara cómo los agentes de IA interactúan con los sistemas back-end existentes, sin quitarle flexibilidad a los equipos. Esta solución debía abstraer las diferencias entre protocolos (HTTP, gRPC™, TChannel), garantizar niveles consistentes de seguridad y observabilidad, y facilitar la creación, el descubrimiento y la reutilización de herramientas MCP en toda la empresa.
Así creamos MCP Gateway para resolver esta necesidad. Es un microservicio fundamental que impulsa todas las interacciones de MCP en Uber, funcionando como una capa de orquestación y enrutamiento entre los agentes de IA, los servicios back-end existentes y los servidores MCP nativos. Al centralizar la lógica de MCP en un solo gateway, ofrecemos un modelo de ejecución consistente para las interacciones entre agentes y servicios, eliminando la necesidad de que cada equipo reinvente la infraestructura base. Las API existentes pueden exponerse sin problemas como herramientas MCP, gestionarse y operarse desde un único lugar, y ser consumidas por múltiples agentes de manera uniforme. MCP Gateway abrió un camino escalable, rápido y consistente para construir agentes de IA dentro de Uber, y actualmente aloja más de 800 servidores MCP y más de 5000 herramientas.
Figura 1: MCP Gateway (APIs como herramientas).
En este blog, repasamos el diseño de MCP Gateway, incluyendo la Capa de Proxy (traducción de MCP a protocolos existentes y viceversa), la Capa de Descubrimiento (MCP Registry y rastreo de APIs) y su plano de control (autoría).
El Gateway
MCP Gateway sigue una arquitectura basada en microservicios, donde el gateway actúa como el punto de integración central entre los sistemas habilitados con IA y los servicios back-end de Uber. La plataforma consta de dos componentes principales: MCP Registry, que funciona como plano de control, y Proxy Gateway, que conforma el plano de datos.
MCP Registry mantiene un catálogo de cientos de servidores MCP respaldados por servicios internos, junto con miles de herramientas MCP. Estas herramientas van desde definiciones no-code que exponen APIs existentes como herramientas MCP, hasta implementaciones completamente nativas construidas específicamente sobre la especificación de MCP. El registro proporciona una única fuente de verdad para el descubrimiento, la propiedad y la habilitación en todo el ecosistema.
Proxy Gateway es responsable de ejecutar las solicitudes MCP en tiempo de ejecución. Traduce las llamadas del protocolo MCP a solicitudes HTTP, gRPC o TChannel, las reenvía al servicio back-end correspondiente y convierte las respuestas nuevamente en resultados compatibles con MCP. Esta capa de traducción permite que los agentes de IA interactúen con los sistemas existentes a través de una interfaz MCP consistente, sin requerir cambios en los servicios subyacentes.
Plano de control
Uber utiliza una arquitectura de microservicios y ejecuta miles de servicios internos que exponen APIs a través de HTTP, gRPC y TChannel. Estas APIs aportan un contexto muy valioso a cualquier sistema de IA, pero pedirle a los equipos que creen manualmente un servidor MCP sería lento y tedioso. Para resolver este problema, construimos AutoCrawler, que escanea continuamente el registro IDL de Uber en busca de APIs, las traduce y las actualiza en el registro. También consulta servidores MCP nativos y los agrega al registro.
AutoCrawler: Motor de descubrimiento
AutoCrawler es un sistema de workflows distribuidos impulsado por Cadence que está suscrito al registro IDL de Uber y a las señales de los servicios internos. Según una programación fija, un cron job dispara un workflow de Cadence que busca nuevos servicios, APIs y cambios de esquema recién agregados.
Por cada entidad descubierta, AutoCrawler se encarga de:
- Crear o actualizar representaciones de servidores MCP
- Generar u obtener definiciones y esquemas de herramientas
- Registrar herramientas en MCP Registry en un estado deshabilitado por defecto
Esta base compartida permite que el descubrimiento de MCP escale a miles de servicios sin que los equipos responsables estén en la ruta crítica.
Figura 2: Auto Crawler.
Descubrimiento para servicios basados en IDL
Para los servicios back-end tradicionales definidos mediante IDLs de Protobuf o Thrift, AutoCrawler genera servidores y herramientas MCP directamente desde el IDL Registry. Para cada grupo de API de servicio, AutoCrawler realiza los siguientes pasos:
- Insertar o actualizar servidor MCP: Crea o actualiza un servidor MCP virtual correspondiente al servicio descubierto.
- Analizar definiciones IDL: Analiza los archivos protobuf o Thrift asociados para extraer nombres de métodos, esquemas de solicitud y respuesta, y comentarios de documentación.
- Generar descripciones de herramientas: Utiliza un LLM para generar descripciones de herramientas MCP enriquecidas y optimizadas para agentes, basadas en los esquemas y comentarios extraídos.
- Traducción de esquemas: Convierte los esquemas de protobuf o Thrift en esquemas JSON-RPC 2.0 compatibles con MCP.
- Insertar o actualizar herramientas MCP: Registra o actualiza las herramientas MCP generadas en MCP Registry en un estado deshabilitado por defecto.
Descubrimiento para servidores nativos
Además de los servicios basados en IDL, MCP Gateway también admite servidores MCP nativos: servicios que implementan el protocolo MCP directamente y exponen herramientas optimizadas para agentes.
MCPFx es el framework que Uber utiliza para construir servidores MCP nativos. Cada servidor MCP nativo emite una métrica de heartbeat que indica su presencia y disponibilidad. AutoCrawler monitorea continuamente estas señales de heartbeat para descubrir automáticamente nuevos servidores MCP nativos. Cuando se detecta uno, AutoCrawler sigue una ruta de descubrimiento diferente:
- Realiza una llamada listTools al servidor MCP nativo para recuperar las herramientas que expone explícitamente, junto con sus esquemas.
- Crea un servidor MCP proxy virtual en MCP Registry que contiene todas las herramientas descubiertas y sus esquemas, en un estado deshabilitado por defecto.
Servidores MCP de terceros
MCP Gateway funciona como la capa de orquestación centralizada para todas las interacciones MCP en Uber, brindando soporte fluido a integraciones de terceros como Jira y Google.
El aprovisionamiento de servidores MCP de terceros depende de la cooperación de dos componentes clave:
- MCP Gateway: Reenvía el token de usuario del llamador hacia downstream mientras aplica capacidades esenciales del gateway, como autorización, limitación de tasa (rate limiting) y redacción de datos sensibles.
- Servicio MCP de terceros: Intercambia el token de usuario interno por un token de autenticación de terceros correspondiente antes de enviar la solicitud al servidor MCP externo.
Autoría y habilitación
Aunque podemos crear servidores MCP sin involucrar al equipo del servicio, la propiedad y el control del servidor MCP deben residir en dicho equipo. Un principio de diseño fundamental de MCP Gateway es que el descubrimiento no implica exposición. Cada servidor y herramienta MCP comienza en un estado deshabilitado y debe ser revisado y habilitado explícitamente por el equipo propietario. Los dueños del servicio pueden revisar y ajustar las definiciones de herramientas generadas antes de habilitarlas.
Cada cambio en la descripción de la herramienta genera un diff de configuración que debe ser aprobado por los propietarios del servidor. Los propietarios pueden aprobar e implementar el cambio de configuración y, si es necesario, revertirlo a una versión anterior conocida.
Figura 3: Interfaz de MCP Registry.
Figura 4: Interfaz de herramientas MCP.
Plano de datos
El plano de datos de MCP Gateway es el servicio de ejecución principal encargado de procesar las solicitudes MCP. Consume continuamente las configuraciones de servidores y herramientas del plano de control y actualiza su estado en memoria a intervalos fijos, lo que permite que los cambios de configuración —como actualizaciones de herramientas o cambios de habilitación— surtan efecto en tiempo real sin reiniciar ni reimplementar servicios.
Con base en esta configuración, el plano de datos materializa dinámicamente servidores MCP virtuales. Para cada servidor virtual, el Gateway expone un único endpoint /<service-name>/mcp que sirve como punto de entrada para la ejecución de los agentes de IA. Las solicitudes entrantes se resuelven hacia sus manejadores de servidor correspondientes a través de un servidor proxy integrado.
Figura 5: Plano de datos de MCP Gateway.
Traducción de protocolos y ejecución
La traducción de protocolos en MCP Gateway es manejada por los manejadores de servidor dentro de Proxy Gateway. Cada manejador conoce tanto las herramientas como los servicios downstream, lo que le permite enrutar y ejecutar correctamente las solicitudes MCP en tiempo de ejecución.
Seguridad
MCP Gateway ofrece autorización y redacción integradas para todos los servidores con granularidad a nivel de herramienta. Utiliza el Sistema de Control de Acceso interno de Uber para aplicar distintas políticas charter configuradas según los actores llamadores detectados (humanos, servicios y agentes). Las políticas charter se crean a nivel de servidor, con anulaciones opcionales a nivel de herramienta si es necesario.
MCP Gateway también realiza de forma nativa la redacción de cualquier dato personal identificable (PII) o información sensible en las respuestas de las herramientas.
Servicios downstream basados en IDL
Para las herramientas respaldadas por servicios back-end existentes, el manejador de servidor mantiene un mapeo en memoria que describe el destino downstream, como la configuración del endpoint HTTP o los procedimientos de gRPC/TChannel.
Cuando llega una solicitud MCP, el manejador:
- Traduce el payload JSON entrante al formato de transmisión adecuado.
- Serializa la solicitud en bytes de Protobuf o Thrift.
- Reenvía la solicitud al servicio downstream.
- Traduce las respuestas en bytes de Protobuf o Thrift de vuelta a JSON compatible con MCP y las devuelve al agente llamador.
La solicitud downstream real se ejecuta a través de Muttley, el sidecar de service mesh de Uber que corre junto a todos los servicios back-end. Al delegar la ejecución de solicitudes a Muttley, MCP Gateway se beneficia automáticamente de las capacidades de enrutamiento servicio a servicio ya existentes.
Servidores MCP nativos
Los servidores MCP nativos también se registran como servidores virtuales en MCP Registry, que actúa como proxy hacia el servidor original. En tiempo de ejecución, las solicitudes MCP nativas se enrutan de forma transparente al servidor downstream, y las respuestas regresan al llamador a través del mismo proxy.
Beneficios del Gateway
Al construir MCP-Gateway, Uber logró un enfoque unificado y escalable para desarrollar sistemas agénticos, y los beneficios más impactantes provienen de:
- Descubrimiento e instalación sencillos
- Enfoque no-code para APIs existentes
- Observabilidad y seguridad integradas
- Propiedad y gobernanza centralizadas
Extensión del Gateway
Escalar MCP Gateway a cientos de servidores y miles de herramientas reveló problemas que no existen a pequeña escala. Inflación de contexto y costos excesivos
Descubrimiento en tiempo de ejecución
MCP no tiene un concepto nativo de búsqueda entre servidores. Un agente ya debe saber con qué servidor comunicarse antes de poder preguntar qué herramientas están disponibles. Configurar un agente para usar un servidor MCP requiere conectar explícitamente la URL del servidor, las credenciales y la lista de herramientas. Hacer esto para cientos de servidores no escala, ya que todo ese contexto consumiría el límite de contexto del modelo. Resolvimos este problema con lo siguiente:
- Omni MCP - Un único servidor proxy que permite a los clientes MCP acceder a cualquiera de los servidores de MCP Gateway con un patrón de descubrimiento gradual, lo que también permite optimizar el contexto y los tokens mediante un descubrimiento incremental. Omni MCP expone estas herramientas:
- discover_server - descubre un servidor MCP según la intención de la consulta
- discover_tools - busca herramientas para un servidor
- get_tool_schema - obtiene el esquema json de una herramienta
- invoke_tool - invoca una herramienta
En conjunto, estas herramientas permiten el descubrimiento incremental y el acceso a todos los servidores MCP, con control de acceso integrado y el resto de las funciones del gateway.
- Response Projection - MCP Gateway también ofrece Response Projection, un patrón de llamada similar a GraphQL para herramientas MCP. Funciona inyectando un nuevo campo en el esquema de solicitud de la herramienta, que le indica al gateway que solicite solo los campos necesarios y no todos. El LLM lee e inyecta los campos con un arreglo de rutas anidadas únicamente de los campos requeridos. Luego, el Gateway recorta la respuesta en tiempo de ejecución conservando solo los campos proyectados. Esto nos ha permitido escalar la compatibilidad de esquemas de API para MCP a nivel empresarial.
- Code Mode - Los agentes de programación suelen operar en entornos de shell donde escribir la salida de las herramientas directamente en archivos es más eficiente que cargar respuestas completas en el contexto del modelo. Code Mode soporta este patrón a través de aifx, la CLI de Uber para operaciones agénticas, enrutando las llamadas MCP a través del gateway sin requerir que se instale ningún servidor MCP. Ayuda a los agentes a descubrir las herramientas MCP correctas para el trabajo sin que la definición MCP esté presente en el contexto. aifx expone tres comandos:
- aifx mcp list - lista los servidores MCP disponibles
- aifx mcp search - busca herramientas en todos los servidores MCP
- aifx mcp call - invoca una herramienta MCP a través de MCP Gateway
Los agentes pueden encadenarlos en un solo comando y escribir la salida en archivos, que luego los agentes de sistema de archivos filtran selectivamente con grep, cargando en el contexto solo lo que necesitan. Code Mode es ahora el estándar de la empresa para el uso de herramientas MCP en agentes de programación.
Conclusión
Construir MCP Gateway cambió radicalmente la forma en que operan los agentes de IA en Uber. Lo que comenzó como un problema de fragmentación, con decenas de equipos conectando integraciones MCP de forma independiente, con herramientas inconsistentes, sin garantías de seguridad compartidas e infraestructura duplicada, hoy es una plataforma unificada y escalable en la que cualquier equipo puede integrarse en minutos.
La idea central que impulsó nuestro diseño fue simple: las APIs existentes son la forma más rápida de proporcionarle herramientas a un agente. En lugar de pedirles a los equipos que reescribieran sus servicios para un mundo agéntico, MCP Gateway se adapta a su realidad: traduce llamadas HTTP, gRPC y TChannel en interacciones compatibles con MCP de forma transparente, a través de Muttley y sin modificar los servicios downstream.
Si estás construyendo sistemas agénticos a gran escala, la parte más difícil no es la IA. Es construir el tejido conectivo: el descubrimiento, la seguridad y la confiabilidad que hacen que los agentes sean lo suficientemente confiables para actuar en nombre de usuarios reales en un entorno de producción. MCP Gateway es nuestra respuesta a ese desafío, y esperamos que las decisiones de diseño documentadas aquí les resulten útiles a otros que enfrentan el mismo problema.
Agradecimientos
Créditos de la foto de portada: Generada con ChatGPT de OpenAI; no se utilizaron imágenes externas, logotipos ni recursos de terceros.
gRPC es una marca registrada de The Linux Foundation.
Mantente al día con las últimas novedades de Uber Engineering: síguenos en LinkedIn para conocer nuestros artículos y análisis más recientes.
