MCP Tool Call Failures Are Silent by Default

A 2026 stress test of 100 production MCP servers found the median server passes 71% of tool-call trials, and the top decile clears 95%, according to DigitalApplied’s stress-test study. Chain five calls at the median rate and the sequence succeeds end to end about 18% of the time; chain ten and it drops to roughly 3%.

An independent benchmark on real MCP servers, MCP-Atlas, points at the same problem from a different angle: 63.3% of the failures it diagnosed occurred after the tool call itself had executed successfully.

That is the pattern this post is about. Most MCP tool call failures never raise an exception. The call returns a schema-valid response, the agent logs the step as done, and the underlying action, the row that should have been written, the email that should have gone out, never happened.

Why MCP Tool Call Failures Don’t Throw an Error

Failures split into five categories in that same stress test: schema mismatches (38%), timeouts (24%), auth and quota errors (19%), upstream API failures (12%), and MCP protocol bugs (7%). Schema mismatches and protocol bugs tend to surface as a visible error, since the request or response literally doesn’t parse.

The other three do not. A timeout, a 401, or a 502 from the wrapped API is exactly the kind of failure a server wrapper is built to catch and normalize, and a normalized response often looks identical to a real success.

DigitalApplied’s SLO design framework for MCP names this pattern directly: a tool that returns OK when the operation actually failed, the database transaction rolled back, the email queued but never sent, the webhook fired but to a stale URL, registers as success in the server’s own metrics and as failure in the user’s reality.

What a Silent Partial Execution Looks Like

Zayne Turner’s MCP reliability series walks through this exact failure mode in Dewy Resort, an open-source reference hotel-booking system built to teach recovery patterns. In the walkthrough, a guest-checkout tool charges $250 through Stripe, then times out updating the matching booking record in Salesforce.

The payment clears. The booking stays unconfirmed, the room can’t be reassigned, and the day’s sales reporting is wrong until someone reconciles it by hand. Two systems, one workflow, no shared transaction boundary: Stripe commits independently of Salesforce, and nothing rolls back when the second call fails.

An agent running that workflow has no way to know any of this happened. It sees a 200 from the payment step and a timeout from the booking step.

In most implementations it either retries the whole call, duplicating the charge, or moves on with a half-completed workflow it believes is finished. The stress-test study cited above found retries are in fact the most common reliability complaint teams report: not a true failure, but a successful first call the agent misclassified as failed and re-invoked, duplicating a side effect that was only supposed to happen once.

Watching the Effect, Not the Return Code

The same SLO framework’s fix is to cover this with checks that verify the operation by observing its downstream effect, not by trusting the handler’s return code. That’s a harder problem than it sounds, because it means grading a tool call against what actually happened in the connected system, not against what the MCP server said happened.

There is an honest limit here: the trace records the server’s schema-valid answer, so no grader can read the truth off the call itself. What graders can see is everything downstream of the lie: state that stops matching later in the session, a retry burst on a step that reported success, task outcomes drifting down. Tessary scores your production traces on these and reads the trend across verdicts over time, not any single score. One silent failure is noise; a tool whose downstream failures move from 3% of sessions to 11% is a real change, even when the graders themselves are imperfect.

When the cause hunt reaches the tool boundary and the trace goes dark, that gap is itself the finding. It names the next node to instrument, usually a verification span on the connected system, and the next silent failure gets caught at the call instead of three steps later.

When the Failure Never Came Through Your Repo

An MCP server updates on its own schedule, not yours. When its behavior shifts, your agent degrades with nothing in the diff to explain it: no PR touched the tool, and git blame has nothing to say. This is the case Tessary is built around. When a grader trend drops, it traces the failing quality dimension back through the agent’s chain to the tool call whose behavior shifted, and tells you when it shifted. Evals for tool-calling agents covers what those per-tool checks look like.

Langfuse and Braintrust hold the same traces and will show you the pass rate falling. They won’t tell you the fall started the day a specific server shipped a new version. That is the question Tessary answers.

For changes that do ship through your repo, the same attribution engine runs before the merge: regression detection reads your signal history against the next PR, so a change that touches a flaky tool wrapper gets flagged before it ships. A gate like that only fires on changes that go through a PR, though. A server-side update reintroduces the failure with no deploy at all, which is why the production trend, not the gate, does the primary work.

Find the Tool Call That Broke Your Agent

Point Tessary at your MCP traces and find which tool call is quietly returning OK on a failed operation, and when its behavior changed. Connecting takes a few minutes and no credit card.

Find what broke your agent