El transporte STDIO

Los clientes y servidores MCP se comunican intercambiando mensajes JSON, pero ¿cómo se transmiten realmente estos mensajes? El canal de comunicación utilizado se llama transporte, y hay varias formas de implementarlo, desde solicitudes HTTP hasta WebSockets e incluso escribir JSON en una postal (aunque esta última no se recomienda para uso en producción).

Cuando estás desarrollando por primera vez un servidor o cliente MCP, el transporte más comúnmente utilizado es el transporte stdio. Este enfoque es sencillo: el cliente lanza el servidor MCP como un subproceso y se comunica a través de los flujos estándar de entrada y salida.

Diagrama del transporte stdio: un cliente MCP envía mensajes a un servidor MCP a través del stdin del servidor, y el servidor envía mensajes de vuelta a través de stdout; cualquiera de las partes puede enviar un mensaje en cualquier momento, y solo funciona cuando ambos se ejecutan en la misma máquina

Así es como funciona:

El cliente envía mensajes al servidor usando el stdin del servidor
El servidor responde escribiendo en stdout
Tanto el servidor como el cliente pueden enviar un mensaje en cualquier momento
Solo funciona cuando el cliente y el servidor se ejecutan en la misma máquina

Viendo Stdio en acción

En realidad puedes probar un servidor MCP directamente desde tu terminal sin escribir un cliente separado. Cuando ejecutas un servidor con uv run server.py, este escucha stdin y escribe las respuestas en stdout. Esto significa que puedes pegar mensajes JSON directamente en tu terminal y ver las respuestas del servidor de inmediato.

La salida de la terminal muestra el intercambio completo de mensajes, incluyendo mensajes de ejemplo para la inicialización y las llamadas a herramientas.

Secuencia de conexión MCP

Toda conexión MCP debe comenzar con un handshake específico de tres mensajes:

Diagrama de secuencia del handshake de MCP: el cliente envía una Initialize Request al servidor, el servidor responde con un Initialize Result, luego el cliente envía una Initialized Notification para la cual no llega ningún resultado de vuelta

Initialize Request - El cliente envía esto primero
Initialize Result - El servidor responde con sus capacidades
Initialized Notification - El cliente confirma (no se espera respuesta)

Solo después de este handshake puedes enviar otras solicitudes como llamadas a herramientas o listados de prompts.

Tipos de mensajes y flujo

MCP admite varios tipos de mensajes que fluyen en ambas direcciones:

Gráfico de los tipos de mensajes MCP entre cliente y servidor: pares de solicitud/resultado iniciados por el cliente como Call Tool Request → Call Tool Result, pares iniciados por el servidor como Create Message Request y List Roots Request, además de notificaciones unidireccionales de cada lado que no requieren respuesta

La idea clave es que algunos mensajes requieren respuestas (solicitudes → resultados) mientras que otros no (notificaciones). Tanto el cliente como el servidor pueden iniciar la comunicación en cualquier momento.

Cuatro escenarios de comunicación

Con cualquier transporte, necesitas manejar cuatro patrones de comunicación diferentes:

Diagrama titulado "¿Cómo podemos implementar cada uno de estos con stdio?" que enumera cuatro patrones: solicitud inicial del cliente al servidor, respuesta del servidor al cliente, solicitud inicial del servidor al cliente y respuesta del cliente al servidor, junto a un cliente MCP conectado al stdin y stdout de un servidor MCP

Solicitud Cliente → Servidor: El cliente escribe en stdin
Respuesta Servidor → Cliente: El servidor escribe en stdout
Solicitud Servidor → Cliente: El servidor escribe en stdout
Respuesta Cliente → Servidor: El cliente escribe en stdin

La belleza del transporte stdio es su simplicidad: cualquiera de las partes puede iniciar la comunicación en cualquier momento usando estos dos canales.

Por qué esto importa

Comprender el transporte stdio es crucial porque representa el caso "ideal" en el que la comunicación bidireccional es fluida. Cuando pasemos a otros transportes como HTTP, nos encontraremos con limitaciones en las que el servidor no siempre puede iniciar solicitudes hacia el cliente. El transporte stdio sirve como nuestra línea base para entender cómo se ve la comunicación MCP completa antes de abordar las restricciones de otros métodos de transporte.

Para el desarrollo y las pruebas, el transporte stdio es perfecto. Para implementaciones en producción donde el cliente y el servidor necesitan ejecutarse en máquinas diferentes, deberás considerar otras opciones de transporte con sus propias ventajas y desventajas.