MCP Server Monitoring: What Reliability Requires

MCP server monitoring should answer one practical question first: can an agent discover, authenticate, call, and recover from each tool before it wastes time, tokens, or privileges? If your dashboard only says the MCP process is up, you are missing the failures that hurt production users.

The reader for this piece is the platform engineer or SRE who has already learned that agent infrastructure does not fail like a normal API. The server can respond to a health check while tools/list is slow, an OAuth audience check is broken, a tool schema is stale, or a downstream API is timing out inside an agent loop.

MCP health is tool health

MCP gives you useful primitives: ping, cancellation, progress notifications, logging messages, transport and session semantics, authorization rules, and tool annotations. Those are good building blocks. They are not a production observability system.

A useful readiness check should prove more than process life. At minimum, the server should initialize a session, return a sane tool registry, authenticate HTTP requests when auth is configured, and exercise a cheap read-only diagnostic tool. A ping confirms responsiveness. It does not prove a database-backed tool can read data or that a cloud credential still works.

The MCP server monitoring lifecycle

Track MCP as a sequence, not a single endpoint. The path is initialization, auth discovery, session creation, tools/list, tool selection, tools/call, downstream work, result validation, retry, and cancellation.

• Session initialization failures
• tools/list duration, error rate, and tool count
• Per-tool call volume, p50, p95, and p99 latency
• Timeout rate by tool, client, server, and transport
• Retry count, retry outcome, and circuit-open events
• Schema validation failures and malformed results
• 401 and 403 spikes, token audience failures, and missing session IDs
• Downstream dependency latency and token or cost correlation

This is where OpenTelemetry fits. The brief points to vendor guidance from Elastic and Datadog around spans for tools/list and tools/call, with per-tool latency, errors, retries, and downstream timing. Server-side spans show what happened inside the handler. Client-side traces show how the agent experienced the failure.

Auth and safety belong on the dashboard

MCP tools are model-controlled and may invoke external systems. That means reliability monitoring has a safety dimension. For Streamable HTTP servers, the transport guidance includes Origin validation, localhost binding guidance, authentication, and session ID behavior. When HTTP authorization is used, MCP defines OAuth-based requirements such as bearer tokens on every HTTP request, protected resource metadata, token audience validation, and no query-string access tokens.

Those should become observable events. Track auth failures, unexpected egress, destructive tool calls, open-world tools, unannotated tools, and tool invocations that happened without the expected user confirmation or policy approval.

Tool annotations help, but do not treat them as enforcement. The MCP tools spec says clients must treat annotations as untrusted unless they come from trusted servers. Ecosystem issues around Payload CMS and the Ruby SDK show that support for readOnlyHint, destructiveHint, idempotentHint, openWorldHint, and title is still uneven. Verify annotations in CI.

Timeouts and retries need hard limits

Timeout behavior is still inconsistent across clients and SDKs. The brief cites a Model Context Protocol SEP about fixed or undefined timeouts and a TypeScript SDK issue where a client timed out after 60 seconds despite progress updates. Do not assume your host, SDK, and transport agree.

Long-running tools should return job handles, emit progress, support polling, and handle explicit cancellation. A disconnected HTTP stream is not automatically cancellation, so test whether resources are actually freed.

Retries need a cap at the agent-loop level, not only at the HTTP-call level. A small retry limit can still become expensive when the model keeps deciding to try again. Use per-tool and per-session or per-tenant circuit breakers. One broken downstream service should not disable the whole MCP server.

A practical production checklist

• Instrument initialization, tools/list, tools/call, downstream calls, retries, cancellation, and terminal errors.
• Use readiness probes that exercise a diagnostic tool, not only ping.
• Alert on timeout spikes, retry loops, circuit-open events, schema failures, and auth failures.
• Monitor tool inventory drift, unannotated tools, destructive tools, and open-world tools.
• Redact secrets and sensitive tool arguments from traces and logs.
• Correlate tool failures with token usage and cost.

The useful mental shift is simple. Do not monitor an MCP server like a green web endpoint. Monitor the path an agent actually takes: discovery, selection, authorization, invocation, downstream work, retries, cancellation, and safety controls. That is where MCP reliability lives.