MCP: R2-D2 como Servidor y el Protocolo que Conecta Todo

Qué es el Model Context Protocol, las 3 primitivas (tools, resources, prompts), la arquitectura cliente-servidor, y cuándo usar MCP vs. herramientas directas.

El astromech socket: un conector universal para la galaxia

R2-D2 puede conectarse a la computadora central de la Estrella de la Muerte. También a los sistemas del Halcón Milenario. Y a los paneles de la base rebelde en Yavin. Y a la red de la ciudad de las nubes en Bespin. Y a casi cualquier sistema que aparece en las películas.

Todos tienen el mismo conector. El mismo socket. La misma interfaz estándar que acepta a cualquier astromech.

R2-D2 no necesita un adaptador custom para cada nave. No tiene que conocer los protocolos internos de cada sistema. Se conecta, anuncia qué puede hacer, y el sistema que lo recibe elige qué quiere usar.

Ese conector universal es exactamente lo que es MCP — el Model Context Protocol. Un protocolo estándar que permite a cualquier agente de IA conectarse a cualquier servidor y acceder a sus capacidades sin integraciones custom.

Cuando R2-D2 se conecta, expone tres tipos de capacidades. Acciones que puede ejecutar — hackear una puerta, calcular coordenadas de salto, disparar el cable de remolque. Datos que puede proveer — los planos de la Estrella de la Muerte, los mapas estelares. Y secuencias pre-programadas — la instrucción lista para reproducir el mensaje de la Princesa Leia.

En MCP eso se llama tools, resources y prompts. Son las tres primitivas del protocolo. Las vas a ver en el examen sí o sí.

¿Qué es MCP y por qué existe?

Imaginá el universo Star Wars sin el astromech socket estándar. Cada nave tendría su propio conector propietario. R2-D2 funcionaría en naves de la República, pero necesitaría un adaptador especial para las imperiales. Y otro distinto para los sistemas de Jabba. Y otro para la ciudad de las nubes.

Cada integración sería un proyecto en sí mismo. Si R2-D2 cambia algo internamente, todos los adaptadores hay que actualizarlos. Y si querés que BB-8 también se conecte a los mismos sistemas, hay que hacer todos los adaptadores de vuelta.

Eso era exactamente la situación con los agentes de IA antes de MCP. Si querías que tu agente usara una base de datos, necesitabas una integración custom. Si también necesitabas un CRM, otra integración custom distinta. Si lo compartías con otro equipo, ellos tenían que reimplementar todo. No había estándar.

MCP — Model Context Protocol — es el astromech socket. Un protocolo abierto que define cómo los clientes de IA se conectan a servidores que exponen herramientas, datos y templates. Cualquier cliente que hable MCP puede usar cualquier servidor MCP. Una vez. Sin adaptadores custom.

Y es abierto: no es exclusivo de Claude. Otros modelos y frameworks pueden implementar MCP también. Eso hace que el ecosistema de servidores MCP — bases de datos, APIs, sistemas de archivos, servicios web — sea útil para todo el ecosistema de IA.

💡 EXAMEN: MCP resuelve el problema de las integraciones N-a-N. Sin estándar, N agentes conectándose a M sistemas necesitan N×M integraciones. Con MCP, necesitás N clientes y M servidores — la complejidad cae de cuadrática a lineal.

Las 3 primitivas: tools, resources y prompts

Cuando R2-D2 se conecta a un sistema, lo primero que hace es anunciar sus capacidades. Eso es lo que hace un servidor MCP: lista todo lo que puede ofrecer. Y esas capacidades se dividen en exactamente tres categorías.

Tools: acciones con efectos

Las tools son funciones. El cliente las llama, se ejecutan, producen un resultado o un efecto en el mundo. R2-D2 hackeando una puerta es una tool: hay un input (qué puerta), hay una ejecución (la secuencia de hackeo), y hay un resultado (la puerta abierta o un error). Las tools pueden tener efectos secundarios. Pueden cambiar estado. Pueden fallar.

Resources: datos sin efectos

Los resources son endpoints de lectura. El cliente los consulta para obtener información, sin ejecutar ninguna acción. Los planos de la Estrella de la Muerte que R2-D2 lleva en su memoria son un resource: son datos, los podés leer, no los podés 'ejecutar'. La diferencia clave con una tool: un resource no tiene efectos secundarios. Leer los planos no cambia nada en el mundo.

Hay una razón muy práctica para separar tools de resources en el protocolo: las herramientas de validación, logging y seguridad pueden tratarlos diferente. Leer un resource es seguro por definición. Llamar a una tool puede necesitar aprobación o auditoría.

⚠️  TRAMPA CLÁSICA: confundir tools con resources. Si tu 'herramienta' solo devuelve datos sin ejecutar ninguna acción, probablemente es un resource, no una tool. La pregunta: ¿tiene side effects? Si no → resource. Si sí → tool.

Prompts: templates para flujos recurrentes

Los prompts son la primitiva menos conocida. Si tenés un flujo de análisis de código que siempre empieza igual, o un proceso de onboarding que siempre hace las mismas preguntas iniciales, podés exponerlos como prompts en tu servidor MCP. El cliente los descubre, los activa, y el servidor provee el template completo listo para usar.

Arquitectura cliente-servidor de MCP

La arquitectura MCP tiene cuatro componentes. El examen pregunta sobre cada uno.

Los dos tipos de transporte

MCP soporta dos tipos de transporte, y el examen distingue entre ellos.

Stdio: el servidor corre como un proceso local. El cliente se comunica por standard input/output. Es la opción para servidores en la misma máquina — rápido, simple, sin red, sin configuración de puertos. Ideal para desarrollo local y herramientas de escritorio.

HTTP con SSE (Server-Sent Events): el servidor corre como un servicio web. El cliente se conecta por red. Es la opción para servidores remotos o cuando múltiples clientes necesitan acceder al mismo servidor. Ideal para producción y servicios compartidos.

💡 EXAMEN: stdio = desarrollo local / mismo proceso. HTTP/SSE = producción / múltiples clientes / acceso remoto.

MCP vs. herramientas directas: cuándo usar cada uno

El Halcón Milenario tiene sus propios sistemas hardwired. La modificación del punto doce que hizo Han Solo — la que le permite hacer el salto a hipervelocidad en tiempo récord — no funciona en ninguna otra nave. Es una integración custom, específica para ese vehículo.

R2-D2 es lo opuesto. Se conecta a cualquier nave. No es custom. Es estándar.

Las herramientas directas en la API de Anthropic son como las modificaciones del Halcón: las definís para un agente específico, funcionan perfecto para ese agente, pero si otro agente necesita las mismas herramientas, tenés que duplicar la definición. Si la herramienta cambia, tenés que actualizar cada agente que la usa.

Regla práctica: si es solo un agente y la herramienta es muy específica de su función → herramientas directas. Si la herramienta la va a usar más de un agente, si va a escalar, si necesitás centralizar el acceso → MCP.

Demo: servidor R2-D2 con las 3 primitivas

Veamos las tres primitivas implementadas en código. Primero instalás el SDK oficial.

Ahora el servidor — R2-D2 con las 3 primitivas

Y el cliente que descubre y consume las 3 primitivas.

Fijate en el patrón del cliente: primero list_tools / list_resources / list_prompts para descubrir capabilities, después call_tool / read_resource / get_prompt para usarlas. El cliente no sabe cómo R2-D2 implementa nada — solo conoce la interfaz estándar. Eso es la abstracción que MCP provee.

Las 4 trampas del examen sobre MCP

Trampa 1: 'MCP reemplaza las herramientas directas de la API'

FALSO. MCP y las herramientas directas coexisten. MCP es un estándar de comunicación entre clientes y servidores — no reemplaza el mecanismo de tool_use de la API. De hecho, cuando Claude interactúa con un servidor MCP a través del Claude Desktop o el SDK, internamente sigue usando el mecanismo de tool_use. MCP es una capa de abstracción encima, no un reemplazo.

Trampa 2: 'Resources y tools son lo mismo porque ambos devuelven datos'

FALSO. La diferencia es los side effects. Una tool puede cambiar estado, ejecutar acciones, tener efectos en el mundo. Un resource es de solo lectura — no cambia nada. Esa distinción importa para auditoría y seguridad: leer un resource siempre es seguro; llamar a una tool puede requerir validación adicional.

Trampa 3: 'MCP solo funciona con Claude'

FALSO. MCP es un protocolo abierto. Anthropic lo diseñó para ser agnóstico al modelo. Cualquier cliente que implemente el protocolo puede conectarse a cualquier servidor MCP. Eso incluye otros modelos y frameworks de IA. La apertura del protocolo es uno de sus valores centrales.

Trampa 4: 'stdio es inferior a HTTP/SSE — siempre es mejor usar HTTP'

FALSO. Ninguno es superior — son casos de uso distintos. stdio es más simple, más rápido para comunicación local, y no requiere configuración de red. HTTP/SSE es necesario cuando el servidor tiene que ser accesible remotamente o compartido entre múltiples clientes. Elegís según el contexto, no por jerarquía.

Lo que te llevás de M2V2

MCP es el astromech socket del ecosistema de IA: un protocolo estándar que permite a cualquier cliente conectarse a cualquier servidor sin integraciones custom. Las tres primitivas son tools (acciones con side effects), resources (datos de solo lectura), y prompts (templates pre-definidos). La arquitectura es cliente-servidor con dos tipos de transporte: stdio para local y HTTP/SSE para remoto o compartido. Y usás MCP cuando la herramienta va a ser compartida por múltiples agentes o necesitás centralizar el acceso.

El valor real de MCP no es solo técnico — es que convierte el problema de N×M integraciones en N clientes + M servidores. Cada nuevo agente que hablé MCP puede usar todos los servidores existentes sin código adicional.

En M2V3 vamos a ver diseño de herramientas con manejo de errores — cómo hacer que tus tools fallen de forma útil y qué hace el agente cuando recibe un error de una herramienta.