A rising rejection rate is a behavioral signal of eroding user trust: a leading indicator of tool poisoning, scope creep, or a rug pull, not a transport fault.
Picture a security guard who waves people through a door all day. Suddenly he starts turning lots of them away. The door did not break and the hallway is fine. Something about the people, or what they are carrying, started looking wrong to him. The approval-rejection ratio is that guard. Each time the assistant wants to run a tool, the user is the guard who says yes or no. When the 'no' count climbs, the wires are not the problem. The users are noticing that a tool is asking for more than it should, or doing something its description never mentioned. That is a trust signal, and trust signals point at the tool and its intent, not at the cable carrying the message.
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 need observability, and the trap in interviews is assuming all health metrics live on the same axis. They do not. Some metrics tell you whether the machinery works. Others tell you whether humans still trust the machinery. The approval-rejection ratio belongs firmly in the second camp, and confusing the two leads to the wrong diagnosis under pressure.
MCP lets a host gate each tool call behind user approval. That design exists precisely because an MCP server is a third-party process whose behavior you do not fully control. The user is the last line of defense. The approval-rejection ratio turns that human gatekeeping into a monitorable number.
This deep dive separates the machine-health signals from the human-trust signals, explains why a rising rejection rate is a leading security indicator, and walks through how to correlate it with other metrics to localize the cause without guessing. The payoff is a clear answer to the interviewer's real question: which signal matters for which failure, and why the rejection ratio cannot be substituted by any of the mechanical ones.
Two families of MCP health metrics
Production MCP observability splits cleanly into two families, and naming the split is half the interview answer.
The machine-health family answers 'is the integration functioning'. These signals are mechanical and have well-understood causes:
- Tool call success and error rate catch failed invocations: bad arguments, a server bug, a broken contract, or an
isErrorresponse. - Per-tool latency catches slow calls: server load, a heavy operation, or network delay on a remote transport.
- Server uptime catches availability loss: a crash, a bad deploy, or a dropped connection.
- Capability and version drift catch a server silently changing its advertised tools or schemas between sessions.
The human-trust family has one headline signal: the approval-rejection ratio. It does not measure whether a call ran. It measures whether a user was willing to let it run. That is a fundamentally different question, and it is the one a rising rejection rate answers.
The split is not academic. It dictates where you look when a metric moves. If a machine-health signal degrades, you reach for logs, traces, and the server process. If the human-trust signal degrades, you reach for the tool's description, its requested permissions, and its change history. Misclassifying the metric sends a team down the wrong runbook, debugging the network for what is really a trust regression, and that wasted time is exactly the window an attacker wants.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Metric | What it senses | Points at |
|---|---|---|
| Approval-rejection ratio | User trust in tool intent | Poisoning, scope creep, rug pull |
| Tool call error rate | Failed invocations | Server bug, bad arguments, contract break |
| Per-tool latency | Slow responses | Server load, network, heavy work |
| Server uptime | Availability | Crash, deploy, connection loss |
| Capability or version drift | Changed schema or tools | Silent update, rug-pull candidate |
Real products, models, and research that use this idea.
- Claude Code and Claude Desktop gate each MCP tool call behind a user approval prompt, producing the approve or reject signal directly.
- The OWASP MCP Top 10, published in 2025, lists tool poisoning and rug pulls as named risks that a rising rejection rate can surface.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhich other MCP metric would you correlate with the rejection rate to confirm a rug pull?
Capability or version drift. Hash each tool's description and schema; a change right before rejections climb is the smoking gun for a silent update.
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.
Reading the rejection rate as a transport or caching bug. It is a behavioral trust metric, so it points at tool intent and permissions, not the wire.
60 second bullets to scan on the way to the call.
Which MCP health metrics are machine signals versus human signals
Why a rising rejection rate is a leading and not lagging indicator
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.