Stdio vs. HTTP Transmitible para MCP: Qué cambia al pasar del desarrollo local a la implementación empresarial

Stdio está bien para el portátil del desarrollador. HTTP Transmitible es lo que realmente necesitan las implementaciones empresariales. Analizamos ambos transportes —formato de cable, ciclo de vida de la conexión, autenticación, auditoría y comparativas— y mostramos qué cambia cuando un entorno MCP escala más allá de un solo usuario.

Una tarde de viernes en Northwind. Seis meses después de implementar Cargo Copilot, el jefe de seguridad de Northwind le hace al equipo de ingeniería una pregunta de auditoría rutinaria: ¿qué desarrolladores utilizaron la herramienta interna de MCP de datos de clientes en los últimos 30 días y con qué ID de cliente? El equipo tiene cada mensaje JSON-RPC que alguna vez pasó por esas herramientas, dentro de los registros de stderr del proceso local de Cursor de cada desarrollador. Repartidos en cincuenta portátiles. Sin una fuente de marca de tiempo compartida, sin esquema y sin forma de correlacionar. La pregunta tarda una semana en responderse, y la respuesta es parcial. La causa no es la negligencia. Es la elección de transporte que hicieron hace seis meses.

Northwind comenzó donde la mayoría de los equipos comienzan: servidores MCP stdio, uno por máquina de desarrollador. Ese es el valor predeterminado correcto para la experimentación local, y el incorrecto para todo lo demás. Esta publicación explica por qué, con los detalles de los formatos de cable, los modelos de implementación y la ruta de migración.

1. Transporte Stdio: Cómo funciona JSON-RPC 2.0 a través de stdin/stdout

La especificación de transporte MCP define stdio en un párrafo: el cliente inicia el servidor como un subproceso; el servidor lee JSON-RPC 2.0 mensajes de stdin y escribe las respuestas en stdout. Cada mensaje es una línea de texto UTF-8 terminada por un salto de línea. El servidor puede escribir registros en stderr; NO DEBE escribir nada en stdout que no sea un mensaje MCP válido.

Una sola llamada de herramienta del agente al servidor es una línea de JSON:

Wire format — newline-delimited JSON-RPC over stdio
# stdin (client → server)
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_issues","arguments":{"query":"is:open label:critical"}}}

# stdout (server → client)
{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"Found 3 issues..."}]}}

Las reglas de enmarcado son simples pero implacables. La especificación MCP requiere que los mensajes estén en una sola línea, por lo que los servidores compatibles escapan cualquier carácter de nueva línea interno como \n durante la serialización JSON. Lo que realmente rompe el enmarcado en producción es la contaminación de stdout con contenido que no es JSON: una sentencia print() extraviada, un rastreo de excepción no capturada, un registro de depuración accidentalmente dirigido a stdout en lugar de stderr, o un servidor que olvida vaciar stdout después de cada mensaje. En todos estos casos, el cliente ve un mensaje mal formado o espera indefinidamente una respuesta que técnicamente ya ha sido escrita. Cada SDK de MCP incluye una implementación de transporte stdio precisamente para que estos casos extremos sean problema de otra persona.

Lo que stdio te ofrece a cambio de esas restricciones es el aislamiento de procesos. El agente es dueño del ciclo de vida del servidor: cuando el agente sale, el sistema operativo recupera el proceso. No hay red, no hay apretón de manos de autenticación, no hay preguntas de firewall. Para el desarrollo local, esto es exactamente lo que se busca.

2. Transporte HTTP Transmitible: Modos de Solicitud-Respuesta y SSE

HTTP Transmitible, introducido en la especificación MCP 2025-03-26 y mantenido en la revisión de noviembre de 2025, reemplaza el transporte HTTP+SSE anterior con un diseño de un solo punto final. El servidor expone una URL (por ejemplo, /mcp) que acepta tanto POST y GET. Los clientes envían mensajes JSON-RPC mediante POST; los servidores responden con un único cuerpo JSON o actualizan a un flujo de eventos enviados por el servidor (Server-Sent Events) para llamadas de larga duración. No existe un punto final "events" separado.

El cliente indica lo que puede aceptar; el servidor elige el modo de respuesta. A continuación, se muestra una llamada a una herramienta en formato HTTP:

Wire format — Streamable HTTP, both response modes
POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
Mcp-Session-Id: 1d3f...e7c2
Authorization: Bearer eyJhbGciOi...

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_issues",...}}

# --- Server response: short call returns plain JSON ---
HTTP/1.1 200 OK
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"result":{"content":[...]}}

# --- Server response: long call upgrades to SSE ---
HTTP/1.1 200 OK
Content-Type: text/event-stream

event: message
data: {"jsonrpc":"2.0","method":"notifications/progress","params":{...}}

event: message
data: {"jsonrpc":"2.0","id":1,"result":{"content":[...]}}

Tres detalles son importantes a nivel operativo. El Mcp-Session-Id encabezado vincula las solicitudes a una sesión y es asignado por el servidor durante la inicialización — persiste a través de los reinicios de los pods solo si el servidor externaliza el estado de la sesión. El Accept encabezado es obligatorio: según la especificación, los clientes DEBEN listar tanto application/json como text/event-stream, y un servidor compatible puede rechazar un encabezado faltante o incompleto Accept con HTTP 406 Not Acceptable (según la semántica HTTP; 415 Tipo de medio no compatible se aplica a tipos incompatibles Content-Type, no Accept). Y según la sección de seguridad de la especificación, los servidores DEBEN validar el Origin en cada conexión para evitar ataques de reencuadernación de DNS contra servidores vinculados localmente — un requisito normativo, no una recomendación, con el código HTTP 403 Prohibido como la respuesta prescrita a un Origin no válido.

3. Ciclo de vida de la conexión: Proceso por usuario vs HTTP sin estado

Los dos transportes modelan las conexiones de forma completamente diferente, y aquí es donde se abre la brecha operativa.

Para un único desarrollador que trabaja localmente, el modelo de proceso por conexión de stdio es una característica, no un error — el aislamiento de procesos es gratuito, y el arranque en frío ocurre una vez cuando se abre el IDE. En el momento en que más de un usuario necesita el servidor, ese modelo se convierte en la limitación.

4. Multitenencia: Por qué Stdio encuentra un límite a escala

La limitación de stdio que falla a nivel empresarial es más aritmética que de ingeniería: las implementaciones típicas de MCP de stdio ejecutan un proceso por tupla (usuario, servidor), sin compartir recursos entre usuarios de forma integrada. Algunas implementaciones multiplexan múltiples definiciones de herramientas dentro de un subproceso, y algunas agrupan subprocesos, pero el patrón de despliegue común en la práctica —y el que se incluye en los SDK oficiales— es un proceso por usuario por servidor.

En Northwind, 50 desarrolladores ejecutan cada uno un IDE con ocho servidores MCP conectados. Esto representa 400 procesos stdio durante las horas pico, distribuidos en 50 portátiles. Cada proceso ocupa memoria (un servidor MCP de Python con algunas dependencias consume entre 60 y 120 MB de RAM; un servidor Node es similar), mantiene descriptores de archivo abiertos y un tiempo de ejecución activo bloqueado en stdin. La huella de recursos agregada no es catastrófica —400 procesos pequeños están bien dentro del presupuesto del hardware moderno— pero el costo real es operativo más que computacional: el recuento de procesos fragmenta el plano de control.

El problema más difícil son los servidores de estado compartido. Imagina que el servidor MCP interno de la API de Logística almacena en caché un grafo de clientes de 200 MB en memoria al inicio. Con stdio, la máquina de cada desarrollador carga su propia copia. Con Streamable HTTP, dos réplicas de pod mantienen el grafo para toda la empresa. Los mismos datos, dos órdenes de magnitud menos de memoria en total, además la caché está activa para todos los usuarios porque es compartida.

Vale la pena mencionar la otra cara de la moneda. El modelo descentralizado de Stdio tiene ventajas reales que un equipo de infraestructura sénior citará con razón: un fuerte aislamiento de fallos (el servidor caído de un desarrollador no afecta a nadie más), ninguna dependencia de entrada compartida, ninguna interrupción de autenticación centralizada que arrastre a todo el sistema, y una infraestructura mínima para operar. Para equipos pequeños, flujos de trabajo locales de alta confianza o entornos aislados (air-gapped), esas propiedades pueden superar genuinamente los beneficios operativos de una capa HTTP centralizada. El argumento en esta publicación no es que stdio sea malo; es que los modos de fallo que impone a la organización —auditoría fragmentada, credenciales distribuidas, sin limitación de velocidad centralizada— aparecen exactamente cuando un sistema pasa de "unos pocos usuarios avanzados" a "infraestructura compartida con obligaciones de cumplimiento".

‍

‍