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.
Free · 2 AI evals / day
An MCP integration has several moving parts, and one global number hides where things break. So you instrument it in layers.
The first layer is **protocol health**. Can the host even connect to the server? Watch how long the `initialize` handshake takes and whether servers stay reachable. A server that fails to start drops all of its tools at once.
The second layer is tool execution. For each tool, track how often a `tools/call` succeeds, how fast it responds, and which JSON-RPC error codes come back. Slice these per tool, not globally, because one slow tool can hide behind ninety fast ones.
The third layer is user trust. MCP asks the user to approve tool calls. If the rejection rate suddenly climbs, users are getting suspicious, which can signal a tool that quietly changed its behavior or is now asking for too much.
Finally, wire alerts on each layer and put them on one dashboard. There is no built-in MCP metrics standard, so you define the schema yourself.
I instrument three layers, and I slice everything per server and per tool.
**Protocol health** comes first. I track session establishment time, the `initialize` handshake duration, and server availability. A rising handshake time hints at version negotiation regressions. A downed server takes all of its tools with it.
**Execution health** is the core. Per tool I track `tools/call` success rate, latency percentiles like p50, p95, and p99, and the distribution of JSON-RPC error codes. A p99 spike on one tool usually means an external dependency or a rate limit. A burst of -32601 means method not found, often server version drift. A burst of -32700, parse error, points at schema evolution bugs.
The third layer is the **approval funnel**. MCP makes the user approve tool calls. I track the approval to rejection ratio per tool. A rising rejection rate is a trust signal. It can mean a tool changed its description or now asks for broader scope, a classic rug pull or tool-poisoning symptom.
There is no standard MCP observability schema, so I define one. I tag every metric with server name, tool name, and protocol version, then alert per layer and render it all on one dashboard.
Quick reference
TL;DR
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.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A single local stdio server with one or two hard-coded tools in a prototype Full multi-layer instrumentation is overhead; basic success and error logging is enough until it ships to real users.
A short-lived batch agent run with no human in the loop The approval funnel metric is meaningless when no user approves calls, so that whole trust layer collapses to nothing.
Treating these client-side metrics as a substitute for server sandboxing Observability detects bad behavior after it happens; it does not enforce the trust boundary that MCP leaves to the host.
Quick scan · 2–4 min
Everything important, quickly.
5 min: three-layer model, per-server and per-tool cardinality, JSON-RPC error code diagnosis, schema-hash drift detection, approval funnel as a trust signal, and per-layer alert routing.
Real products, models, and research that use this idea.
1Claude Code runs multiple MCP servers per session, so per-server slicing is essential to isolate which filesystem or GitHub server regressed.
2Teams wrap mcp-inspector and JSON-RPC tracing into CI smoke tests, then export the same client-side spans to Datadog or Grafana in production.
3A Postgres MCP server hitting connection-pool limits surfaces as a p99 latency spike on its tools while every other server stays healthy.
4The OWASP MCP Top 10 lists rug-pull and tool-poisoning attacks that a rising approval-rejection ratio is designed to catch early.
Interviewer follow-ups
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?
Sign in or go Pro to see the approach for this follow-up.
QWhere do you emit these metrics from, the host client or each MCP server, and why?
Sign in or go Pro to see the approach for this follow-up.
QHow do you set alert thresholds when each tool has a wildly different baseline latency?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
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.