Conectaste tu agente de IA a quince servidores MCP — Slack, GitHub, Jira, una base de datos — y lo probaste hasta que todo funcionaba en perfecta armonía. MCP (Model Context Protocol) es el estándar de conexión universal que permite a los agentes de IA hablar con herramientas externas, como USB pero para datos. Tu demo se veía genial. Tu jefe asentía con la cabeza. Lo mandaste a producción.

Aquí viene la parte que nadie te advirtió: los servidores MCP no son paquetes estáticos sentados en tu disco. Son procesos vivos y endpoints remotos. Y a fecha de 25 de abril de 2026, ninguna plataforma de agentes te avisa cuando uno se cae, se vuelve lento como tortuga, o empieza a devolver basura.

La mitad de tus herramientas podrían estar muertas ya

El 20 de abril, RapidClaw auditó 1,847 servidores MCP públicos en siete registros. El resultado: 52% están muertos o abandonados. Solo el 17% — 315 servidores — calificaban como listos para producción. El servidor MCP promedio tiene seis commits en su vida, un solo mantenedor, cero tests, y lleva 142 días sin actualizarse.

Ese es el ecosistema del que depende tu agente. Un volado decide si la herramienta que está llamando todavía funciona.

Y el protocolo MCP no te ayuda en nada. No hay un endpoint de health check integrado — ninguna forma estandarizada para que un servidor diga "estoy vivo y funcionando". Los SDKs implementan un ping básico, pero no hay /health, no hay /ready, no hay sondas de vida. Cada equipo arma lo suyo, o — lo más común — no arma nada.

El agujero con forma de protocolo

El vacío no está solo en las plataformas — está en la especificación. HTTP tiene códigos de estado. gRPC tiene servicios de health checking. Kubernetes tiene sondas de liveness y readiness. MCP tiene... un método ping que confirma que la capa de transporte está viva, no que el servidor pueda hacer su trabajo.

Un servidor MCP de base de datos puede responder al ping mientras su pool de conexiones está agotado. Un servidor MCP de GitHub puede devolver pong mientras su token de autenticación expiró hace tres semanas. El protocolo no distingue entre "el transporte funciona" y "la herramienta funciona". Esa distinción importa cuando tu agente quema tokens reintentando una herramienta que técnicamente responde pero funcionalmente miente.

El Agent Observability de Google, lanzado el 22 de abril como parte de Gemini Enterprise Agent Platform, rastrea conteo de requests y latencia p95 para servidores MCP. Dos métricas. Ya cubrimos los vacíos más amplios de la plataforma — la versión corta es que Google construyó trazabilidad a nivel de agente, no monitoreo a nivel de herramienta. AWS presentó un enfoque similar de catálogo con Agent Registry el 17 de abril — un directorio telefónico para agentes, no un monitor de salud. Ambos reconocen que las herramientas necesitan tratamiento de infraestructura. Ninguno verifica realmente si tus herramientas están vivas.

Para comparar, cualquier microservicio medio decente — una pieza pequeña e independiente de tu backend — tiene health checks, tasas de error, análisis de calidad de respuestas y alertas automatizadas. Tu servidor MCP tiene un contador de requests y un cronómetro.

Qué se rompe cuando una herramienta se rompe

Cuando un servidor MCP se degrada en silencio, tu agente no se entera. O alucina una respuesta (se inventa algo), reintenta quemando tokens en silencio — los fragmentos de texto que la IA lee, cada uno cuesta dinero — o falla sin decirte cuál herramienta se rompió. Las trazas de observabilidad del agente muestran qué decidió el agente. No muestran si la herramienta estaba sana cuando respondió. Ves el síntoma. No puedes diagnosticar la causa.

Es como monitorear tu aplicación web pero no monitorear su base de datos. El dashboard se queda en verde hasta que todo está en llamas.

Qué hacer ahora mismo

Si estás corriendo agentes en producción, trata cada servidor MCP como una dependencia de microservicio:

  • Configura timeouts. El protocolo MCP no lo va a hacer por ti.
  • Define fallbacks. Si una herramienta se cae, tu agente necesita un Plan B, no una alucinación improvisada.
  • Monitorea la calidad de las respuestas. Un 200 OK que devuelve basura es peor que una falla limpia.
  • Envuelve las conexiones en circuit breakers — un patrón que corta el acceso a un servicio que está fallando antes de que arrastre todo lo demás.
  • Acepta el techo. Tu agente es exactamente tan confiable como su herramienta menos confiable.

La mayoría de los equipos no presupuestaron esta plomería. La mayoría aprenderán por qué debieron hacerlo.

La capa que falta

El stack de agentes en abril de 2026 tiene modelos más inteligentes, registros más grandes y gateways más sofisticados. Lo que no tiene es tool SRE — Ingeniería de Confiabilidad de Sitio aplicada a las herramientas de las que dependen los agentes. Artículos anteriores en este canal argumentaron que la ingeniería de confiabilidad de agentes todavía no existe. La auditoría de RapidClaw demuestra que el problema está un nivel más abajo: no puedes tener agentes confiables cuando el protocolo que hablan ni siquiera define qué significa "saludable" para una herramienta.

La primera plataforma que lance monitoreo de salud a nivel de herramienta con endpoints /health y /ready integrados en la spec de MCP — no atornillados por cada vendor — captura la capa de confiabilidad que le falta a todo el ecosistema.

Empezaste con quince servidores MCP que funcionaban perfecto en dev. En producción, aproximadamente ocho de ellos están a un volado de morir. Nadie los está vigilando. Quizás empieza por ahí.