Raft Analizó Dónde MCP y Thin MCP Añaden Latencia a Agentes de IA

MCP se presenta frecuentemente como una forma universal de conectar herramientas de manera limpia a aplicaciones LLM, pero en la práctica esa modularidad tiene un costo de latencia. En un nuevo análisis, Raft comparó varias arquitecturas y mostró que el problema generalmente no reside en un componente específico, sino en cómo se estructura en general la ruta de solicitud del agente a la herramienta y viceversa.

Dónde nace la latencia

El autor comenzó con una pregunta básica: cuánta latencia añade MCP en sí mismo si eliminas la red y mantienes todo en un solo proceso. Para hacerlo, compararon un monolito sin MCP y un monolito con MCP in-process. Resultó que el patrón en sí añade una sobrecarga relativamente pequeña — alrededor de 10–11 ms en promedio, a veces hasta 35 ms. Este es un punto de referencia importante: si un agente se ralentiza por cientos de milisegundos, el culpable suele no ser el uso de MCP en sí, sino la capa externa a su alrededor.

Luego, trasladaron la comparación a una arquitectura más realista, donde los servidores MCP se implementan en contenedores Docker separados. Aquí la situación cambia notablemente: la latencia adicional media para herramientas principales creció hasta alrededor de 169 ms por llamada. Mientras tanto, los trazos mostraron que ni siquiera esto es el principal consumidor de tiempo. Las partes más pesadas son la obtención de embeddings y el trabajo de reranker, mientras que la búsqueda en base de datos vectorial lleva relativamente poco. En otras palabras, MCP añade un costo, pero no siempre se convierte en el principal cuello de botella de toda la cadena.

Lo que revelaron las pruebas

El artículo analiza varios escenarios para separar los efectos del transporte, serialización y tiempo de ejecución en sí.

• S1, MCP in-process: alrededor de 10–11 ms de latencia adicional, lo que significa que el tiempo de ejecución en sí es relativamente ligero.
• S2, MCP separado a través de la red Docker: alrededor de 169 ms de sobrecarga por llamada en promedio debido a la red, serialización y comunicación entre procesos.
• S3a, Thin MCP por HTTP + JSON: en una serie de mediciones, la sobrecarga bajó a alrededor de 128 ms, pero el resultado resultó ser inestable y podría ser notablemente peor en ejecuciones repetidas.
• S3b, Thin MCP por HTTP + YAML: la latencia aumentó a alrededor de 274 ms, lo que indica un costo adicional de serialización y deserialización.
• S4 y S5: ZeroMQ produjo alrededor de 200 ms, pero con comportamiento más predecible, mientras que el tiempo de ejecución C++ redujo la sobrecarga a alrededor de 130–145 ms sin un cambio radical en magnitud.

La conclusión principal de estos números es que las optimizaciones intuitivas no siempre funcionan como se espera. Reemplazar JSON con YAML no aceleró el sistema, sino que lo empeoró. Cambiar de HTTP a IPC tampoco dio ganancias automáticas: la implementación en iceoryx2 no mostró la mejora esperada, y solo la variante con ZeroMQ resultó ser prácticamente más útil gracias a su modelo asincrónico. Incluso C++ ayudó moderadamente, no dramáticamente.

Por qué thin no salva el día

Thin MCP en el artículo no parece un botón mágico de aceleración, sino una forma de simplificar la arquitectura. En este esquema, la capa proxy permanece mínima y solo traduce llamadas, mientras que la lógica de negocio se traslada a servicios HTTP separados. Este enfoque proporciona independencia del lenguaje, simplifica el escalado y permite escribir ejecutores en Go, Rust o C++, incluso si aún no existe un SDK MCP completo para ellos.

Thin MCP es más una herramienta arquitectónica que un método de

optimización de latencia.

El matiz práctico es que el enfoque thin puede parecer más rápido en una ejecución, pero no reproducirse establemente en otra. Para un sistema en producción, esto es crítico: a veces un comportamiento predecible bajo carga repetida es más importante que un p95 mínimo único. Por eso Raft hace una conclusión bastante severa pero útil: si quieres realmente acelerar un agente de IA, no es solo cambiar el lenguaje o protocolo, sino reconstruir el esquema de interacción entre proxy, componentes backend y pasos computacionales pesados.

Qué significa esto

Para equipos que construyen agentes de IA, esto es un buen antídoto contra la optimización superficial. Si el sistema es lento, primero debe observar el número de transiciones entre componentes, operaciones bloqueantes, el modelo de ejecución concurrente y etapas pesadas como embeddings y reranking. Thin MCP puede hacer un sistema más limpio y flexible, y C++ o IPC pueden proporcionar ganancias adicionales, pero el efecto decisivo aparece solo cuando la arquitectura en sí deja de ejecutar solicitudes a través de capas innecesarias.