El Futuro de MCP: Cómo Uber Conecta 1,500 Agentes IA con un Solo Protocolo

Metadata

Duración objetivo: 25-35 min
Tipo: Concepto + análisis (estilo Harness Engineering)
Keywords principales: futuro de MCP, claude mcp, mcp server, model context protocol, agentes IA producción
Fuentes: David Soria Parra (Anthropic), Uber keynote (AAIF), Google Cloud Tech, Google Next ‘26, ThoughtWorks Radar

[0:00-1:30] HOOK + OPEN LOOPS

Hook — Variante B adaptada: dolor universal → revelación

MCP. Model Context Protocol.

Si buscas MCP en YouTube, vas a encontrar miles de tutoriales
que te enseñan a conectar Blender, Figma, o tu base de datos
a Claude o a Cursor.

Pero eso es la versión local. La versión de juguete.

Uber tiene 1,500 agentes de IA ejecutándose en producción
— 60,000 tareas por semana —
y todos se conectan a 10,000 servicios internos
a través de un solo protocolo: MCP.

Y no son los únicos.
Anthropic, Google, OpenAI, Microsoft y Amazon
están manteniendo este protocolo juntos.
En la misma mesa. En la misma fundación.
En el mismo repositorio.

Eso no había pasado antes en la historia de la IA.

Open Loops (antes del min 2)

Más adelante vas a ver exactamente cómo Uber convirtió
10,000 servicios internos en MCP servers de forma automática
— sin que cada equipo construyera el suyo.

También vas a ver qué dijo el creador de MCP
sobre por qué convertir una REST API a MCP
uno-a-uno es, en sus palabras, "cringe".

Y al final vamos a ver qué viene en junio
— porque hay 3 features nuevas que van a cambiar
cómo construimos agentes en producción.

[1:30-5:00] CONTEXTO — QUÉ ES MCP HOY

Lo que la mayoría entiende

Primero, nivelemos. Qué es MCP hoy para la mayoría de la gente.

MCP es un protocolo abierto que creó Anthropic a finales de 2024.
La idea es simple: en vez de que cada agente de IA
tenga que aprender a hablar con cada herramienta de forma distinta,
hay un protocolo estándar.

Un MCP server expone herramientas — tools.
Un MCP client — que puede ser Claude Code, Cursor, ChatGPT —
se conecta al server y usa esas herramientas.

Es como USB para agentes de IA.
Antes de USB, cada dispositivo tenía su propio conector.
Después de USB, un solo estándar.

Y funciona. Hoy hay MCP servers para todo:
Slack, Notion, GitHub, bases de datos, Figma, Blender.
110 millones de descargas mensuales.
Para contexto: React, uno de los proyectos open source
más exitosos de la última década,
tardó el doble de tiempo en llegar a esa cifra.

Pero hay un problema

El problema es que casi todo el mundo
está usando MCP en modo local.

Abres Claude Code, conectas un MCP server
que corre en tu máquina, y lo usas tú solo.
Eso está bien para un developer individual.

Pero, ¿qué pasa cuando necesitas que un agente
en producción se conecte a herramientas de verdad?
¿Con autenticación? ¿Con governance?
¿Con 5,000 engineers usándolo al mismo tiempo?

Ahí es donde la historia se pone interesante.

[5:00-10:00] LA TESIS — MCP VA DE LOCAL A PRODUCCIÓN

David Soria Parra — El creador de MCP

En abril de este año, David Soria Parra
— el co-creador de MCP, Lead Maintainer del protocolo,
Member of Technical Staff en Anthropic —
dio una keynote que cambió la conversación.

[CLIP/SLIDE: "The Future of MCP" — AI Engineer]

Su argumento central fue:

2024 fue el año de las demos.
2025 fue el año de los coding agents
— agentes que corren en tu terminal,
que escriben código, que llaman al compilador.
Son el caso ideal: locales, verificables, con sandbox.

Pero 2026, dice Soria Parra, es otra cosa.
2026 es el año de los agentes generales.
Agentes que hacen trabajo real de knowledge workers.
Análisis financiero. Marketing. Operaciones.

Y esos agentes necesitan una cosa
que los coding agents no necesitaban:
conectividad masiva.

Conectarse a 5 aplicaciones SaaS.
A un shared drive.
A servicios internos de la empresa.
Con autenticación.
Con permisos.
Con governance.

El stack de conectividad — 3 capas

Y acá viene lo más importante que dijo Soria Parra.

Si alguien te dice que hay UNA solución
para todos tus problemas de conectividad
— sea MCP, sea computer use, sea CLI —
probablemente está equivocado.

La realidad es que hay 3 capas,
y los mejores agentes de 2026 van a usar las tres:

[DIAGRAMA: 3 capas]

1. SKILLS — Conocimiento de dominio.
   Archivos simples que le dicen al agente
   cómo hacer algo. Reutilizables.
   Es el "qué sabe hacer" del agente.

2. MCP — Conectividad a herramientas.
   Cuando necesitas rich semantics,
   cuando necesitas UI, autorización,
   independencia de plataforma,
   governance enterprise.
   Es el "a qué puede conectarse" el agente.

3. CLI / Computer Use — Ejecución local.
   Cuando tienes sandbox, cuando las herramientas
   están en pre-training (git, gh, gcloud).
   Es el "qué puede ejecutar" el agente.

Si viste mi video de Harness Engineering,
esto te va a sonar familiar.
El harness controla al agente.
Pero el harness necesita conectividad.
Y MCP es esa capa de conectividad.

[10:00-13:00] CUÁNDO USAR CADA COSA

El framework de Google

Ahora, si todavía no te queda claro
cuándo usar MCP vs sub-agents vs A2A vs RAG,
Google Cloud publicó un video que lo resuelve
con un framework muy simple:

[DIAGRAMA: 5 casos]

¿Necesitas info de una librería de contenido?
→ RAG.

¿Necesitas acceso estandarizado a datos?
→ MCP como lookup.

¿Necesitas que el agente haga algo en el mundo real?
→ MCP como acción.

¿Necesitas trabajo en equipo dentro de tu app?
→ Sub-agents.

¿Agentes de distintas organizaciones hablando entre sí?
→ A2A.

No son competidores. Son capas distintas.
Y en un sistema real, usas varias al mismo tiempo.

[13:00-22:00] UBER — LA PRUEBA EN PRODUCCIÓN

Los números

Todo esto suena bien en una keynote.
Pero, ¿alguien ya lo está haciendo de verdad?

Sí. Uber.

[SLIDE: números de Uber]

Meghana Somasundara y Rush Tehrani,
que lideran la plataforma de IA agéntica en Uber,
presentaron su caso esta semana
en el MCP Dev Summit de la Agentic AI Foundation.

Los números:
- 5,000 engineers, 90% usando agentes cada mes
- 10,000+ servicios internos
- 1,500 agentes activos mensuales
- 60,000 ejecuciones por semana

Esto no es un piloto.
Es la nueva forma de trabajar en Uber.

Los 3 problemas que tuvieron

Pero llegar ahí no fue fácil.
Tuvieron tres problemas graves:

Primero: cada equipo construía su propia integración MCP.
Sin estándar, sin framework central.
La mayoría no era reutilizable.
Todos resolviendo los mismos problemas en silos.

Segundo: seguridad.
Con agentes, el blast radius es más alto que con humanos.
Un agente con acceso equivocado puede romper cosas
mucho más rápido que un developer.
Necesitaban visibilidad total de quién accede a qué.

Tercero: discovery.
¿Cómo encuentra un agente el MCP server correcto?
No cualquier MCP — uno que sea confiable,
con buen performance, y seguro.
Porque un tool malo no solo falla:
degrada al agente entero.

Si viste mi video de Agent Skills,
esto es exactamente el mismo problema
pero a escala enterprise.

La solución: MCP Gateway + Registry

Lo que Uber construyó es brutal.

[DIAGRAMA: arquitectura Uber]

Dos componentes:

1. Un ORCHESTRATOR que crawlea los 10,000+
   service definitions internos de Uber
   — archivos proto y thrift —
   y usa un LLM para generar descripciones
   de MCP tools automáticamente.

   Los service owners siguen en control.
   Ellos deciden qué se expone y afinan
   las descripciones para los modelos.

2. Un GATEWAY SERVICE que sirve esos MCP servers
   a todos los consumidores:
   plataforma no-code, SDKs, y coding agents.

Seguridad en cada capa:
- Autorización central integrada
- Redactor automático de datos sensibles (PII)
- Code scanning en cada commit
- Guardrails que bloquean endpoints mutables
  que podrían tirar servicios críticos
- Logging, métricas y tracing completo

Las 3 superficies de consumo

Y lo usan desde 3 superficies distintas:

1. Uber Agent Builder — no-code.
   Miles de agentes internos para productividad.

2. Uber Agent SDK — code-first.
   Los agentes de customer support,
   grocery assistant, care coordination.

3. Coding agents — Claude Code y Cursor.
   95% de los engineers los usan.
   Y tienen "Minions", un background agent
   construido sobre el harness de Claude
   que produce 1,800 cambios de código por semana.

Fíjate: Uber mencionó "Claude harness" explícitamente.
Harness engineering no es un concepto teórico.
Uber lo está usando en producción.

Lo que hacen para que sea confiable

Un detalle que me pareció muy inteligente
de cómo Uber usa MCP:

No dejan que el LLM elija libremente entre todos los tools.
Hacen tres cosas:

1. Scoping — acotan qué tools del MCP server
   están disponibles para cada agente.

2. Tool selection explícita — el desarrollador
   elige los tools específicos, no el LLM.

3. Parameter overrides — ciertos parámetros
   son estáticos, el LLM ni los toca.

Cada una de estas capas reduce un punto de fallo.
Es el mismo principio de agent skills:
no le das acceso a todo,
le das acceso a exactamente lo que necesita.

[22:00-28:00] LO QUE VIENE — EL ROADMAP

Las técnicas que mejoran el harness

Ahora, Soria Parra no solo habló de la visión.
También presentó dos técnicas concretas
que van a mejorar cómo los harnesses
manejan MCP en producción:

PROGRESSIVE DISCOVERY:

Hoy, la mayoría de los clientes MCP
meten todos los tools en el context window.
Y después se sorprenden de que sea enorme.

[SLIDE: antes vs después en Claude Code]

La solución: no cargar todos los tools de entrada.
Darle al modelo un "tool search" —
una herramienta para buscar herramientas.

El modelo dice: "Necesito algo para DNS."
Tool search le devuelve el tool específico.
Se carga on demand.
Reducción masiva de contexto.

De hecho, si usas Claude Code,
ya estás usando esto.
Los deferred tools que ves al inicio
son exactamente este patrón.

Uber también lo tiene en su roadmap.
Lo llaman "omni MCP tool".

PROGRAMMATIC TOOL CALLING:

En vez de que el modelo haga:
tool call → resultado → pensar → otro tool call → resultado...

Le das un REPL — un ambiente de ejecución —
y el modelo escribe código que compone
múltiples tools en una sola llamada.

En vez de 5 roundtrips con latencia,
un script que ejecuta todo junto.

Soria Parra fue muy directo acá:
"We're just not doing this enough yet."

Lo que viene en junio

Y para junio, hay 3 cosas grandes
que van a aterrizar en la especificación de MCP:

1. STATELESS TRANSPORT
   Una propuesta de Google que hace que
   los MCP servers se puedan tratar
   como cualquier servidor stateless.
   Desplegarlo en Cloud Run, en Kubernetes,
   como ya sabemos hacer.
   Eso resuelve el problema de escalar MCP.

2. SERVER DISCOVERY
   URLs well-known para que agentes
   descubran MCP servers automáticamente.
   Como robots.txt pero para agentes.
   Vas a un sitio web y tu agente pregunta:
   "¿Tienes un MCP server?" — y lo encuentra solo.

3. SKILLS OVER MCP
   El MCP server no solo te da tools.
   También te manda el conocimiento de dominio
   de cómo usarlos.
   El server author puede actualizar las skills
   sin depender de registries externos.

Quién gobierna todo esto

Y algo que creo que poca gente sabe:

MCP ya no es "de Anthropic".

Desde diciembre de 2025, MCP está bajo la
Agentic AI Foundation, dentro de la Linux Foundation.

Co-fundadores: Anthropic, Block y OpenAI.
Miembros platinum: Google, Microsoft, Amazon, Cloudflare, GitHub.

Los Core Maintainers del protocolo son:
- David Soria Parra — Anthropic
- Den Delimarsky — Anthropic
- Clare Liguori — AWS
- Caitie McCaffrey — Microsoft
- Nick Cooper — OpenAI
- Kurtis Van Gent — Google Cloud

Anthropic, Google, OpenAI, Microsoft y Amazon
sentados en la misma mesa
definiendo cómo los agentes se conectan al mundo.

ThoughtWorks ya lo puso en su Technology Radar
en la categoría "Trial" — recomendado para probar
en proyectos reales.

Pero con una advertencia:
pusieron "Naive API-to-MCP conversion" en "Hold".
No lo hagas.
Es exactamente lo que Soria Parra llamó "cringe".
No tomes tu REST API y la conviertas 1:1 en MCP.
Diseña para agentes.

[28:00-32:00] CIERRE — Insight conceptual fuerte

Variante A: Insight fuerte

Antes de cerrar, quiero que pienses en algo.

Cada era de la computación tuvo un protocolo
que definió cómo se conectaban las cosas.

HTTP conectó páginas web.
REST conectó aplicaciones.
gRPC conectó microservicios.

MCP está posicionándose para ser
el protocolo que conecte agentes de IA
con el mundo real.

Y lo interesante no es el protocolo en sí.
Es quién está detrás.

Porque cuando Anthropic, Google, OpenAI,
Microsoft y Amazon se sientan juntos
a mantener el mismo estándar,
no es porque les guste colaborar.
Es porque todos entendieron
que sin un estándar de conectividad,
los agentes no llegan a producción.

Uber ya lo demostró.
1,500 agentes. 60,000 tareas por semana.
Un solo protocolo.

Y esto recién empieza.

Si viste mi video de Harness Engineering,
ahí hablamos de cómo controlar al agente.
Skills, guardrails, CLAUDE.md.

MCP es la siguiente pieza:
cómo conectar al agente con el mundo.

Control + conectividad.
Eso es lo que un agente necesita
para funcionar en producción.

Gratitud + teaser

Gracias por quedarse hasta el final.

Todo lo que mencioné en este video
— las fuentes, los links a las keynotes,
los artículos — está en la descripción.

Si te gustó este tipo de análisis,
suscríbete porque vienen cosas entretenidas.

Y si quieres ver estas capas funcionando juntas
en un sistema real — MCP + A2A + Skills
en agentes corriendo en Cloud Run —
eso es exactamente lo que viene
en el próximo video.

Nos vemos.

RECURSOS VISUALES NECESARIOS

Momento	Recurso
Hook	Número 1,500 agentes + 60,000 tasks en pantalla
MCP hoy	Diagrama simple: Client ↔ Server ↔ Tools
3 capas	Diagrama: Skills / MCP / CLI-ComputerUse
Framework Google	Tabla: RAG vs MCP vs Sub-agents vs A2A
Uber arquitectura	Diagrama: Orchestrator + Gateway + 3 superficies
Uber confiabilidad	Diagrama: scoping → tool selection → parameter overrides
Progressive discovery	Antes vs después (context window)
Programmatic tool calling	Diagrama: 5 roundtrips vs 1 script
Roadmap	Timeline: stateless transport, server discovery, skills over MCP
Governance	Logos: Anthropic, Google, OpenAI, Microsoft, AWS + Linux Foundation
Cierre	Timeline: HTTP → REST → gRPC → MCP

TAGS PROPUESTOS

mcp, model context protocol, mcp server, claude mcp, mcp tutorial,
futuro de mcp, future of mcp, mcp produccion, uber mcp, uber ai agents,
david soria parra, anthropic mcp, google adk, a2a protocol,
agent skills, harness engineering, agentes ia, agentes ia produccion,
ai agents, mcp explained, progressive discovery, programmatic tool calling,
agentic ai, mcp gateway, agent connectivity, claude code,
linux foundation mcp, openai mcp, mcp 2026

DESCRIPCIÓN PROPUESTA (ES)

El Futuro de MCP (Model Context Protocol): cómo Uber conecta 1,500 agentes IA
a 10,000 servicios internos con un solo protocolo — 60,000 tareas por semana
en producción real.

David Soria Parra (co-creador de MCP, Anthropic) presentó la visión:
2026 es el año de los agentes generales en producción.
No más demos, no más coding agents locales.
Agentes que se conectan a SaaS, bases de datos y servicios enterprise.

En este video analizo:
- Qué es MCP hoy y por qué la versión "local" no alcanza
- Las 3 capas de conectividad: Skills, MCP, CLI/Computer Use
- Cuándo usar RAG vs MCP vs Sub-agents vs A2A
- Cómo Uber construyó su MCP Gateway + Registry
- Progressive Discovery y Programmatic Tool Calling
- El roadmap: stateless transport, server discovery, skills over MCP
- Quién gobierna MCP: Anthropic, Google, OpenAI, Microsoft y AWS en la misma mesa

Fuentes:
- David Soria Parra keynote (AI Engineer): [LINK]
- Uber keynote (AAIF): [LINK]
- Google Cloud Tech — RAG vs MCP vs A2A: [LINK]
- Google Cloud Next '26 keynote: [LINK]
- ThoughtWorks Technology Radar — MCP: [LINK]
- Martin Fowler — Context Engineering: [LINK]

Mis videos relacionados:
- Harness Engineering: [LINK video harness]
- Agent Skills: [LINK video skills]
- 7 Agentes ADK + A2A: [LINK video ADK]

🔔 Suscríbete: https://www.youtube.com/@NicolasNeiraGarcia?sub_confirmation=1