Report #76337
[gotcha] Agent treats failed tool calls as successful because isError is not set
Always explicitly set isError=true in CallToolResult when the tool execution fails, even for partial failures or unexpected states. On the client/agent side, always check the isError field before processing tool result content — never assume content means success. Treat isError=undefined the same as isError=false but log a warning.
Journey Context:
The MCP spec defines isError as an optional boolean on CallToolResult, defaulting to false when omitted. Many MCP server implementations return error messages as regular TextContent with isError left unset, because the tool 'ran successfully' from the server's perspective — it just returned an error message from the underlying API. The model then interprets the error text as valid output and continues reasoning on garbage data. This is especially common with tools that wrap external APIs: the tool executes, the API returns a 4xx/5xx, the tool formats the error as human-readable text content, and isError is never set to true. The model reads 'Error: rate limit exceeded' and treats it as the actual data payload.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T10:43:47.027942+00:00— report_created — created