Los Servidores MCP Fallan en Silencio. Tu Dashboard No Te Lo Dirá.

Tu servidor MCP devuelve 200 OK en cada petición. Tu panel está en verde. Tus usuarios están frustrados.

Los códigos de estado HTTP no miden lo que importa aquí. La herramienta devolvió datos. ¿Era la herramienta correcta? ¿Fue útil la respuesta? ¿El modelo la usó de verdad?

Una evaluación pública de Anthropic sobre uso agentic de herramientas (MCP Bench, finales de 2025) midió tasas de error de selección entre 28% y 46% en servidores MCP populares con más de seis herramientas. El mismo patrón aparece en producción: servidores con uptime perfecto, latencia por debajo de 200ms y cero errores 5xx — mientras el modelo llama a la herramienta equivocada casi la mitad del tiempo.

El servidor no lo sabe. El equipo no lo sabe. Los usuarios solo dicen que la IA es mala.

Eso es el fallo silencioso. Un servidor MCP puede pasar cada chequeo tradicional y aun así responder mal a cada llamada.

Para una API REST, funcionar significa aceptar peticiones válidas y devolver respuestas correctas. Décadas de herramientas existen para verificar eso.

Para un servidor MCP, funcionar es una cadena de cuatro pasos. El modelo elige la herramienta correcta. Envía parámetros correctos. Recibe una respuesta útil. La incorpora en su respuesta. Cada paso falla independientemente. Ninguno aparece en el monitoreo tradicional.

¿Herramienta equivocada? 200. ¿Parámetros que pasan validación de schema pero ignoran la intención del usuario? 200. ¿Respuesta ignorada? 200.

Puedes tener 100% de éxito en el panel y 40% de éxito en producción. Esa brecha es donde los usuarios dicen "la IA no funciona" — y tienen razón, aunque cada métrica de SRE diga lo contrario.

Una vez que aceptas que las métricas tradicionales son insuficientes, la pregunta es qué medir en su lugar. Cinco cosas.

**Precisión de selección de herramienta.** Si tienes `search_invoices` y `list_documents`, y un usuario pide "las facturas del mes pasado," ¿cuál se llama? Rastrea la brecha entre selección prevista y real. Es la métrica más reveladora en observabilidad MCP.

**Validez de parámetros.** No si los parámetros pasaron la validación de schema — eso es lo básico. ¿El rango de fechas coincide con lo que pidió el usuario? ¿La consulta capturó su intención?

**Utilización de respuesta.** ¿El modelo usó la respuesta? Si devuelves 50 filas y el modelo no referencia ninguna en su respuesta, o la descripción de la herramienta está mal, o el formato está mal, o los datos son irrelevantes.

**Tasa de recuperación de errores.** Cuando una llamada falla, ¿el modelo reintenta con parámetros corregidos, cambia de herramienta, o se rinde? El patrón de recuperación te dice si tus mensajes de error son útiles.

**Coste por invocación exitosa.** No coste por llamada. Coste por llamada que produjo una respuesta útil. Los reintentos perdidos y las llamadas a la herramienta equivocada suelen llevar el coste real a 3-5x el gasto bruto de la API.

Estas cinco te dicen más sobre la salud de un servidor MCP que todas las métricas tradicionales juntas.

Datadog, New Relic y Grafana son excelentes en lo suyo. Rastrean distribuciones de latencia, tasas de error, throughput y utilización de recursos. Esa es la forma correcta para una API cuyo cliente es un navegador o una app enviando peticiones deterministas.

El cliente de un servidor MCP no es determinista. Es un modelo tomando una decisión en tiempo de inferencia. El modo de fallo no es "la petición agotó el tiempo." Es "el modelo decidió que esta era la herramienta correcta, y no lo era." Es un problema de calidad de decisión, y el APM tradicional no está hecho para medir eso.

En concreto: si tu agente tiene `get_customer` y `search_customers` y el modelo siempre elige `get_customer` con un ID inventado, tu p99 se mantiene plano, tu tasa de error plana, y cada interacción con el usuario termina en fallo. La tooling existente no tiene señal que emitir.

Necesitas una capa de observabilidad entre el modelo y las herramientas — una que correlacione intención del usuario, selección de herramienta, parámetros y utilización de respuesta. El APM tradicional es el suelo. Para servidores MCP, no es ni la mitad del panorama.

Tres cosas concretas para empezar. No necesitas hervir el océano.

**1. Registra cada invocación con contexto completo del prompt.** No solo nombre de la herramienta y parámetros. La conversación que llevó a la llamada, el system prompt, el último mensaje del usuario. Sin contexto, no puedes evaluar si la selección fue correcta.

**2. Rastrea herramienta prevista versus herramienta seleccionada.** Necesitas verdad de base — etiquetas manuales sobre una muestra, señales de pulgar arriba/abajo del usuario, o reglas heurísticas (una pregunta que coincide con "factura|facturación|pago" y termina en `list_contacts` es un defecto). Incluso heurísticas aproximadas superan a nada.

**3. Mide la utilización de respuesta.** Compara lo que devolvió la herramienta con lo que apareció en la respuesta final del modelo. Una brecha grande significa mal formato de respuesta, datos irrelevantes, o una descripción que no ayuda al modelo a usar el resultado.

Estas tres señales — contexto de invocación, precisión de selección, utilización de respuesta — te dicen si tu servidor MCP realmente ayuda a los usuarios. Los paneles de cinco nueves te dicen si el proceso está vivo. Son preguntas diferentes.