La versión corta

Si tu producto depende de un servidor del Model Context Protocol (MCP), un ping clásico basado en códigos de estado te va a mentir. Un servidor MCP puede devolver 200 OK mientras su capa JSON-RPC está rota, mientras su lista de herramientas viene vacía, o mientras las conexiones SSE se cortan en silencio. La buena noticia para un fundador que trabaja solo es que no necesitas observabilidad enterprise para detectar esto. Solo necesitas unas pocas comprobaciones bien apuntadas al protocolo y una política de alertas razonable que filtre el ruido.

Esta guía explica qué medir de verdad, qué herramientas ligeras encajan con los transportes que usa MCP y cómo distinguir una incidencia real de una sonda inestable.

Por qué los servidores MCP son difíciles de monitorizar

MCP es el estándar abierto que permite a los asistentes de IA llamar a herramientas y datos externos. Por debajo, un servidor suele hablar uno de dos transportes:

  • Streamable HTTP, basado en peticiones y respuestas HTTP, a menudo con SSE para respuestas en streaming.
  • stdio, donde el cliente lanza el servidor como subproceso.

El caso stdio es local y rara vez necesita monitorización externa. El caso streamable HTTP es el que expones al mundo, y ahí es donde se complica la cosa.

Un chequeador de uptime tradicional pregunta: ¿he recibido un 200? Para MCP eso no basta. La guía de OpenStatus lo deja claro: un servidor puede responder 200 OK con una página HTML de error, dejar de devolver el id de JSON-RPC, o devolver silenciosamente un tools/list vacío. Todos esos casos parecen sanos para un pinger de códigos de estado, mientras rompen a cualquier cliente de IA que se conecte.

Así que la primera decisión es elegir qué valida realmente tu comprobación.

Qué medir de verdad

Trata tu servidor MCP como una API con un protocolo charlatán encima. Las señales que importan:

  • Alcance. ¿Se puede abrir una conexión TCP desde la región de la sonda hasta tu endpoint?
  • Viveza JSON-RPC. ¿Responde el servidor a una llamada ping con un payload válido del tipo {"result":...,"jsonrpc":"2.0","id":...}?
  • Descubrimiento de herramientas. ¿Devuelve tools/list las herramientas esperadas, con resultados no vacíos?
  • Comportamiento SSE. En streamable HTTP, ¿mantiene el servidor el stream abierto y emite datos, en vez de quedarse en búfer para siempre o cerrar tras el primer byte?
  • Presupuesto de latencia. Cuánto tarda una llamada típica tools/call, en p50 y p95.
  • Tasa de error. Qué fracción de llamadas devuelve errores JSON-RPC frente a resultados correctos.

Las tres primeras son el suelo mínimo. Las tres últimas son cómo atrapar la rotura lenta y silenciosa que erosiona la confianza del cliente mucho antes de que el servidor caiga del todo.

Elegir un chequeador que hable MCP

No todos los servicios de uptime entienden JSON-RPC o SSE. Estos son los perfiles que vas a encontrar.

Chequeadores con soporte explícito de MCP

  • OpenStatus documenta una configuración de monitor para servidores MCP usando un archivo YAML. La comprobación es un POST con un cuerpo JSON-RPC ping, más aserciones sobre el código de estado y sobre el payload exacto de respuesta ({"result":{},"jsonrpc":"2.0","id":"openstatus"}). Ejecuta desde varias regiones, reintenta ante fallos y puede apuntar a un endpoint MCP sobre HTTPS. Es lo más parecido a un chequeo MCP listo para usar que existe hoy, y combina bien con su comprobación puntual gratuita si solo quieres hacer un test rápido.
  • Pulsetic expone su propio servidor MCP para que un asistente de IA lea datos de uptime, gestione monitores, abra incidencias y programe mantenimientos a través del propio MCP. Útil para “hablar con tu monitorización”, no para chequear un servidor MCP de terceros.
  • OneUptime incluye un servidor MCP junto a su producto de monitorización, con alrededor de 155 herramientas para incidencias, monitores, páginas de estado, on-call y telemetría. Otra vez, una superficie MCP para operar OneUptime, no para monitorizar un servidor MCP arbitrario.

Chequeadores generalistas que se pueden adaptar a MCP

Si tu herramienta preferida permite enviar una petición HTTP personalizada y asertar sobre el cuerpo, puedes enseñarle a hacer ping a un servidor MCP. La mayoría de servicios de uptime maduros encajan en este perfil, incluyendo opciones gratuitas y autoalojadas del mercado general. La receta es parecida:

  1. Método: POST.
  2. URL: tu endpoint MCP.
  3. Cabeceras: Content-Type: application/json y Accept: application/json, text/event-stream.
  4. Cuerpo: un payload JSON-RPC 2.0 ping.
  5. Aserción: código 200 y cuerpo que contenga el id devuelto.

Si también quieres verificar tools/list, lanza una segunda comprobación con method: "tools/list" y aserta que la respuesta contiene al menos un nombre de herramienta que tu servidor expone.

Opciones gratuitas que conviene conocer

OpenStatus anuncia una comprobación gratuita de salud de servidor MCP en el navegador, sin cuenta, ideal para un diagnóstico puntual. Para monitorización continua, las capas gratuitas de servicios generalistas cubren una flota pequeña de endpoints MCP si tu intervalo de chequeo es generoso (hablamos de 5 minutos, no de 30 segundos). Para endpoints SSE, cualquier checker que permita un timeout de respuesta de varios segundos y pueda leer cuerpos en streaming dará una señal más honesta que uno que cierre la conexión tras el primer fragmento.

Configurar una política de monitorización sensata

Más comprobaciones no son mejores. Comprobaciones más útiles sí lo son. Una política práctica para un fundador en solitario:

  • Sondea desde al menos dos regiones. Los proveedores cloud tienen caídas regionales. Si tu base de clientes está concentrada, elige regiones cercanas.
  • Sondea cada 1 a 5 minutos. Más rápido y pagarás en ruido; más lento y una caída de 10 minutos se siente eterna para un cliente de pago.
  • Reintenta 2 o 3 veces antes de alertar. Un fallo aislado es un tropiezo. Tres seguidos ya son un patrón.
  • Separa alcance de corrección. Una comprobación hace ping a JSON-RPC. Otra aserta sobre tools/list. Deben alertar por canales distintos, porque fallan por razones distintas.
  • Alerta por latencia, no solo por caída. Un aumento de 10x en latencia suele ser una caída a cámara lenta.

Distinguir una incidencia real de un tropiezo

Aquí es donde la mayoría de equipos pequeños se queman. Te despiertan a las 3 de la madrugada y al final no pasaba nada. Algunas reglas útiles:

  • Una región, un fallo: ignora. Suele ser la sonda o un problema de red transitorio.
  • Dos regiones, mismo minuto: investiga. Abre el dashboard, mira el cuerpo de respuesta real que capturó el checker.
  • Mismo fallo en las últimas 5 sondas: trátalo como incidencia. Avísate, publica en tu página de estado, comunícalo a los clientes afectados.
  • Latencia subiendo sin fallo claro: abre una incidencia blanda. Muchas veces la resuelves antes de que nadie se entere.

Si tu herramienta guarda el cuerpo de respuesta en el fallo, puedes depurar sin reproducir el problema a mano.

Dónde se complica más adelante

Los patrones anteriores bastan para uno o dos servidores MCP. Cuando creces, las preguntas cambian:

  • ¿Quieres tracing por herramienta estilo Sentry, con contexto de cliente y transporte? Eso es otra categoría de tooling, orientada a depurar dentro del servidor, no solo uptime desde fuera.
  • ¿Quieres que un asistente de IA consulte tus datos de monitorización? Varias plataformas exponen ya su propio servidor MCP, así que tu asistente de código puede preguntar “qué monitores cayeron esta semana” sin que salgas del chat.
  • ¿Quieres autoalojar? Algunas plataformas dejan correr el plano de control en tu infraestructura y exponer un endpoint MCP a tu asistente en el mismo dominio.

Esos son buenos problemas. Significan que a tus clientes les importa lo suficiente como para darse cuenta cuando algo se rompe.

Lista de arranque

  • Elige un checker de uptime que soporte aserciones HTTP personalizadas.
  • Añade un chequeo ping contra cada endpoint MCP público.
  • Añade un chequeo tools/list que aserte al menos un nombre de herramienta conocido.
  • Sondea desde dos regiones, cada 1 a 5 minutos, con 2 o 3 reintentos.
  • Separa alertas de caída de alertas de corrección.
  • Conserva el cuerpo de respuesta en el fallo para depurar sin reproducir.
  • Repasa el historial de alertas cada mes y ajusta umbrales.

Esta configuración no ganará ningún RFP enterprise, pero atrapará las caídas que si no encontraría antes tu cliente.

Preguntas frecuentes

¿Puedo simplemente hacer ping a mi servidor MCP con curl? Para una comprobación rápida, sí. Para monitorización continua, no. Quieres historial, alertas, sondas multi-región y aserciones sobre el cuerpo de respuesta, algo que curl no te da por sí solo.

¿Necesito un plan de pago? No necesariamente. Las capas gratuitas cubren una flota pequeña si el intervalo de sondeo es relajado. Los planes de pago se justifican cuando necesitas más regiones, intervalos más cortos o aserciones más ricas.

¿Y el transporte stdio? stdio es local al cliente y no necesita monitorización externa de uptime. Lo que monitorizas entonces es el proceso anfitrión y sus logs.

¿En qué se diferencia monitorizar un servidor MCP de monitorizar una API? Con una API basta con el código de estado y quizá un JSON path. MCP exige consciencia de JSON-RPC, de SSE y verificación de la lista de herramientas, porque el protocolo tiene más formas de estar “arriba pero roto”.

Fuentes

  • Guía de OpenStatus sobre monitorización de servidores MCP
  • Documentación del servidor MCP de Pulsetic
  • Documentación del servidor MCP de OneUptime

Sources