MCP: El USB-C del AI

Descripción de la cápsula

Ya conoces el problema M×N — cada AI host necesita integraciones custom con cada servicio. Ahora vas a conocer la solución: Model Context Protocol (MCP), un protocolo abierto que estandariza cómo AI hosts se conectan con servicios externos. MCP reduce el problema M×N a M+N, exactamente como USB-C redujo la explosión de conectores en hardware.

En esta cápsula vas a entender qué es MCP, cómo funciona a alto nivel, y por qué la analogía USB-C es más que una metáfora — es el mismo patrón de estandarización aplicado a un dominio diferente. Al terminar, podrás explicar MCP a cualquier colega developer en menos de un minuto.

La analogía USB-C: de M×N a M+N

Antes de USB-C (el problema)

En 2010, cada fabricante tenía su propio conector:

Apple:
├── iPhone      → Lightning
├── MacBook     → MagSafe
└── iPad (old)  → 30-pin connector

Samsung:
├── Galaxy      → Micro-USB
└── Tablets     → Micro-USB 3.0

Otros:
├── Nokia       → Conector propietario (DC-4)
├── Sony        → Conector propietario
├── Laptops     → Barrel jack (diferente por marca)
└── Cámaras     → Mini-USB

Resultado: Un cajón lleno de cables. 5 dispositivos = 5 cables diferentes. Y si tu amigo tiene un Samsung y tú un iPhone, no podían compartir cargador.

Eso es M×N: M dispositivos × N tipos de conector.

Después de USB-C (la solución)

Apple:
├── iPhone 15+  → USB-C ✅
├── MacBook     → USB-C ✅
└── iPad        → USB-C ✅

Samsung:
├── Galaxy      → USB-C ✅
└── Tablets     → USB-C ✅

Todos los demás:
├── Laptops     → USB-C ✅
├── Cámaras     → USB-C ✅
├── Headphones  → USB-C ✅
└── Nintendo    → USB-C ✅

Resultado: Un solo cable funciona con todo. Tu cargador carga cualquier dispositivo. Tu cable transfiere datos de cualquier fuente.

Eso es M+N: Cada dispositivo implementa USB-C (M implementaciones) y cada accesorio soporta USB-C (N implementaciones). Total: M + N, no M × N.

Mapeando USB-C a MCP

La clave: Así como USB-C define un estándar que cualquier dispositivo y accesorio pueden implementar, MCP define un estándar que cualquier AI host y servicio pueden implementar.

¿Qué es MCP exactamente?

Definición en una oración

MCP (Model Context Protocol) es un protocolo abierto que estandariza cómo las aplicaciones de AI se conectan con fuentes de datos y herramientas externas.

Definición expandida

MCP define:

1. Cómo un AI host descubre qué puede hacer un servicio (capabilities discovery)
2. Cómo se comunican AI host y servicio (protocolo de mensajes)
3. Qué tipos de cosas puede exponer un servicio (3 primitivas: Resources, Tools, Prompts)
4. Cómo se manejan permisos y seguridad

Piensa en MCP como un contrato:

Contrato MCP:

"Si eres un AI host (Claude Code, Cursor, etc.):
 → Implementa un MCP Client
 → Podrás conectarte con CUALQUIER MCP Server

Si eres un servicio (GitHub, PostgreSQL, etc.):
 → Implementa un MCP Server
 → CUALQUIER AI host con MCP Client podrá usarte

Ambos lados hablan el mismo protocolo.
No necesitan conocerse de antemano."

Cómo MCP resuelve el problema M×N

Sin MCP: integraciones específicas

Claude Code ←[custom A]→ GitHub
Claude Code ←[custom B]→ PostgreSQL
Claude Code ←[custom C]→ Slack
Cursor      ←[custom D]→ GitHub      ← Diferente de A
Cursor      ←[custom E]→ PostgreSQL  ← Diferente de B
Cursor      ←[custom F]→ Slack       ← Diferente de C

Total: 6 integraciones custom (3 hosts × 2... o M × N)

Con MCP: protocolo estándar

Claude Code ←[MCP Client]→ MCP Protocol ←[MCP Server]→ GitHub
                                         ←[MCP Server]→ PostgreSQL
                                         ←[MCP Server]→ Slack
Cursor      ←[MCP Client]→ MCP Protocol ←[mismos MCP Servers]→
Windsurf    ←[MCP Client]→ MCP Protocol ←[mismos MCP Servers]→

Implementaciones:
- 3 MCP Clients (uno por AI host)
- 3 MCP Servers (uno por servicio)
Total: 3 + 3 = 6 (vs 3 × 3 = 9 sin MCP)

La magia: Los MCP Servers de GitHub, PostgreSQL, y Slack funcionan con cualquier AI host que tenga un MCP Client. No necesitan saber si es Claude Code, Cursor, o Windsurf.

Los 3 roles en MCP

1. MCP Host

El Host es la aplicación de AI que el usuario utiliza directamente.

Ejemplos de Hosts:
├── Claude Code (CLI de Anthropic)
├── Cursor (IDE con AI)
├── Windsurf (IDE de Codeium)
├── Claude Desktop (app de escritorio)
└── Zed (editor con MCP support)

Responsabilidades del Host:

• Presenta la interfaz al usuario
• Decide cuándo usar MCP servers
• Maneja permisos y seguridad
• Puede conectarse a múltiples MCP servers simultáneamente

2. MCP Client

El Client es el componente dentro del Host que habla el protocolo MCP.

Claude Code (Host)
└── MCP Client (componente interno)
    ├── Conecta con MCP Server de GitHub
    ├── Conecta con MCP Server de PostgreSQL
    └── Conecta con MCP Server de Slack

Responsabilidades del Client:

• Establece conexión con MCP Servers
• Descubre qué puede hacer cada Server (capabilities)
• Envía requests y recibe responses
• Maneja el lifecycle de la conexión

Nota: Como developer, normalmente no construyes el Client — ya viene implementado en el Host (Claude Code, Cursor, etc.). Tú construyes Servers.

3. MCP Server

El Server es tu código — el programa que expone capabilities al Host via MCP.

Tu MCP Server (ejemplo: database server)
├── Resources: datos que el modelo puede leer
│   └── "database://users" → lista de usuarios
├── Tools: funciones que el modelo puede ejecutar
│   └── "create_user(name, email)" → crea usuario
└── Prompts: templates reutilizables
    └── "analyze_schema(table)" → template de análisis

Responsabilidades del Server:

• Expone capabilities (Resources, Tools, Prompts)
• Responde a requests del Client
• Ejecuta operaciones (queries, API calls, etc.)
• Maneja errores y retorna resultados

Esto es lo que vas a construir en esta guía.

MCP en acción: ejemplos completos

Veamos cómo funciona un flujo completo con MCP en dos escenarios diferentes:

Escenario 1: "¿Cuántos usuarios tiene mi database?"

1. Usuario en Claude Code:
   "¿Cuántos usuarios hay en la database?"

2. Claude Code (Host) procesa:
   → Identifica que tiene un MCP Server de database conectado
   → El Server expone un tool "count_records(table)"
   → Decide usar ese tool

3. MCP Client envía request:
   → Tool call: count_records(table="users")
   → Via protocolo MCP estándar

4. MCP Server (tu código) recibe:
   → Ejecuta: SELECT COUNT(*) FROM users
   → Resultado: 1,247

5. MCP Server responde:
   → { "count": 1247 }
   → Via protocolo MCP estándar

6. Claude Code presenta al usuario:
   "Hay 1,247 usuarios en la database."

Todo este flujo usa el protocolo MCP estándar. El mismo MCP Server funcionaría con Cursor, Windsurf, o cualquier otro host que soporte MCP.

Escenario 2: "Crea un ticket con el bug que acabo de encontrar"

Este escenario muestra un flujo más complejo donde Claude Code usa múltiples MCP servers en una sola interacción:

1. Usuario en Claude Code:
   "Encontré un bug en el endpoint /api/users que retorna 500
    cuando el email es null. Crea un ticket en Linear y
    notifica al equipo en Slack."

2. Claude Code (Host) procesa:
   → Identifica que tiene MCP Servers de Linear y Slack conectados
   → Planifica usar ambos tools secuencialmente

3. MCP Client envía primer request a Linear Server:
   → Tool call: create_issue(
       title="Bug: /api/users returns 500 when email is null",
       description="...",
       priority="high",
       labels=["bug", "api"]
     )

4. Linear MCP Server recibe y ejecuta:
   → Crea el ticket via Linear API
   → Retorna: { "issue_id": "BUG-234", "url": "..." }

5. MCP Client envía segundo request a Slack Server:
   → Tool call: send_message(
       channel="#engineering",
       text="🐛 Nuevo bug reportado: BUG-234 - /api/users
             returns 500 when email is null. Priority: High"
     )

6. Slack MCP Server recibe y ejecuta:
   → Envía mensaje via Slack API
   → Retorna: { "sent": true, "channel": "#engineering" }

7. Claude Code presenta al usuario:
   "Listo. Creé el ticket BUG-234 en Linear con prioridad alta
    y notifiqué al equipo en #engineering en Slack."

Esto demuestra la composabilidad de MCP — múltiples servers trabajando juntos en un solo flujo, cada uno manejando su dominio. Claude Code orquesta la secuencia porque entiende el protocolo estándar de ambos servers.

Fíjate en algo importante: en ningún momento tuviste que decirle a Claude Code "usa el Linear server y luego el Slack server." Solo describiste lo que querías lograr. Claude Code, al conocer las capabilities de cada server (gracias al discovery del protocolo MCP), decide qué tools usar y en qué orden. Esa es la diferencia entre una integración mecánica y un flujo inteligente.

Lo que no viste pero pasó

En ambos escenarios, hay pasos que MCP manejó automáticamente detrás de escena:

1. Discovery: Cuando Claude Code arrancó, contactó cada MCP server y le preguntó "¿qué puedes hacer?" Cada server respondió con su lista de capabilities (tools, resources, prompts).
2. Selección: Cuando recibió tu petición, Claude Code evaluó qué tools disponibles eran relevantes y eligió los correctos.
3. Serialización: Los argumentos del tool call se serializaron en formato estándar (JSON) y se enviaron al server.
4. Respuesta: El server procesó la petición y retornó resultados en formato estándar.
5. Presentación: Claude Code interpretó los resultados y los presentó en lenguaje natural.

Todo esto pasó en milisegundos. Vas a ver estos pasos en detalle en el módulo 2.

Qué hace MCP diferente de otras soluciones

MCP vs Plugins de ChatGPT

ChatGPT Plugins:
- ❌ Solo funcionan con ChatGPT
- ❌ Propietarios de OpenAI
- ❌ Sin acceso a sistema local
- ❌ Limitados a HTTP
- ❌ Descontinuados/reemplazados por GPTs

MCP:
- ✅ Funciona con cualquier host que lo implemente
- ✅ Protocolo abierto (cualquiera puede implementar)
- ✅ Acceso a sistema local (stdio transport)
- ✅ Múltiples transports (stdio, HTTP/SSE)
- ✅ Activamente desarrollado y adoptado

MCP vs API REST directa

API REST directa:
- ✅ Estándar bien establecido
- ❌ No define descubrimiento de capabilities
- ❌ No define cómo AI hosts deben interactuar
- ❌ Cada host necesita lógica custom para cada API

MCP:
- ✅ Define descubrimiento de capabilities
- ✅ Define interacción AI host ↔ servicio
- ✅ Un server funciona con todos los hosts
- ✅ Puede usar REST bajo el hood

MCP vs Function Calling (OpenAI)

Function Calling:
- ✅ Permite al modelo invocar funciones
- ❌ Solo define el modelo's side
- ❌ No estandariza el server side
- ❌ Propietario de cada vendor

MCP:
- ✅ Estandariza ambos lados (host + server)
- ✅ Incluye Resources y Prompts además de Tools
- ✅ Protocolo completo de lifecycle
- ✅ Open source y vendor-neutral

Principios de diseño de MCP

MCP no fue diseñado al azar. Hay principios de diseño claros que explican por qué el protocolo está estructurado como está:

1. Protocolo abierto

MCP es open source. La especificación, los SDKs, y los servers de referencia están disponibles públicamente. Cualquiera puede implementar un Host, Client, o Server sin pedir permiso ni pagar licencias.

¿Por qué importa? Los protocolos propietarios crean lock-in. Si los plugins de ChatGPT fueran abiertos, otros hosts podrían haberlos adoptado y hoy tendríamos un estándar unificado en lugar de ecosistemas fragmentados. MCP evita ese error desde el diseño: al ser abierto, la adopción no tiene fricciones legales ni comerciales.

2. Vendor-neutral

No pertenece a una empresa. Aunque Anthropic lo creó, el protocolo es abierto y cualquier AI host puede adoptarlo — y lo están haciendo (Cursor, Windsurf, Zed, Continue.dev, etc.). Anthropic no cobra por MCP ni tiene control exclusivo sobre su evolución.

¿Por qué importa? Si MCP fuera propiedad exclusiva de Anthropic, Cursor y Windsurf no lo habrían adoptado — ¿por qué fortalecer el ecosistema de tu competidor? Al ser vendor-neutral, todos ganan: los hosts obtienen un ecosistema de servers gratis, y los servers obtienen alcance en todos los hosts.

3. Composable

Un Host puede conectarse a múltiples Servers simultáneamente. Puedes tener un Server de GitHub, otro de PostgreSQL, y otro de Slack, todos funcionando al mismo tiempo en Claude Code. Cada server opera independientemente.

¿Por qué importa? La composabilidad permite flujos de trabajo complejos. El escenario 2 de arriba — crear ticket en Linear y notificar en Slack — solo es posible porque los servers son independientes y composables. No necesitas un "super server" que haga todo; combinas servers especializados como piezas de LEGO.

4. Transport-agnostic

MCP puede funcionar sobre diferentes mecanismos de transporte:

• stdio: Para servers locales (el más común con Claude Code). El server se ejecuta como un proceso hijo y se comunica via standard input/output.
• HTTP/SSE: Para servers remotos. Comunicación via HTTP con Server-Sent Events para mensajes del server al client.
• Streamable HTTP: Para comunicación bidireccional eficiente en escenarios que necesitan streaming.

¿Por qué importa? Diferentes contextos requieren diferentes transports. Un developer usando Claude Code en su laptop quiere servers locales rápidos (stdio). Una empresa quiere servers centralizados accesibles desde múltiples máquinas (HTTP). MCP soporta ambos sin cambiar la lógica del server.

5. Progressive capability

Un Server puede exponer tan poco o tanto como quiera. Un Server mínimo puede tener 1 tool. Un Server complejo puede tener docenas de resources, tools, y prompts. No hay requisitos mínimos artificiales.

¿Por qué importa? La barrera de entrada baja es crítica para adopción. Si crear un MCP server requiriera implementar 20 capabilities mínimas, pocos lo harían. Con progressive capability, puedes empezar con un server que solo tiene un tool (query_database) y agregar más capabilities a medida que necesites. Tu primer server puede ser funcional en 30 líneas de código.

Limitaciones de MCP

MCP es poderoso, pero no es una solución universal. Es importante entender qué no resuelve para tener expectativas correctas:

Lo que MCP no resuelve

1. Autenticación con servicios externos

MCP define cómo tu AI host se comunica con tu MCP server, pero no define cómo tu MCP server se autentica con el servicio externo (GitHub, Slack, PostgreSQL, etc.). Tú sigues necesitando manejar API keys, OAuth tokens, connection strings, etc. dentro de tu server.

MCP define:     Host ←→ Tu MCP Server (protocolo estándar)
Tú defines:     Tu MCP Server ←→ Servicio externo (autenticación, etc.)

2. Calidad de las respuestas del modelo

MCP le da al modelo acceso a datos y herramientas, pero no garantiza que el modelo tome las decisiones correctas sobre cuándo y cómo usarlas. Si el modelo decide no usar un tool disponible o lo usa con argumentos incorrectos, eso es un tema del modelo, no del protocolo.

3. Performance del servicio subyacente

Si tu database tarda 30 segundos en responder una query, el MCP server va a tardar al menos 30 segundos. MCP no optimiza la velocidad del servicio subyacente — es una capa de comunicación, no un acelerador.

4. Seguridad end-to-end automática

MCP tiene mecanismos de seguridad (el host pide confirmación para operaciones sensibles, los servers definen qué directorios/recursos pueden acceder), pero la seguridad end-to-end depende de cómo implementes tu server. Un server mal escrito que expone DELETE FROM users como tool sin confirmación es un problema de implementación, no del protocolo.

5. Offline o desconexiones complejas

MCP asume una conexión activa entre host y server. No tiene un modelo robusto de offline-first, caché de resultados, o reconexión automática con estado. Si la conexión se pierde, la sesión se resetea.

Qué sí resuelve MCP (resumen)

Para contexto, veamos la lista completa de lo que MCP sí hace bien:

✅ Descubrimiento de capabilities (el host sabe qué puede hacer el server)
✅ Interfaz estándar (un server funciona con todos los hosts)
✅ Composabilidad (múltiples servers funcionando juntos)
✅ Ecosistema compartido (reutilizar servers de la comunidad)
✅ Progressive capability (empezar simple, crecer después)
✅ Transport-agnostic (local via stdio, remoto via HTTP)
✅ Open source y vendor-neutral (sin lock-in)

Troubleshooting

"¿MCP reemplaza las APIs REST?"

No. MCP es una capa encima de las APIs. Tu MCP Server puede internamente llamar APIs REST, conectarse a databases, leer archivos, o hacer lo que necesite. MCP estandariza cómo el AI host descubre y usa las capabilities de tu Server — no reemplaza lo que hace internamente. Piensa en MCP como un "adaptador universal" entre AI hosts y cualquier servicio.

"¿Necesito TypeScript o Python para crear MCP Servers?"

Los SDKs oficiales están en TypeScript y Python, que son los caminos más fáciles. Pero MCP es un protocolo — cualquier lenguaje que pueda manejar JSON y stdio/HTTP puede implementar un Server. Hay implementaciones community en Go, Rust, Java, C#, y otros. Los SDKs simplemente facilitan el proceso, pero no son requisito absoluto.

"¿Qué pasa si un AI host no soporta MCP?"

Entonces no puede conectarse con MCP Servers. Pero la tendencia es clara: cada vez más hosts adoptan MCP. Si tu herramienta de AI favorita no lo soporta hoy, probablemente lo soportará pronto. Los principales (Claude Code, Cursor, Windsurf, Zed, Continue.dev) ya lo soportan.

"¿MCP agrega latencia a las operaciones?"

Sí, hay un overhead mínimo por la comunicación via protocolo (serialización JSON, comunicación stdio/HTTP). En la práctica, este overhead es negligible comparado con el tiempo de las operaciones reales (queries a database, API calls). Estamos hablando de milisegundos de overhead vs segundos de operación real. Solo en escenarios de ultra-baja latencia sería un factor relevante.

"¿Puedo usar MCP sin Claude Code?"

Absolutamente. MCP funciona con cualquier host que lo implemente. Puedes usar MCP servers con Cursor, Windsurf, Zed, Continue.dev, y más. El protocolo es independiente del host. En esta guía usamos Claude Code como host principal porque es el que más experiencia tienes, pero lo que construyas funcionará en todos.

Ejercicios

Ejercicio 1: Explicar MCP en una oración (Fácil)

Escribe tu propia definición de MCP en una oración, sin usar jerga técnica. Imagina que se la explicas a un product manager.

Ejercicio 2: Mapear la analogía USB-C (Fácil)

Completa esta tabla mapeando cada concepto USB-C a su equivalente MCP:

Ejercicio 3: Identificar Host, Client, Server (Medio)

En este escenario, identifica qué es el Host, qué es el Client, y qué es el Server:

"Un developer usa Cursor para escribir código. Cursor está conectado a un programa que puede leer y buscar en la documentación de React. El developer pregunta '¿cómo se usa useEffect?' y Cursor usa ese programa para buscar la respuesta en los docs de React."

Ejercicio 4: Diseñar un MCP Server conceptual (Medio)

Si fueras a construir un MCP Server para tu servicio favorito (Notion, Spotify, tu database del trabajo), ¿qué capabilities expondría? Lista al menos:

• 2 Resources (datos que el modelo puede leer)
• 2 Tools (funciones que el modelo puede ejecutar)
• 1 Prompt (template reutilizable)

Ejercicio 5: Argumentar MCP vs custom integrations (Difícil)

Tu CTO dice: "Podemos construir integraciones custom directamente. ¿Por qué complicarnos con MCP?" Escribe 3 argumentos a favor de MCP sobre integraciones custom.

Ejercicio 6: Identificar limitaciones (Medio)

Lee la sección "Limitaciones de MCP" de esta cápsula. Ahora, para cada limitación, describe cómo la manejarías en la práctica si estuvieras construyendo un MCP server para PostgreSQL.

# Ejemplo de cómo pasaría credenciales al server
MCP_PG_CONNECTION_STRING=postgresql://user:pass@localhost/mydb

Resumen

En esta cápsula aprendiste:

• MCP es el USB-C del AI — un protocolo estándar que reduce M×N integraciones a M+N implementaciones
• 3 roles: Host (aplicación AI), Client (componente de comunicación), Server (tu código)
• MCP define: Descubrimiento de capabilities, protocolo de comunicación, tipos de capabilities (Resources, Tools, Prompts), y permisos
• MCP vs alternativas: Es abierto (vs plugins propietarios), estandariza ambos lados (vs function calling), y es una capa arriba de APIs (vs REST directo)
• 5 principios: Abierto, vendor-neutral, composable, transport-agnostic, progressive capability
• Limitaciones: MCP no resuelve autenticación con servicios externos, performance del servicio subyacente, ni seguridad end-to-end automática
• Lo que construirás: MCP Servers — el código que expone capabilities a cualquier AI host

Próxima cápsula: El ecosistema MCP actual — quién usa MCP hoy, qué servers existen, y cómo está creciendo la adopción.

Recursos adicionales

1. Model Context Protocol — Specification - Especificación técnica completa
2. MCP Architecture Overview - Documentación oficial de arquitectura
3. Introducing MCP (Anthropic Blog) - Anuncio oficial con contexto de diseño
4. MCP GitHub Organization - Repos oficiales: spec, SDKs, servers de referencia
5. USB-C Specification - La analogía real: cómo un estándar unificó hardware
6. Awesome MCP Servers - Directorio community de MCP servers