MCP Gateway de Uber: qué aprender de su diseño para tu empresa

El MCP Gateway de Uber es el microservicio por el que pasan todas las interacciones MCP de la empresa. Tiene dos partes: un registro que hace de plano de control y un proxy que traduce las llamadas MCP a HTTP, gRPC y TChannel, que hace de plano de datos. Según el artículo de Uber Engineering del 2 de octubre de 2026, aloja más de 800 servidores MCP y más de 5000 tools. Aquí no lo traducimos. Lo desmontamos pieza a pieza para quien quiera construir algo parecido, separando lo que se puede copiar de lo que conviene discutir.

Llegamos a él por el resumen en español que publicó @santtiagom_ el 3 de octubre. Todo lo que contamos de Uber sale del artículo original. Cuando lo comparamos con el protocolo, la referencia es la especificación 2026-07-28. Uber no dice qué versión de MCP implementa, así que esas comparaciones son nuestras, no suyas.

El problema: cada equipo con su integración

La historia empieza como en casi todas las empresas. Las primeras integraciones con MCP se hicieron sin un plan común y salieron bien. Con acceso a servicios internos y a datos vivos del negocio, los agentes hacían mucho más, y a partir de ahí cada equipo montó su propia integración.

El resultado que describe Uber te sonará. Había herramientas duplicadas y tools difíciles de encontrar y de operar, acopladas a un servicio o a un agente concreto. Con cientos de equipos explorando flujos agénticos, eso escalaba mal en tres frentes: complejidad operativa, riesgo de seguridad y fricción para los desarrolladores.

Uber decidió centralizar sin quitar la propiedad a los equipos. El gateway tenía que cumplir tres cosas:

• esconder las diferencias de protocolo internas
• aplicar las mismas garantías de seguridad y observabilidad a todo
• hacer que crear, descubrir y reutilizar una tool fuera fácil.

Su tesis aparece en la conclusión del artículo: “existing APIs are the fastest way to provide tools to an agent”. Volveremos a ella en la parte crítica, porque es la decisión de diseño más discutible.

La arquitectura: plano de control y plano de datos

El diseño separa dos responsabilidades clásicas de cualquier plataforma de red:

• Plano de control: el MCP Registry. Es el catálogo y la fuente de verdad. Dice qué servidores y tools existen, quién es su dueño y si están activados. Contiene desde tools sin código, que exponen una API existente, hasta servidores nativos escritos contra la especificación.
• Plano de datos: el Proxy Gateway. Atiende las peticiones en tiempo de ejecución. Recibe la llamada MCP, la traduce al protocolo del servicio, la reenvía y convierte la respuesta en un resultado MCP. Los servicios de detrás no cambian.

flowchart LR
  subgraph CP["Plano de control"]
    IDL["IDL registry (Protobuf y Thrift)"]
    HB["Heartbeat de servidores nativos (MCPFx)"]
    AC["AutoCrawler (workflow de Cadence)"]
    REG["MCP Registry (todo nace desactivado)"]
    OWN["Equipo dueño: revisa, aprueba el diff, activa o vuelve atrás"]
    IDL --> AC
    HB --> AC
    AC --> REG
    OWN --> REG
  end
  subgraph DP["Plano de datos: Proxy Gateway (autorización y redacción)"]
    VS["Servidores virtuales: /nombre-servicio/mcp"]
    SH["Server handlers: traducción y enrutado por tool"]
    VS --> SH
  end
  AG["Agentes: Omni MCP o aifx (Code Mode)"] --> VS
  REG -. "configuración refrescada en memoria" .-> DP
  SH --> MU["Muttley (sidecar del service mesh)"]
  MU --> BE["Servicios internos: HTTP, gRPC, TChannel"]
  SH --> NAT["Servidores MCP nativos (MCPFx)"]
  SH --> TP["Third-Party MCP Service: intercambia el token"]
  TP --> EXT["Servidores MCP externos (Jira, Google)"]

AutoCrawler: el catálogo se rellena solo

Pedir a cada equipo que escriba a mano un servidor MCP para su servicio era, en palabras de Uber, lento y doloroso. Así que construyeron AutoCrawler, un sistema de workflows sobre Cadence que se dispara con un cron a intervalo fijo y recorre dos fuentes:

1. El IDL registry. Cubre los servicios definidos con Protobuf o Thrift. Por cada servicio y grupo de API, AutoCrawler crea o actualiza un servidor MCP virtual. Después analiza los IDL para sacar métodos, esquemas de petición y respuesta y comentarios. Con un LLM genera descripciones de tool pensadas para un agente. Por último traduce los esquemas al formato de MCP y registra las tools.
2. Los servidores nativos. Uber tiene un framework propio, MCPFx, para escribir servidores MCP de verdad. Cada uno emite una métrica de heartbeat que AutoCrawler vigila. Cuando aparece un servidor nuevo, AutoCrawler le pide su lista de tools y crea en el registro un servidor virtual que hace de proxy hacia él.

En los dos caminos, lo que se registra queda desactivado por defecto. Es el detalle más importante de todo el diseño y tiene sección propia más abajo.

El proxy: un endpoint por servicio

El proxy no consulta el registro en cada petición. Guarda en memoria una copia de la configuración y la renueva cada cierto tiempo. Por eso, cuando alguien activa una tool o cambia su descripción, el cambio se nota en caliente, sin reinicios ni despliegues. A partir de esa copia, el proxy monta los servidores virtuales, uno por servicio, cada uno con su endpoint /<nombre-del-servicio>/mcp.

Dentro de cada servidor, unos server handlers saben qué tool es cada una y a dónde va. Para un servicio con IDL, el handler guarda en memoria un mapa con el destino, que puede ser una configuración HTTP o un procedimiento gRPC o TChannel. En cada llamada, el handler convierte el JSON de entrada al formato de cable, lo serializa en bytes de Protobuf o Thrift y lo envía. Con la respuesta hace el camino inverso.

La petición real no la hace el gateway, sino Muttley, el sidecar del service mesh de Uber. Así hereda el enrutado entre servicios que ya existía. Los servidores nativos se proxifican de forma transparente.

Aquí hay dos decisiones que merecen copiarse tal cual. La primera es separar catálogo y ejecución. El registro puede ser lento y transaccional, con revisiones, diffs e historial, mientras el proxy solo lee su copia en memoria y no depende del registro para atender una llamada. La segunda es dar un endpoint a cada servicio, porque así cada equipo tiene su espacio de nombres. La especificación 2026-07-28 pide a los agregadores que desambigüen las colisiones de nombres de tool entre servidores. Con un servidor virtual por servicio, el problema casi desaparece.

Esto conecta con lo que ya enseña el curso. En «Arquitecturas distribuidas», del nivel Experto, la pasarela de Nortia sale de un fichero de destinos mantenido a mano, y discutimos de dónde debería salir esa tabla. Uber responde a esa pregunta a escala: la tabla la genera un rastreador y la gobierna un registro. Si te interesa el lado público del descubrimiento, lo tienes en Server Cards y AI Catalog.

Descubrir no es exponer

Uber formula el principio con cuatro palabras: “discovery doesn’t imply exposure”. AutoCrawler puede crear el servidor MCP de un servicio sin que su equipo intervenga, pero la propiedad y el control siguen siendo del equipo. En la práctica:

• Todo empieza desactivado. Ningún servidor ni tool generados automáticamente llegan a un agente hasta que el equipo dueño los revisa y los activa.
• El dueño puede corregir lo generado. El equipo dueño revisa y refina las descripciones que escribió el LLM antes de activar nada.
• Cada cambio de descripción es un diff de configuración que tiene que aprobar el dueño del servidor. El dueño lo aprueba, se despliega y, si algo va mal, se vuelve a una versión anterior conocida.

Esto importa tanto porque la descripción de una tool es código que ejecuta un modelo. Si la cambias, cambia cuándo y cómo la llama el agente, y una descripción manipulada es un vector de inyección conocido. Por eso lo correcto es tratarla con el mismo flujo que un cambio de configuración en producción, con revisión, aprobación y vuelta atrás. Si en tu empresa los servidores MCP se publican sin revisión, este es el punto que más barato sale copiar. El gobierno de quién publica qué está desarrollado en «Patrones enterprise», también del nivel Experto.

Seguridad: políticas por actor, redacción y tokens de terceros

El artículo dedica poco espacio a la seguridad, pero lo que cuenta tiene sustancia.

Autorización por tipo de actor. El gateway usa el sistema de control de acceso interno de Uber para aplicar políticas según quién llama: humanos, servicios o agentes. Uber las llama charter policies. Se definen por servidor y admiten excepciones por tool. Nos parece la granularidad adecuada. Casi siempre el permiso se piensa por servicio, pero la tool que borra o la que devuelve datos sensibles necesita una regla propia. También acierta al distinguir en la política a un agente de un humano, porque un agente puede tener menos permisos que la persona por la que actúa.

Redacción de datos personales. El gateway elimina “out-of-the-box” los datos personales y sensibles de las respuestas de las tools. Como red de seguridad está bien, pero no lo uses como diseño principal. En «Diseño de servidores MCP», del nivel Avanzado, la regla es que un dato personal sin una tarea que lo necesite no sale del servidor, porque lo que no sale no puede acabar en un contexto. Redactar en el gateway te protege de los errores de los servidores, pero no sustituye a diseñarlos bien.

Servidores de terceros e intercambio de token. En integraciones como Jira o Google intervienen dos piezas:

• el gateway, que retransmite el token del usuario aguas abajo y aplica autorización, límites de tasa y redacción
• un Third-Party MCP Service interno, que cambia ese token interno por un token del tercero antes de llamar al servidor externo.

De cara al servidor externo, esto no es reenviar el token del usuario, y la diferencia importa. La especificación 2026-07-28 es tajante. Un servidor MCP debe validar que el token se emitió para él, y no debe aceptar ni reenviar tokens emitidos para otro: el token passthrough está prohibido. Si el gateway mandara a Jira el token interno de Uber, el servidor externo recibiría una credencial que no es para él. Se saltarían sus controles y se perdería la trazabilidad. Con el intercambio, el tercero recibe un token de su propio sistema, no la credencial interna de Uber. El artículo habla de un token de autenticación del tercero “correspondiente”, pero no da los detalles del canje.

El artículo tampoco detalla el tramo interno. No dice con qué audiencia viaja el token del usuario desde el gateway al servicio de terceros, ni cómo se obtiene el consentimiento del usuario ante cada proveedor. Si vas a replicar el patrón, esos son los dos sitios donde se cuelan el confused deputy y el paso de tokens. Los recorremos con código en «Seguridad avanzada», del nivel Experto. Los fallos reales de los últimos meses están en lo que enseñan dos meses de avisos de seguridad.

El problema de escala: el contexto

Con cientos de servidores y miles de tools aparece un problema que no existe a pequeña escala: el contexto. Uber lo plantea así: “MCP has no native concept of cross-server search”. Para hablar con un servidor hay que conocerlo antes. Configurar a mano la URL, las credenciales y la lista de tools de cientos de servidores no escala, ni para las personas ni para la ventana de contexto del modelo. Uber propone tres respuestas, y cada una ataca una parte distinta del gasto.

Omni MCP: cuatro meta-tools en lugar de cinco mil

Omni MCP es un único servidor proxy que da acceso a cualquier servidor del gateway mediante descubrimiento gradual. En lugar de cargar miles de definiciones, el cliente ve cuatro tools:

Todo pasa por el gateway, así que el control de acceso y el resto de garantías se mantienen.

sequenceDiagram
  participant A as Agente
  participant O as Omni MCP
  participant G as MCP Gateway
  participant S as Servidor virtual
  A->>O: discover_server(intención)
  O-->>A: servidores candidatos
  A->>O: discover_tools(servidor)
  O-->>A: tools de ese servidor
  A->>O: get_tool_schema(tool)
  O-->>A: JSON Schema de la tool
  A->>O: invoke_tool(tool, argumentos)
  O->>G: llamada con control de acceso
  G->>S: tools/call
  S-->>G: resultado
  G-->>O: resultado redactado
  O-->>A: resultado
  Note over A,O: El agente solo carga en contexto lo que va pidiendo

Es el mismo patrón que la búsqueda de tools que vemos en «Rendimiento y coste de contexto», del nivel Experto, llevado al gateway. Tiene un coste que el artículo no menciona: el host ya no ve las tools reales, solo ve invoke_tool. Las anotaciones de cada tool (readOnlyHint, destructiveHint) dejan de aplicarse de forma natural, y lo mismo le pasa a la aprobación tool a tool que hacen muchos hosts. Para el host, todo es la misma meta-tool. Y ocurre igual con la cabecera Mcp-Name de 2026-07-28: cualquier intermediario que filtre por nombre de tool verá siempre invoke_tool.

Uber lo compensa con la autorización en el gateway. Si construyes algo así, la confirmación de acciones destructivas también tiene que vivir en el gateway, o perderás esa barrera. Esto es una inferencia nuestra a partir del diseño, no algo que cuente la fuente.

Response Projection: pedir solo los campos que necesitas

La segunda respuesta ataca el tamaño de los resultados, no el de las definiciones. Response Projection es un patrón de llamada “GraphQL-like” que funciona en tres pasos:

1. El gateway inyecta un campo nuevo en el esquema de entrada de la tool.
2. El modelo rellena ese campo con una lista de rutas anidadas de los campos que necesita.
3. El gateway recorta la respuesta en tiempo de ejecución y deja solo esos campos.

Uber no publica el nombre del campo ni su formato exacto. Para que veas la idea, una llamada podría tener esta forma. El nombre _projection y las rutas son inventados:

{
  "name": "getTrip",
  "arguments": {
    "trip_id": "abc-123",
    "_projection": ["status", "driver.name", "fare.total"]
  }
}

Con APIs internas que devuelven objetos enormes, esto puede ahorrar mucho contexto sin tocar el servicio. Eso sí, tiene implicaciones de esquema que veremos en la parte crítica.

Code Mode con una CLI: el resultado va a un fichero

La tercera respuesta es para agentes de programación que trabajan en una shell. Ahí es más eficiente escribir la salida de una tool en un fichero que meterla entera en el contexto. Uber lo resuelve con aifx, su CLI para operaciones agénticas. aifx enruta las llamadas MCP por el gateway sin instalar ningún servidor MCP en el cliente:

• aifx mcp list: lista los servidores disponibles.
• aifx mcp search: busca tools en todos los servidores.
• aifx mcp call: invoca una tool a través del gateway.

El agente encadena comandos en una sola línea, vuelca la salida a ficheros y luego hace grep de lo que necesita. Según Uber, Code Mode es ya la opción por defecto de la empresa para el uso de tools MCP en agentes de programación.

No lo confundas con el Code Mode de Cloudflare, en el que el modelo escribe código contra una API tipada y ese código se ejecuta en un sandbox. Lo contamos en un artículo de 2025 sobre Code Mode, hoy histórico, y lo tienes al día en la lección de rendimiento. El de Uber es más simple: una CLI y el sistema de ficheros. Los dos comparten la idea de fondo: el resultado de una tool no tiene por qué pasar por el contexto del modelo.

Qué puede aplicar una empresa mediana

No tienes 800 servidores, pero algunas decisiones de Uber valen desde el primer servidor compartido:

1. Un registro con dueño y estado desde el día uno. Puede ser un repositorio con un fichero por servidor: dueño, endpoint, tools activadas y su descripción. Las pull requests son tus diffs de configuración aprobados y git revert es tu vuelta atrás. Lo que no esté en el registro no se enruta.
2. Desactivado por defecto, siempre. Tanto si el servidor lo escribe un equipo como si lo genera una herramienta a partir de una API, nada llega a un agente sin que alguien con responsabilidad lo active.
3. Generar sí, pero como borrador. Generar tools a partir de OpenAPI, Protobuf o lo que tengas ahorra el arranque. Trata el resultado como un primer borrador que el equipo dueño reduce y reorganiza por tarea antes de activarlo.
4. Autorización y auditoría en el gateway, con políticas por servidor, excepciones por tool y distinción entre personas, servicios y agentes. Nada de reenviar tokens: el gateway valida el del usuario y presenta aguas abajo una credencial propia o un token intercambiado.
5. Mide antes de construir Omni. Mide lo que ocupa tu tools/list y lo que ocupan los resultados. Con unas decenas de tools, suele bastar con seleccionar cuáles ve cada cliente. La búsqueda incremental y la proyección se justifican cuando los números lo dicen.
6. Valora comprar antes que construir. Hay gateways gestionados que cubren parte de esto. Los portales MCP de Cloudflare dan un endpoint único con Access, selección de tools, Code Mode, logs y DLP. AgentCore Gateway de AWS convierte APIs y funciones Lambda en tools con búsqueda semántica. Lo que Uber tiene, y que un producto genérico difícilmente te dará, es la integración con su registro de IDL y su service mesh. Si tu ventaja no está ahí, no la construyas.

Si quieres ver hacia dónde va la autorización empresarial en el protocolo, con Enterprise-Managed Authorization ya estable, mira el roadmap de MCP hasta 2027.

Mirada crítica: lo que el artículo no cuenta

Es un buen artículo de arquitectura, pero deja fuera cosas que necesitarías para decidir:

• La versión del protocolo. No dice qué versión de MCP implementan el gateway, Omni MCP o MCPFx, ni si hablan ya el protocolo sin estado de 2026-07-28. Para un gateway es relevante. En esa versión, tools/list lleva ttlMs y cacheScope obligatorios y puede variar según la autorización, y los avisos de cambio de lista solo llegan por subscriptions/listen. Un gateway que activa tools en caliente tiene que decidir qué TTL anuncia, o los clientes seguirán con la lista vieja. El artículo no entra en esto.
• Cifras de coste y de calidad. Hay dos números de tamaño, más de 800 servidores y más de 5000 tools, y ninguno de efecto. No dice cuántos tokens ahorran Omni MCP o la proyección, ni cómo cambia la tasa de acierto del agente al elegir tool, ni qué latencia añade el proxy.
• Cómo evalúan las descripciones generadas por LLM. Un modelo escribe la descripción que otro modelo leerá para decidir. La revisión del dueño es un control humano, pero no se menciona ninguna evaluación sistemática de si las descripciones generadas llevan al agente a la tool correcta.
• Detalles de seguridad. Faltan el tramo interno del token hacia el servicio de terceros, el consentimiento ante cada proveedor y cómo se detectan los datos personales que se redactan.

Tensiones con lo que enseñamos en el curso

Tools 1:1 desde la API frente a tools por tarea. El camino de AutoCrawler genera una tool por cada método de la API. Con las cifras de Uber salen unas seis tools por servidor de media; la cuenta es nuestra. En «Diseño de servidores MCP» defendemos lo contrario. El criterio de granularidad es la tarea del usuario, no la forma de la API, porque cada paso que dejas componer al modelo es una regla de negocio que ya no ejecuta tu código.

Uber no es ajeno a esto. Separa los servidores nativos de MCPFx, que exponen “agent-optimized tools”, de los generados, y usa la revisión del dueño como filtro. Nuestra lectura es que lo generado es un buen punto de partida para tener cobertura rápido, pero un mal punto de llegada para las tareas importantes. Las tools que más se usen deberían acabar rediseñadas por tarea.

Projection y el esquema. Inyectar un campo en el inputSchema cambia la definición que vio y aprobó el dueño, y añade texto a cada tool. La salida es más delicada. En 2026-07-28, si una tool declara outputSchema, el servidor debe devolver un structuredContent conforme y el cliente debería validarlo. Si la proyección quita un campo obligatorio, el resultado deja de cumplir su propio esquema y un cliente estricto lo puede rechazar. El gateway tendría que reescribir también el outputSchema o marcar los campos como opcionales, y el artículo no explica cómo lo resuelven. Por otro lado, el modelo tiene que acertar con las rutas antes de ver la respuesta. Si pide de menos, necesitará otra llamada.

Nada de esto quita valor al diseño. La frase final del artículo, “the hardest part isn’t the AI”, resume la lección de fondo: lo difícil es el tejido que lo conecta todo, es decir, el descubrimiento, la seguridad y la fiabilidad. Si estás montando una plataforma MCP interna, el temario del nivel Experto recorre exactamente esas piezas sobre el caso de Nortia. El nivel Avanzado cubre el diseño de cada servidor que pondrás detrás.