A commenter found a false positive in my MCP failure detector, and fixing it took a day

Posted here this morning about MCP tool errors returning HTTP 200 with isError: true. Two people in that thread pushed back with a correction, and following it up turned into a bug fix.

The correction: -32601 and -32602 come back as JSON-RPC error objects, not as isError, so keying detection off isError alone misses them.

Investigating that surfaced something I wasn't looking for.

The high-level McpServer actually converts most protocol errors into isError: true before instrumentation sees them — but it wraps them as "MCP error {code}: ..." inside the content text. So the code is recoverable, and those failures were already being fingerprinted.

The problem was what happened next. -32602 is overloaded across four conditions in the TypeScript SDK: tool not found, tool disabled, input validation failure, and output validation failure. That last one is the server returning content that breaks its own advertised schema.

My detector was counting those as agent retry thrash. They aren't. The agent can retry with different arguments forever and never fix a server-side schema bug. False positive since v0.4.0, nobody reported it, and it only turned up because I traced the classifier against the SDK's real error messages instead of assuming.

v0.7.0:

- output validation failures excluded from thrash counting

- mcp.failure.channel attribute with per-channel thresholds

- fingerprints unchanged, verified against the previous tag

Also checked whether field-level convergence tracking was worth building (different property failing each attempt = agent converging; same property repeatedly = ambiguous tool description). Turned out the fingerprint hash already discriminates these, because Zod's error message embeds the full issues array with paths. So instead of a new detector, I wrote regression tests so that accidental behaviour doesn't silently break.

https://www.npmjs.com/package/opentel-mcp

Five known gaps tracked in the repo, each credited to whoever raised it. Still interested in what people running MCP in production are seeing — the corrections have been more useful than anything I'd have found alone.