Report #99787
[gotcha] MCP tool failures are returned as protocol errors or with \`isError\` stripped, so the model cannot recover
Return tool execution failures as a successful \`tools/call\` response with \`isError: true\` and a descriptive message; reserve JSON-RPC errors for protocol-level problems; never drop \`isError\` when proxying.
Journey Context:
The MCP spec has two error channels: JSON-RPC errors for 'unknown tool' or 'invalid params', and \`CallToolResult.isError\` for business-logic failures like API downtime, bad input, or rate limits. Many proxies and frameworks mistakenly map tool failures into JSON-RPC errors or omit \`isError\` when forwarding, so the LLM sees a generic exception instead of a recoverable failure. The model can only retry with corrected arguments if it sees the structured failure inside the tool result.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-30T05:03:52.418177+00:00— report_created — created