27.257 conexiones MCP medidas: el p90 de una sesión espera 35 segundos

Un desarrollador ha medido durante 35 días cómo se conectan sus servidores MCP y el resultado se lleva por delante la excusa habitual: casi nunca es el código del servidor. Sobre 38.876 intentos de conexión registrados en su propia máquina, 27.257 se completaron y la mediana fue de 582 ms. El problema aparece al mirar la sesión entera: con una media de ocho servidores por sesión, el p90 del tiempo total de conexión se va a 35,5 segundos.

Los datos salen de los ficheros JSONL que Claude Code deja en disco, uno por servidor y sesión, bajo ~/Library/Caches/claude-cli-nodejs/<proyecto>/mcp-logs-<servidor>/. Son 33.599 ficheros, 22 servidores y 2.888 sesiones entre el 13 de agosto y el 16 de septiembre. No es un banco de pruebas: es una máquina de trabajo, con lo que eso tiene de bueno y de malo.

OAuth, no tu servidor

La causa principal no está en el servidor. Si se separan las conexiones según si hubo refresco de token en la misma ventana, las cifras cambian de escala: 748 conexiones con refresco dieron una mediana de 3.170 ms y un p90 de 9.619 ms; 26.509 sin refresco, 550 ms y 3.400 ms. Es 5,8 veces más lento con los mismos servidores, la misma red y la misma máquina. El servidor tarda 550 ms en arrancar mientras la ida y vuelta OAuth se come los otros 2,6 segundos.

Solo el 2,7% de las conexiones pasó por un refresco, pero ese porcentaje concentra el dolor visible, porque convierte una conexión rápida en lenta de forma no determinista. Es imposible reproducirlo a voluntad, así que la culpa se la lleva el servidor.

El transporte es la segunda variable. HTTP: 19.894 conexiones, mediana 676 ms y p90 3.395 ms. stdio: 7.363 conexiones, mediana 222 ms y p90 4.693 ms. stdio es tres veces más rápido en la mediana porque no hay red, pero empeora en la cola: arrancar un proceso tiene un suelo bajo y un techo impredecible. La decisión real es esa, no que stdio sea más rápido.

Ocho servidores por sesión

El tercer factor es el abanico. Cada sesión conecta una mediana de ocho servidores, hasta 16. La mediana del tiempo total de conexión es 5,9 s, el p90 35,5 s y el p99 81,8 s. Un 33,7% de las sesiones dedica más de diez segundos solo a conectar. El peor servidor por mediana, 2.261 ms con un p90 de 10.413 ms, era uno de los dos que el autor ya había desactivado por consumo de RAM.

Y queda el dato incómodo: de 38.876 intentos, 11.556 (29,7%) no llegaron a registrar la línea de conexión establecida. Parte puede ser rotación de logs que corta un fichero a media negociación, así que es un límite superior, no una tasa de fallo. Pero no está repartido: un único conector remoto se lleva 7.422 de esos intentos.

También descartó muestras. Su primera pasada daba un máximo de 119 segundos, hasta que releyó la línea del cliente: el tiempo de espera está declarado en 30.000 ms. Una conexión no puede establecerse a los 119 segundos si el cliente se rinde a los 30; eran portátiles cerrados, con el reloj corriendo durante la suspensión. Recortó todo lo que pasaba de 30 s: 24 muestras de 27.281, un 0,09%.

La conclusión práctica va contra la intuición. Antes de optimizar un servidor conviene contar cuántos hay: quitar uno mediocre rinde más que mejorar uno bueno. Para eso el autor ya había escrito un script de 56 líneas, mcp-optional, que elimina servidores por defecto y los vuelve a añadir cuando una tarea los necesita. Lo escribió por consumo de memoria, no por latencia, y le resolvió las dos. Si las conexiones son erráticas y no uniformemente lentas, el sitio donde mirar es el camino de refresco del token.