Introducción
La rápida adopción de agentes de IA por parte de Uber ha transformado 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 evidente: los agentes se volvieron drásticamente más capaces cuando pudieron acceder a contexto empresarial en tiempo real, consultar servicios internos y ejecutar acciones significativas en nombre de los usuarios. Estos primeros éxitos validaron a MCP como una abstracción potente para construir sistemas agénticos dentro de Uber.
Sin embargo, a medida que la adopción se aceleró, surgieron desafíos importantes. Cada equipo desarrollaba sus propias integraciones de forma independiente, lo que provocó fragmentación en las herramientas e infraestructura duplicada. Las herramientas MCP eran difíciles de descubrir, complicadas de operar de manera fiable y estaban estrechamente acopladas a servicios o implementaciones de agentes específicos. Aunque estos enfoques funcionaban a pequeña escala, no satisfací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 en última instancia su impacto.
Para aprovechar todo el potencial de MCP a la escala de Uber, necesitábamos una solución centralizada y escalable que estandarizara la forma en que los agentes de IA interactúan con los sistemas back-end existentes, sin sacrificar la flexibilidad de los equipos. Esta solución debía abstraer las diferencias entre protocolos (HTTP, gRPC™, TChannel), garantizar una seguridad y observabilidad consistentes, y facilitar la creación, el descubrimiento y la reutilización de herramientas MCP en toda la empresa.
Creamos MCP Gateway para resolver esta necesidad. Se trata de un microservicio fundamental que impulsa todas las interacciones MCP en Uber, actuando como 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 único 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 básica. Las API existentes pueden exponerse sin problemas como herramientas MCP, gestionarse y operarse desde un solo lugar, y ser consumidas por múltiples agentes de manera uniforme. MCP Gateway abrió un camino escalable, rápido y consistente para desarrollar 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 artículo, repasamos el diseño de MCP Gateway, abarcando 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 punto de integración central entre los sistemas habilitados para 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 MCP. El registro proporciona una única fuente de verdad para el descubrimiento, la propiedad y la habilitación en todo el ecosistema.
Proxy Gateway se encarga 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 de nuevo en resultados compatibles con MCP. Esta capa de traducción permite que los agentes de IA interactúen con los sistemas existentes mediante 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 desarrollaran manualmente un servidor MCP sería lento y tedioso. Para resolver este problema, construimos AutoCrawler, que analiza 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 añade al registro.
AutoCrawler: Motor de descubrimiento
Autocrawler es un sistema de flujos de trabajo distribuido impulsado por Cadence suscrito al registro IDL de Uber y a las señales de los servicios internos. Según una programación fija, un trabajo cron desencadena un flujo de trabajo de Cadence que busca nuevos servicios, APIs y cambios de esquema añadidos recientemente.
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 queden 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, basándose 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 supervisa 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 actúa como la capa de orquestación centralizada para todas las interacciones MCP en Uber, ofreciendo soporte fluido a integraciones de terceros como Jira y Google.
El aprovisionamiento de servidores MCP de terceros depende de la colaboración de dos componentes clave:
- MCP Gateway: Reenvía el token de usuario del llamante hacia los servicios posteriores, aplicando al mismo tiempo 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 responsable 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 responsables del servicio pueden revisar y ajustar las definiciones de herramientas generadas antes de habilitarlas.
Cualquier cambio en la descripción de la herramienta genera un diff de configuración que debe ser aprobado por los propietarios del servidor. Estos pueden aprobar y desplegar 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 principal en tiempo de ejecución encargado de ejecutar las solicitudes MCP. Consume continuamente las configuraciones de servidores y herramientas del plano de control y actualiza su estado en memoria a intervalos regulares, lo que permite que los cambios de configuración —como actualizaciones de herramientas o modificaciones de habilitación— surtan efecto en tiempo real sin reiniciar ni redesplegar el servicio.
Basándose 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 por parte de los agentes de IA. Las solicitudes entrantes se resuelven hacia sus manejadores de servidor correspondientes mediante 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 la gestionan los manejadores de servidor dentro de Proxy Gateway. Cada manejador conoce tanto las herramientas como los servicios posteriores, 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 llamantes detectados (humanos, servicios y agentes). Las políticas charter se crean a nivel de servidor, con anulaciones opcionales a nivel de herramienta si fuera necesario.
MCP Gateway también realiza de forma nativa la redacción de cualquier dato personal identificable (PII) o información sensible presente en las respuestas de las herramientas.
Servicios posteriores 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 posterior, como la configuración de un 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 posterior.
- Traduce las respuestas en bytes de Protobuf o Thrift de vuelta a JSON compatible con MCP y las devuelve al agente llamante.
La solicitud posterior real se ejecuta a través de Muttley, el sidecar de service mesh de Uber que se ejecuta 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 posterior, y las respuestas se devuelven al llamante a través del proxy.
Beneficios del Gateway
Al construir MCP-Gateway, Uber ha logrado un enfoque unificado y escalable para desarrollar sistemas agénticos, y los beneficios más destacados provienen de:
- Descubrimiento e instalación sencillos
- Enfoque no-code para APIs existentes
- Observabilidad y seguridad integradas
- Propiedad y gobernanza centralizadas
Ampliación del Gateway
Escalar MCP Gateway a cientos de servidores y miles de herramientas puso de manifiesto problemas que no existen a pequeña escala. Inflación de contexto y costes excesivos
Descubrimiento en tiempo de ejecución
MCP no tiene un concepto nativo de búsqueda entre servidores. Un agente necesita saber de antemano 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 mediante un patrón de descubrimiento gradual, lo que además posibilita optimizar el contexto y los tokens a través del descubrimiento incremental. Omni MCP expone estas herramientas:
- discover_server - descubre un servidor MCP basándose en 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 funcionalidades 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 indica al gateway que solicite únicamente los campos necesarios, no todos. El LLM lee e inyecta los campos mediante un array de rutas anidadas que incluye solo los campos requeridos. Después, el Gateway recorta la respuesta en tiempo de ejecución conservando únicamente 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 shell donde escribir la salida de las herramientas directamente en archivos resulta más eficiente que cargar respuestas completas en el contexto del modelo. Code Mode da soporte a este patrón a través de aifx, la CLI de Uber para operaciones agénticas, enrutando las llamadas MCP por el gateway sin necesidad de instalar ningún servidor MCP. Ayuda a los agentes a descubrir las herramientas MCP adecuadas para cada tarea 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 únicamente 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
La construcción de MCP Gateway ha transformado radicalmente la forma en que operan los agentes de IA en Uber. Lo que empezó como un problema de fragmentación, con decenas de equipos conectando integraciones MCP por su cuenta con herramientas dispares, sin garantías de seguridad compartidas y con infraestructura duplicada, es hoy una plataforma unificada y escalable a la que cualquier equipo puede conectarse en cuestión de minutos.
La idea central que impulsó nuestro diseño era sencilla: las APIs existentes son la vía más rápida para proporcionar herramientas a un agente. En lugar de pedir a los equipos que reescribieran sus servicios para adaptarse a un mundo agéntico, MCP Gateway se adapta a su realidad: traduce llamadas HTTP, gRPC y TChannel a interacciones compatibles con MCP de forma transparente, a través de Muttley y sin modificar en absoluto los servicios posteriores.
Si estás construyendo sistemas agénticos a gran escala, lo más difícil no es la IA. Es crear el tejido conectivo —el descubrimiento, la seguridad, la fiabilidad— que hace que los agentes sean lo bastante 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í resulten útiles a otros que se enfrenten al mismo problema.
Agradecimientos
Atribución 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 leer nuestros artículos y análisis más recientes.
