Stdio frente a SSE: 2,1 ms contra 19,4 ms por llamada de herramienta en MCP
Un benchmark de 10.000 ejecuciones mide latencia y memoria de los dos transportes del Model Context Protocol y da un veredicto según el tipo de despliegue.
El Model Context Protocol mueve las llamadas a herramientas entre un agente y su servidor de dos maneras: por tubería (stdio) o por SSE sobre HTTP. Un benchmark de 10.000 ejecuciones pone cifras a la diferencia. La latencia media por invocación es de 2,1 ms con stdio y de 19,4 ms con SSE remoto sobre HTTP/1.1 con TLS. Nueve veces más. En el percentil 99 la brecha se ensancha hasta 6,2 ms frente a 48,7 ms.
El dato importa cuando el agente encadena consultas. Un agente que triage un repositorio o inspecciona un clúster lanza diez o quince llamadas seguidas, y ahí el coste de serialización y transporte deja de ser ruido: se acumula. Con SSE y un p99 de 48,7 ms, esas quince llamadas se van a más de 700 ms solo en transporte, sin contar la generación de tokens.
Los números
El percentil 95 va en la misma dirección: 3,8 ms con stdio y 32,1 ms con SSE. Donde más se nota el diseño es en el establecimiento de conexión. La tubería stdio es persistente y no cuesta nada; SSE paga 45 ms de handshake TCP más TLS cada vez que hay que levantar la conexión.
El consumo de memoria depende del runtime del servidor. Un worker de Node.js por stdio ronda los 32 MB de RSS por proceso activo. Con Python y FastMCP baja a unos 21 MB, y un binario compilado en Go o Rust se queda por debajo de 7 MB. Un daemon SSE centralizado ocupa unos 42 MB, pero los comparte entre todos los flujos de clientes que entren.
Dónde encaja cada uno
El veredicto de quien firma el benchmark es que, para estación de trabajo y agentes de escritorio, stdio gana sin discusión: invocaciones por debajo de 3 ms, ningún puerto de red abierto y sandboxing supervisado por el sistema operativo. En entornos multi-inquilino, donde varios agentes comparten acceso a un clúster o a una base de datos, SSE detrás de un proxy inverso como Envoy o Traefik aporta mTLS y control de tasa, cosas que una tubería local no puede dar.
Las cifras hay que leerlas con cautela. Son del autor del banco de pruebas, que no publica hardware, versiones ni topología, así que la distancia entre cliente y servidor SSE queda sin acotar: un SSE contra un servicio en otra región no se comporta como uno en la misma. En cómo escalar servidores MCP en producción hay más recetas nativas y comparativas de arquitectura.
Lo que sí se saca en limpio: si el agente corre en la misma máquina que la herramienta, meter red en medio es regalar latencia. La decisión no es cuál de los dos transportes es mejor, sino dónde vive el servidor.
