En la clase anterior vimos qué es un MCP y para qué sirve. Hoy, en la segunda clase del curso gratis «Programar con IA desde cero» de Control Z, abrimos el capó: vamos a ver cómo se hablan un cliente y un servidor MCP, paso a paso, con los mensajes reales que se intercambian. No hace falta que memorices nada; la idea es que, cuando algo falle, sepas dónde mirar.

Aquí tienes el vídeo de la clase y, debajo, la explicación por escrito.

Repaso rápido

MCP (Model Context Protocol) es un estándar abierto para conectar aplicaciones de IA con datos y herramientas. Hay tres participantes:

• Host: la aplicación de IA (un editor, un chat de escritorio, tu agente).
• Cliente: el componente del host que mantiene la conexión con un servidor.
• Servidor: el programa que ofrece herramientas, recursos y prompts.

Hoy nos centramos en la conversación entre cliente y servidor.

El idioma: JSON-RPC 2.0

Cliente y servidor no se inventan su formato: según la documentación oficial, MCP usa JSON-RPC 2.0. Es un formato sencillo basado en JSON con tres tipos de mensaje:

• Petición (request): lleva un id, un method (qué quieres hacer) y unos params.
• Respuesta (response): lleva el mismo id que la petición y un result o un error.
• Notificación: como una petición, pero sin id, porque no espera respuesta.

Con estas tres piezas se construye toda la conversación. Veamos sus tres momentos clave.

1. Inicialización: presentarse y ponerse de acuerdo

Lo primero que hace el cliente al conectarse es enviar una petición initialize. En ella dice qué versión del protocolo usa, qué capacidades tiene y quién es. Simplificado, se parece a esto:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": { "name": "mi-cliente", "version": "1.0.0" }
  }
}

El servidor responde con su versión, su nombre y sus capacidades; por ejemplo, que ofrece herramientas. Si las versiones no son compatibles, aquí es donde se detecta. Después, el cliente envía la notificación notifications/initialized para decir «listo, empezamos».

La versión del protocolo cambia con el tiempo. Usa la que indique la especificación vigente en modelcontextprotocol.io o la que gestione tu SDK.

2. Descubrir herramientas: tools/list

Ahora el cliente necesita saber qué puede hacer el servidor. Para eso envía tools/list:

{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

El servidor devuelve la lista de herramientas. Cada una tiene un nombre, una descripción y un esquema de entrada (inputSchema, en JSON Schema) que indica qué parámetros acepta:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "buscar_tareas",
        "description": "Busca tareas por texto",
        "inputSchema": {
          "type": "object",
          "properties": { "texto": { "type": "string" } },
          "required": ["texto"]
        }
      }
    ]
  }
}

La descripción es muy importante: es lo que lee el modelo para decidir cuándo usar la herramienta. Una descripción vaga hace que el modelo la use mal o no la use.

3. Llamar a una herramienta: tools/call

Cuando el modelo decide usar una herramienta, el host la llama a través del cliente con tools/call, indicando el nombre y los argumentos:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "buscar_tareas",
    "arguments": { "texto": "pagos" }
  }
}

El servidor ejecuta la acción y devuelve el resultado en un campo content, que normalmente es una lista de bloques, por ejemplo de texto:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [{ "type": "text", "text": "2 tareas encontradas: ..." }]
  }
}

Ese contenido vuelve al modelo, que lo usa para responderte. Y el ciclo se repite tantas veces como haga falta.

El transporte: por dónde viajan los mensajes

Los mensajes JSON-RPC tienen que viajar por algún sitio. La documentación oficial define dos transportes:

stdio (entrada y salida estándar)

El host arranca el servidor como un proceso en tu propio ordenador y se comunican por la entrada y la salida estándar. Es rápido, sencillo y no usa red. Es lo típico para servidores locales, como uno que lee tus archivos.

Streamable HTTP

El servidor funciona como un servicio web: el cliente envía los mensajes con peticiones HTTP POST y el servidor puede responder en streaming usando Server-Sent Events. Es lo que se usa para servidores remotos y permite autenticación estándar, como tokens o OAuth.

Lo bonito es que los mensajes son los mismos en ambos casos: solo cambia el «cable».

Errores habituales

Cuando empiezas a trabajar con MCP, hay fallos que se repiten mucho. Estos son algunos de los más comunes y dónde mirar:

• Escribir logs en la salida estándar con stdio. Si tu servidor imprime mensajes de depuración por stdout, se mezclan con el JSON-RPC y rompen la comunicación. Escribe los logs en stderr o en un archivo.
• Rutas o comandos incorrectos en la configuración. Si el host no encuentra el ejecutable, el servidor ni siquiera arranca. Comprueba la ruta y prueba el comando a mano.
• Argumentos que no cumplen el esquema. Si falta un parámetro obligatorio o tiene otro tipo, la llamada falla. Revisa el inputSchema.
• Descripciones pobres. Si el modelo no usa tu herramienta, mejora el nombre y la descripción.
• Versiones incompatibles. Si la inicialización falla, revisa la versión del protocolo y actualiza el SDK.

Para depurar, la documentación oficial recomienda el MCP Inspector, una herramienta para conectarte a un servidor y probar sus herramientas a mano.

Resumen

• Cliente y servidor MCP hablan JSON-RPC 2.0: peticiones, respuestas y notificaciones.
• La conversación empieza con initialize y la notificación notifications/initialized.
• El cliente descubre las herramientas con tools/list y las ejecuta con tools/call.
• Los mensajes viajan por stdio (local) o Streamable HTTP (remoto).
• Los errores típicos son logs en stdout, rutas mal puestas, argumentos fuera de esquema y descripciones vagas.

Siguiente clase

En la clase 3 damos un paso atrás para entender una pieza básica que aparece por todas partes, también dentro de muchos servidores MCP: las API.

👉 Siguiente capítulo: Qué es una API y por qué sirve (con ejemplos reales) (se publica el 30/10/2026 a las 18:00; revisa el enlace antes de publicar).

👈 Capítulo anterior: Qué es un MCP y para qué sirve

¿Te ha servido?

Si quieres seguir aprendiendo a programar con IA en español, suscríbete a Control Z en YouTube y activa la campanita para no perderte las próximas clases.