Descubre cómo viajan los datos entre el Client y el Server: STDIO para uso local, HTTP para la web y SSE para streaming en tiempo real.
En MCP, el transporte es la capa que define como Client y Server se comunican físicamente: por qué canal viajan los datos. El protocolo MCP en sí es independiente del transporte: define el formato de los mensajes (el «qué»), pero no impone cómo llegan esos mensajes a su destino (el «cómo»). Esto significa que el mismo server puede funcionar mediante distintos medios de comunicación sin necesidad de cambiar su lógica interna.
Piensa en el transporte como el medio de envío de un mensaje. Puedes enviar la misma carta por correo postal, por correo electrónico o leerla por teléfono: el contenido del mensaje es idéntico, pero el canal cambia. En MCP, el mensaje JSON-RPC es siempre el mismo, pero puede viajar por STDIO (dentro de la misma máquina), HTTP (por la red) o SSE (streaming por la red). El server no necesita saber qué transporte se está usando: solo procesa los mensajes que llegan.
MCP admite oficialmente tres transportes: STDIO, HTTP y SSE. Esta separación entre protocolo y transporte es un patrón arquitectónico consolidado: el propio HTTP funciona sobre TCP, pero podría funcionar sobre cualquier protocolo de transporte confiable. Esta independencia es lo que permite que MCP sea tan flexible: funciona tanto en un script local en tu máquina como en un servidor en la nube que atiende a miles de clientes simultáneamente.
El transporte STDIO (Standard Input/Output) es el más simple y directo de los tres. En este modo, el Client y el Server se ejecutan en la la misma máquina, y la comunicación ocurre a través de los canales estándar de entrada y salida del proceso: el famoso stdin y stdout. El Client inicia el Server como un proceso hijo y envía mensajes por el stdin del proceso. El Server responde por stdout. Sin red, sin puertos, sin configuración HTTP: solo dos procesos que se comunican directamente.
En STDIO, el Client inicia (inicia) el Server como un proceso hijo en el sistema operativo. La comunicación fluye a través de los pipes estándar: el Client escribe en el stdin del Server y lee del stdout del Server. Cada mensaje es una línea JSON-RPC terminada en un salto de línea. Es el transporte más rápido porque no hay sobrecarga de red: los datos pasan directamente por la memoria del sistema operativo. Es ideal para herramientas locales como el acceso a archivos, la ejecución de comandos y la integración con IDEs.
STDIO es perfecto para desarrollo local y herramientas que se ejecutan en tu computadora. Si tu servidor MCP accede a archivos locales, ejecuta scripts o interactúa con programas instalados en la máquina, STDIO es la opción natural. También es la más fácil de depurar: puedes ver literalmente los mensajes que se intercambian en la terminal.
El transporte HTTP permite que Client y Server estén en máquinas diferentes, comunicándose a través de la red. El Server expone endpoints HTTP y el Client envía solicitudes estándar (POST) que contienen mensajes JSON-RPC. Es el transporte ideal para servers remotos, API en la nube y situaciones en las que se necesita acceder al server desde varios clients simultáneamente.
En el transporte HTTP, el Server MCP se ejecuta como un servicio web que escucha en un puerto (ej.: puerto 3000). El Client envía mensajes JSON-RPC como cuerpo de las solicitudes POST para el endpoint del servidor. El servidor procesa la solicitud y devuelve la respuesta en el cuerpo de la respuesta HTTP. Es el mismo modelo familiar de cualquier API REST, pero en lugar de tener varios endpoints, todos los mensajes MCP pasan por un único endpoint, con el tipo de operación definido dentro del JSON-RPC.
El Client prepara un mensaje JSON-RPC (por ejemplo, para llamar a una tool) y lo envía como cuerpo de una solicitud POST HTTP al endpoint del Server.
El Server recibe la solicitud, deserializa el JSON-RPC, identifica el método solicitado y ejecuta la lógica correspondiente.
El Server prepara la respuesta JSON-RPC con el resultado (o el error) y la envía al Client en el cuerpo de la respuesta HTTP.
HTTP es el protocolo más usado en la web, lo que hace que el transporte HTTP de MCP nativamente compatible con toda la infraestructura existente: balanceadores de carga, proxies inversos, firewalls, certificados TLS y herramientas de monitoreo. Los servers MCP sobre HTTP pueden implementarse en cualquier plataforma de nube (AWS, GCP, Azure) y escalarse horizontalmente usando las mismas técnicas que se usan para cualquier API web tradicional.
O SSE (Server-Sent Events) es una extensión de HTTP que permite transmisión unidireccional del Server al Client. En lugar de que el Client envíe una solicitud y espere la respuesta completa, el Server abre un canal persistente y envía datos continuamente a medida que están disponibles. En MCP, esto es ideal para operaciones largas, como procesar un archivo grande o ejecutar una consulta que demora, en las que el Client necesita recibir actualizaciones de progreso en tiempo real.
Con SSE, el Server puede enviar datos al Client sin que el Client tenga que estar preguntando (sondeo). El Client realiza una sola solicitud HTTP y la conexión permanece abierta. El Server envía eventos por el canal cuando hay datos nuevos. En el contexto de MCP, esto permite que el server envíe notificaciones de progreso, resultados parciales y actualizaciones de estado en tiempo real. El Client usa POST para enviar mensajes al Server y el Server usa el canal SSE para enviar respuestas y notificaciones de vuelta.
Usa SSE cuando tu server MCP necesite enviar actualizaciones en tiempo real al cliente; por ejemplo, el progreso del procesamiento de archivos, los logs de ejecución en vivo o los resultados que llegan gradualmente. SSE es compatible de forma nativa con los navegadores y funciona con la infraestructura HTTP existente, sin necesidad de WebSocket.
Cada transporte tiene sus ventajas y desventajas. La elección depende del escenario: dónde se ejecuta el server, a cuántos clients debe atender, si se necesita streaming y qué nivel de complejidad es aceptable. Entender las diferencias es fundamental para tomar la decisión correcta al implementar tu server MCP.
| Criterio | STDIO | HTTP | SSE |
|---|---|---|---|
| Ubicación | La misma máquina | Cualquier lugar | Cualquier lugar |
| Velocidad | Muy rápido | Rápido | Rápido |
| Complejidad | Mínima | Moderada | Moderada |
| Streaming | No | No | Sí |
| Multi-client | No | Sí | Sí |
| Caso ideal | Desarrollo local, IDEs | APIs en la nube | Tiempo real |
Actualmente, STDIO se usa en aproximadamente el 70% de los servers MCP en producción, precisamente por ser el más sencillo de implementar y probar. HTTP aparece en cerca del 25% de los casos, principalmente en servers desplegados en la nube. SSE todavía es el menos adoptado (~5%), pero su participación crece a medida que más aplicaciones requieren streaming y feedback en tiempo real. La tendencia es que HTTP y SSE ganen terreno a medida que el ecosistema madura y más servers migran a entornos remotos.
En la práctica, elegir el transporte se reduce a responder algunas preguntas sencillas: ¿dónde se ejecutará el server? ¿Cuántos clientes necesitan conectarse? ¿Se necesita streaming? Si tienes dudas, la regla de oro es: comienza con STDIO. Es el más fácil de configurar, probar y depurar. Cuando necesites acceso remoto, migra a HTTP. Cuando necesites streaming, agrega SSE.
Guía de decisión para elegir el transporte:
Empieza siempre con STDIO — es el más fácil de probar y depurar. Puedes tener un server funcionando en minutos, sin configurar puertos, URLs ni certificados. Cuando estés conforme con la lógica del server, migrar a HTTP o SSE solo requiere cambiar la capa de transporte; todo el código del server permanece igual. Esa es la ventaja de separar protocolo y transporte en MCP.
No compliques las cosas al principio. Un error común entre principiantes es querer usar HTTP o SSE cuando STDIO resuelve perfectamente el problema. Configurar el transporte de red agrega complejidad innecesaria en las etapas iniciales: puertos, CORS, autenticación, TLS, firewalls. Enfócate primero en la lógica de tu server — tools, resources, prompts — y solo después preocúpate por el transporte de producción. Optimiza cuando exista una necesidad real, no por anticipado.
Siguiente Ruta: Ruta 2 - Entorno de desarrollo