MCP Gateway de Uber: qué enseña sobre agentes de IA en empresa

Cuando un agente de inteligencia artificial deja de ser una demo y empieza a consultar datos internos, llamar a servicios o ejecutar acciones, el problema cambia. Ya no basta con que el modelo responda bien: hay que decidir qué puede hacer, con qué sistemas, bajo qué permisos y con qué trazabilidad.

Uber acaba de publicar un caso especialmente útil para entender ese salto. Su plataforma MCP centraliza actualmente más de 800 servidores MCP y más de 5.000 herramientas, conectando agentes con servicios internos ya existentes. La escala de Uber es excepcional, pero las decisiones de arquitectura que describe son relevantes mucho antes de llegar a esos números.

Diagrama de arquitectura del MCP Gateway publicado por Uber Engineering. Fuente original.

El problema aparece cuando cada equipo conecta sus agentes por su cuenta

MCP, siglas de Model Context Protocol, permite que una aplicación de IA utilice herramientas y fuentes externas mediante una interfaz común. En pequeño, la idea es sencilla: un agente puede disponer de una herramienta para consultar una base de datos, buscar documentación, crear una incidencia o llamar a una API.

El problema surge cuando esa lógica se multiplica.

Uber explica que sus primeras integraciones se construyeron de forma bastante independiente. Funcionaban, pero empezaron a aparecer los síntomas habituales de una adopción descentralizada: infraestructura duplicada, herramientas difíciles de descubrir, integraciones acopladas a servicios concretos y criterios diferentes para operar y proteger cada conexión.

Su respuesta no fue crear otro agente más potente, sino crear una capa común entre los agentes y los sistemas de la empresa.

Ese matiz importa. La dificultad ya no estaba principalmente en el modelo de IA, sino en la infraestructura que permitía al modelo actuar sobre sistemas reales.

Qué hace realmente el MCP Gateway de Uber

La arquitectura se apoya en dos grandes piezas.

Por un lado, el MCP Registry funciona como plano de control: mantiene el catálogo de servidores, herramientas, esquemas, propietarios y estado de habilitación.

Por otro, el Proxy Gateway actúa como plano de datos: recibe las llamadas MCP de los agentes, resuelve qué herramienta debe ejecutarse y traduce la petición hacia el protocolo que utiliza el servicio interno correspondiente.

Esto permite que un agente trabaje con una interfaz MCP uniforme aunque por debajo existan servicios HTTP, gRPC o TChannel.

La consecuencia práctica es importante: no hace falta reescribir todo el backend para hacerlo accesible a agentes.

1. Reutilizar APIs existentes antes que reconstruir sistemas

Uber opera con miles de servicios internos. Pedir a cada equipo que escribiera manualmente un servidor MCP específico habría creado otra capa de trabajo y mantenimiento.

Para evitarlo creó AutoCrawler, un sistema que recorre su registro interno de interfaces, detecta servicios y APIs, extrae sus métodos y esquemas y genera las representaciones necesarias para registrarlas como herramientas MCP.

En servicios definidos con Protobuf o Thrift, el proceso puede derivar automáticamente métodos, entradas, salidas y documentación. Uber indica además que utiliza un LLM para enriquecer las descripciones de las herramientas y hacerlas más comprensibles para los agentes.

La lección no es que todas las empresas necesiten construir un AutoCrawler. Es más sencilla: antes de crear una infraestructura nueva para IA, conviene revisar qué sistemas, APIs y procesos ya existen y pueden reutilizarse.

La IA empresarial madura no sustituye necesariamente la arquitectura anterior. Muchas veces la conecta de una forma nueva.

2. Descubrir una herramienta no significa autorizar su uso

Esta es probablemente la decisión más relevante del diseño.

Las herramientas que AutoCrawler descubre o genera se registran desactivadas por defecto. El equipo propietario del servicio debe revisarlas y habilitarlas expresamente antes de que puedan utilizarse.

Además, los cambios en la descripción o configuración generan una diferencia que debe aprobar el propietario y que puede revertirse a una versión anterior.

Es una decisión poco espectacular, pero muy importante: automatizar el descubrimiento no equivale a automatizar el permiso.

Cuando un agente puede pasar de leer información a ejecutar acciones, esta separación se vuelve esencial. El criterio debería ser parecido al de cualquier otro sistema empresarial: acceso mínimo necesario, responsable identificado y cambios controlados.

Si una organización está empezando con IA, esta idea es más útil que muchas demostraciones de agentes autónomos.

3. Seguridad y gobierno no pueden depender de cada agente

Uber concentra en el gateway funciones que, si se implementaran de manera independiente en cada integración, serían difíciles de mantener de forma coherente.

Entre ellas aparecen autorización a nivel de herramienta, políticas diferentes según quién realiza la llamada —personas, servicios o agentes—, limitación de uso y redacción automática de información personal o sensible en las respuestas.

El resultado es un principio arquitectónico claro: el agente no debería ser quien decida por sí solo qué puede hacer.

El modelo puede razonar sobre una tarea, pero los límites de acceso deben estar fuera del modelo y controlados por la infraestructura.

Esto conecta directamente con una regla práctica para cualquier empresa: antes de conectar un asistente a documentos, CRM, correo, ERP o sistemas internos, hay que definir qué información puede consultar y qué operaciones puede ejecutar.

En ARCIORA ya hemos tratado una versión más básica de este problema al explicar qué datos no conviene compartir con un chat de IA. Con agentes, la cuestión da un paso más: no solo importa qué datos entran en el modelo, sino también qué capacidad de acción recibe el sistema.

4. Cinco mil herramientas también pueden ser demasiadas

Tener muchas herramientas disponibles parece una ventaja hasta que todas compiten por el contexto del modelo.

Uber identifica este problema al escalar a cientos de servidores. MCP no incorpora de forma nativa una búsqueda global entre servidores: normalmente el cliente tiene que saber de antemano con cuál conectarse y qué herramientas ofrece.

Cargar miles de definiciones en el contexto sería caro e ineficiente.

Su solución es Omni MCP, un servidor proxy que permite un descubrimiento progresivo. El agente puede primero localizar el servidor adecuado, después descubrir sus herramientas, solicitar el esquema de una concreta y finalmente invocarla.

Es decir, el modelo recibe solo el contexto que necesita en cada momento.

Uber complementa este enfoque con Response Projection, que permite pedir únicamente determinados campos de una respuesta, y con un modo de trabajo para agentes de programación que escribe resultados en archivos para que el agente cargue después únicamente las partes necesarias.

La idea general es sencilla: más herramientas no significan automáticamente más capacidad. Sin una estrategia de descubrimiento y selección, también significan más ruido, más tokens y más coste.

Qué puede aprender una pyme sin construir la infraestructura de Uber

Una pyme no necesita 800 servidores MCP para beneficiarse de estas decisiones. De hecho, copiar la arquitectura completa sería absurdo en la mayoría de los casos.

Lo transferible son los principios.

Antes de desplegar un agente conectado a sistemas reales conviene poder responder cinco preguntas:

1. ¿Qué sistemas puede consultar? No «todo lo que tengamos», sino fuentes concretas.
2. ¿Qué acciones puede ejecutar? Leer un pedido no es lo mismo que modificarlo, aprobar un gasto o enviar un correo.
3. ¿Quién autoriza cada capacidad? Debe existir un responsable humano o de sistema.
4. ¿Qué información necesita realmente el modelo? Cuanto menos contexto innecesario, menor coste y menor superficie de exposición.
5. ¿Cómo sabremos qué hizo? Las acciones relevantes necesitan registro, observabilidad y posibilidad de revisión.

Para organizaciones que aún están comenzando, el paso anterior sigue siendo elegir bien el problema. Por eso tiene sentido empezar por una prueba pequeña y medible de IA en la empresa antes de plantear agentes con capacidad operativa.

Lo que este caso no demuestra

También conviene evitar la conclusión contraria.

Que Uber necesite un gateway centralizado no significa que todas las empresas necesiten montar una plataforma MCP propia. Su arquitectura responde a una organización con miles de servicios y cientos de equipos.

Tampoco demuestra que MCP sea la única forma correcta de conectar agentes con sistemas empresariales.

El valor del caso está en otra parte: muestra qué problemas aparecen cuando los agentes dejan de ser experimentos aislados y pasan a formar parte de una infraestructura productiva.

En ese momento, la pregunta deja de ser «¿qué modelo es mejor?» y empieza a parecerse a preguntas de ingeniería y gestión bastante conocidas: quién tiene acceso, quién es propietario, cómo se aprueba un cambio, qué se registra, qué datos circulan y cómo se limita el impacto de un error.

En resumen

• Uber ha centralizado el acceso de sus agentes mediante un MCP Gateway que aloja más de 800 servidores y 5.000 herramientas.
• Las APIs existentes pueden transformarse en herramientas para agentes sin rehacer los servicios internos.
• Las herramientas se registran desactivadas por defecto y requieren aprobación del equipo propietario.
• Seguridad, permisos, redacción de datos sensibles y observabilidad se aplican desde una capa común.
• Omni MCP evita cargar miles de herramientas en el contexto y permite descubrirlas progresivamente.
• La lección para empresas más pequeñas no es copiar la escala de Uber, sino adoptar desde el principio límites, responsables y control.

Cuando los agentes empiezan a actuar sobre sistemas reales, la calidad del modelo sigue importando. Pero deja de ser suficiente.

La IA empresarial termina necesitando algo bastante menos novedoso y bastante más importante: arquitectura, seguridad y gobierno.

Fuente principal: Uber Engineering — “Designing MCP Gateway: Uber’s MCP Management Platform”, publicado el 1 de octubre de 2026.