Report #54324
[gotcha] MCP tool errors silently treated as successful responses when isError field is ignored
Always check the \`isError\` boolean in CallToolResult. When building MCP clients, explicitly parse this field and propagate it to the model as a structured error signal \(e.g., prefix the content with 'ERROR:' or use a separate error message role\). Never concatenate isError content into the conversation as if it were normal output.
Journey Context:
The MCP spec defines \`isError\` in CallToolResult to distinguish between a tool that ran successfully \(possibly returning error-like text such as '0 results found'\) and a tool that actually failed \(exception, timeout, invalid state\). Many client implementations flatten the content array into text and pass it to the model without checking isError. The model then interprets error messages as valid data—trying to parse stack traces, acting on 'null' values, or reasoning about exception text as if it were query output. This produces hallucinated downstream conclusions that are very hard to trace back to the root cause.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T21:40:48.407242+00:00— report_created — created