An MCP tool returns its error states in a custom shape: { "success": false, "details": "service unavailable" }. The agent occasionally treats these as successful responses (because the response parsed as JSON) and proceeds with bad data — then a few turns later tells the user something incorrect.
What's the right fix at the MCP layer?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
isError: true is the protocol-level signal MCP defines for failures. When the flag is set, the agent reliably distinguishes the response from a successful one. Custom shapes like {success: false, ...} work probabilistically — the agent often gets it right, but not reliably enough to depend on. Use the flag the protocol provides.
Asking the agent to interpret success: false via prompt is fragile — the moment the response shape changes (new field, different key, different value type), the prompt is misaligned. The protocol-defined flag stays correct regardless of payload shape.
You'd be building infrastructure to do what isError already does — inspect responses, classify them as errors. That's reinventing the protocol, badly.
Adding an LLM call to verify whether each tool response succeeded multiplies cost and latency, and introduces another probabilistic failure point on a problem that has a deterministic answer.