Raft analiza dónde MCP y Thin MCP añaden latencia innecesaria a los agentes de IA

MCP se presenta a menudo como una forma universal de conectar herramientas a una aplicación LLM de manera ordenada, pero en la práctica esa modularidad se paga con latencia. En un nuevo análisis, Raft comparó varias arquitecturas y mostró que el problema normalmente no está en un componente concreto, sino en cómo está diseñado todo el recorrido de la petición, desde el agente hasta la herramienta y de vuelta.

De dónde sale la latencia

El autor empezó con una pregunta básica: ¿cuánta latencia añade MCP por sí solo si se elimina la red y todo se queda en un único proceso? Para averiguarlo, comparó un monolito sin MCP con un monolito con MCP in-process. El patrón resultó tener un overhead relativamente pequeño: de media unos 10–11 ms, y en ocasiones hasta 35 ms. Es un punto de partida importante: si un agente se frena cientos de milisegundos, lo normal es que el culpable no sea el uso de MCP en sí, sino la capa externa que lo rodea.

La comparación pasó después a una arquitectura más realista, en la que los servidores MCP se ejecutan en contenedores Docker separados. Aquí el panorama cambia de forma notable: la latencia adicional media de las herramientas principales subió hasta unos 169 ms por llamada. Aun así, las trazas mostraron que ni siquiera eso es lo que más tiempo consume. Los tramos más pesados son la obtención de embeddings y el trabajo del reranker, mientras que la búsqueda en la base de datos vectorial tarda comparativamente poco. Dicho de otro modo, MCP añade un coste, pero no siempre es el principal cuello de botella de la cadena.

Qué mostraron las pruebas

El artículo examina varios escenarios para separar la influencia del transporte, la serialización y el propio runtime.

• S1, MCP in-process: unos 10–11 ms de latencia adicional, es decir, el runtime en sí es relativamente ligero.
• S2, MCP separados a través de la red de Docker: de media unos 169 ms de overhead por llamada, debido a la red, la serialización y la comunicación entre procesos.
• S3a, Thin MCP mediante HTTP + JSON: en una serie de mediciones el overhead bajó hasta unos 128 ms, pero el resultado fue inestable y en ejecuciones repetidas podía ser notablemente peor.
• S3b, Thin MCP mediante HTTP + YAML: la latencia subió hasta unos 274 ms, lo que apunta al coste añadido de la serialización y la deserialización.
• S4 y S5: ZeroMQ dio unos 200 ms, pero con un comportamiento más predecible, mientras que un runtime en C++ redujo el overhead a unos 130–145 ms, sin un cambio radical en el orden de magnitud.

La principal conclusión de estas cifras es que las optimizaciones intuitivas no siempre funcionan como se espera. Sustituir JSON por YAML no aceleró el sistema, sino que lo empeoró. Pasar de HTTP a IPC tampoco supuso una victoria automática: la implementación con iceoryx2 no mostró la mejora esperada, y solo la variante con ZeroMQ resultó más útil en la práctica, gracias a su modelo asíncrono. Incluso C++ ayudó de forma moderada, no dramática.

Por qué thin no salva la situación

En el artículo, Thin MCP no aparece como un botón mágico de aceleración, sino como una forma de simplificar la arquitectura. En este esquema la capa proxy se mantiene mínima y solo traduce las llamadas, mientras que la lógica de negocio pasa a servicios HTTP independientes. Este enfoque ofrece independencia de lenguaje, simplifica el escalado y permite escribir ejecutores en Go, Rust o C++, aunque todavía no exista un SDK de MCP completo para ellos.

Thin MCP es más una herramienta arquitectónica que una forma de

optimizar la latencia.

Hay un matiz práctico: el enfoque thin puede parecer más rápido en una ejecución y no reproducirse de forma estable en otra. Para un sistema en producción esto es crítico: a veces importa más un comportamiento predecible bajo carga repetida que el mejor p95 puntual. Por eso Raft extrae una conclusión bastante dura pero útil: si de verdad se quiere acelerar un agente de IA, no basta con cambiar de lenguaje o de protocolo. Hay que rehacer el esquema de interacción entre el proxy, los componentes de backend y los pasos de cómputo pesado.

Qué significa esto

Para los equipos que construyen agentes de IA, es un buen antídoto contra la optimización superficial. Si un sistema es lento, primero hay que mirar el número de saltos entre componentes, las operaciones bloqueantes, el modelo de ejecución concurrente y las etapas pesadas como los embeddings y el reranking. Thin MCP puede hacer el sistema más limpio y flexible, y C++ o IPC pueden aportar una mejora adicional, pero el efecto decisivo aparece solo cuando la arquitectura deja de hacer pasar la petición por capas innecesarias.