Describe five key metrics or signals you would instrument to monitor the health of a production MCP server integration. For each, explain what degradation indicates.
Instrument three layers: protocol health, per-tool execution health, and the human approval funnel. MCP ships no observability schema, so you define your own.
Imagine you hire a bunch of outside contractors who each speak through one standard intercom. You want a dashboard that tells you, per contractor, how often a job actually finishes, how long it takes, and how often the intercom drops the call or garbles the message. You also watch how often you have to reject a contractor's request because it looks shady. If one contractor suddenly fails more, gets slower, garbles messages, or starts asking for things you keep refusing, you notice before it hurts the whole operation. MCP servers are those contractors. The intercom is the protocol. Your dashboard watches each one separately, so a single bad server cannot quietly poison the whole agent.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Production MCP integrations fail in ways a single uptime check never catches. A host like Claude Code or Cursor connects to several MCP servers at once, each advertising its own tools, resources, and prompts over JSON-RPC. One server can crash, one tool can get slow, one server can silently redefine a tool after the user approved it, and a flat global metric will average all of that into a reassuring lie.
The protocol itself gives you nothing to lean on. There is no standard MCP observability schema, no built-in metrics endpoint, no agreed error taxonomy beyond the JSON-RPC base codes. You build the instrumentation yourself, on the host-side client, and you decide the cardinality and the alert routing.
The organizing idea is three layers: protocol health, execution health, and the human approval funnel. A fourth concern, capability drift, cuts across them and deserves its own signal. This deep dive walks each layer, the specific metrics, what their degradation means, and how to turn the whole thing into a dashboard plus alerts an on-call engineer can actually act on.
Layer 1: protocol and server availability
The bottom layer is whether the host can talk to the server at all. An MCP session begins with an initialize handshake that negotiates protocol version and exchanges capabilities. You instrument two things here: session establishment time and server availability.
Session establishment time is the wall-clock duration of the initialize and initialized handshake. A slow, creeping increase is a classic regression signal. It usually means the server is doing more work at startup, or that version negotiation is falling back through extra rounds because the host and server disagree on the supported protocol version.
Server availability is binary but high-leverage. When a server process dies or a remote endpoint times out, every tool it advertised disappears from the catalog at once. That is a cliff, not a slope. You want availability tracked per server, with the count of currently connected servers as a top-line gauge, because a host running ten servers down to eight has quietly lost a fifth of its capabilities even though the agent still appears to work.
The transport matters here too. A local stdio server fails differently from a remote streamable-HTTP one. The stdio process can crash or hang, so you watch for a dead subprocess and a stalled read. The remote server can return connection resets, TLS errors, or timeouts, so you watch the HTTP layer separately. Tag each availability metric with its transport, because the remediation differs: respawn a subprocess versus retry with backoff against a remote endpoint.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Layer | What to instrument | What degradation indicates |
|---|---|---|
| Protocol | Handshake time, server availability | Version negotiation regression or server crash |
| Execution | Success rate, latency percentiles, error histogram | Slow dependency, rate limit, or schema bug |
| Capability drift | Tool schema hash diff at connect | Silent tool redefinition or rug pull |
| Approval funnel | Approval-to-rejection ratio per tool | Eroding user trust or tool poisoning |
Real products, models, and research that use this idea.
- Claude Code runs multiple MCP servers per session, so per-server slicing is essential to isolate which filesystem or GitHub server regressed.
- Teams wrap mcp-inspector and JSON-RPC tracing into CI smoke tests, then export the same client-side spans to Datadog or Grafana in production.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you detect a rug-pull attack where a server changes a tool after the user approved it?
Hash the advertised tool schema and description at connect time, diff against the last approved hash, and require re-approval plus a security alert when the fingerprint changes mid-session.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Reporting one global success rate and one latency number. That hides the single bad server or bad tool dragging an agent down. Always slice per server and per tool.
60 second bullets to scan on the way to the call.
The three layers of MCP health and what each one measures
Why metrics must be sliced per server and per tool
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.