is_error in tool_result: reporting tool failures

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. Your create_ticket tool refuses a call because the target project is archived. Your loop swallows the refusal and returns a normal-looking tool_result saying the ticket was filed, so Claude tells the user about work that never happened. You want Claude to learn the call failed and act on that. What's the most effective way to report this refusal?

   Right. In the game that’s Renown for your Agent Architecture and Orchestration building.

   Not that one: A is right. In the game your Agent Architecture and Orchestration building would lose a little Renown, and this question would come back later.

   The answerA.Return the refusal text as the tool_result content with is_error set to true, which Claude then incorporates into its response.Set is_error to true when "the tool execution resulted in an error", and "Claude will then incorporate this error into its response". The flag is what turns a failed call into something the model reasons about rather than reports as success, and the content beside it should say what went wrong and what to try next.Your answerB.Return the refusal text as the tool_result content and leave is_error unset, trusting Claude to read the wording as a failure.Without the flag the result reads as a successful execution whose content happens to describe a problem. The field exists so the status does not depend on wording.Your answerC.Raise the refusal to your own caller, end the turn there, and replay the whole conversation once the project is unarchived.A tool failure is an ordinary event inside the loop. Claude can adjust within the same turn once it receives the error, so aborting the run discards recoverable progress.Your answerD.Send the refusal as a plain user text block after the results, so Claude receives it as an instruction from you.Text after the results is not attached to any tool_use id, and it presents the failure as your instruction rather than as the outcome of the call Claude made.

   Written from platform.claude.com/docs/en/agents-and-tools/tool-use/handle-tool-calls

2. Your platform team runs a Claude Sonnet 5 (claude-sonnet-5) agent whose inventory tool sometimes raises a timeout. Your current handler drops the block for the failed tool and returns only the successful tool_result blocks. Requests then fail with an invalid-request error, and when they do succeed the agent has no idea the lookup failed. What change would most effectively address this issue?

   Right. In the game that’s Renown for your Tool Design, MCP and Server Tools building.

   Not that one: B is right. In the game your Tool Design, MCP and Server Tools building would lose a little Renown, and this question would come back later.

   Your answerA.Return the failed tool's result with an empty content string so the block validates and Claude sees nothing.An empty content satisfies the schema but lies to the model. Claude reads it as a successful call that returned nothing and proceeds as if the inventory were genuinely empty, so the loop never recovers from the timeout.The answerB.Return a tool_result for the failed call with is_error: true and the error text as its content.Every tool_use block in an assistant message must be answered by a tool_result block carrying the same tool_use_id in the following user message.Your answerC.Re-send the assistant message without the failing tool_use block so no matching result is required.The assistant message must be appended with its full content, exactly as returned. Editing out a tool_use block rewrites the model's own turn and produces a transcript that no longer reflects what happened, which degrades subsequent tool selection.Your answerD.Set tool_choice to {"type": "none"} on the retry so Claude answers from the results that succeeded.tool_choice: {"type":"none"} only stops Claude from making new tool calls. It does not excuse the unanswered tool_use block from the previous assistant turn, so the request still fails validation.

   Show the full explanation and doc quotes

   Failures are signalled in-band: return the block with is_error: true and a short description as content. Claude then sees the failure, can retry, choose another tool, or explain the gap to the user.

   Written from platform.claude.com/docs/en/agents-and-tools/tool-use/handle-tool-calls

3. Claude calls your send_report tool without the required recipient field. Your loop treats a missing argument as a defect, aborts the run and pages your on-call engineer. Your lead asks whether the loop could instead hand the problem back to Claude and let the run carry on. What's the correct approach to handle a malformed tool call?

   Right. In the game that’s Renown for your Agent Architecture and Orchestration building.

   Not that one: A is right. In the game your Agent Architecture and Orchestration building would lose a little Renown, and this question would come back later.

   The answerA.Return a tool_result naming the missing field with is_error: true, and let Claude reissue the call with corrections.For an invalid call, return a tool_result carrying the error with is_error: true. "If a tool request is invalid or missing parameters, Claude will retry 2-3 times with corrections before apologizing to the user." The correction loop is built in; the caller's job is to report the fault precisely rather than to abort or to guess.Your answerB.Return a tool_result naming the missing field with is_error unset, and run the tool yourself with a default recipient.Substitutes a value Claude never chose, hiding the malformed call instead of correcting it and sending a report to the wrong place.Your answerC.Resend the previous request unchanged, treating an incomplete call as a sampling artefact that rarely repeats itself.Nothing about resending the same request makes the next call better formed, and the turn's tool results are lost in the process.Your answerD.Send a plain user text block explaining the missing field, leaving that tool_use block without a result this turn.Every tool_use block needs a tool_result. Explaining the fault in text leaves the id unanswered, and the request is rejected for it.

   Written from platform.claude.com/docs/en/agents-and-tools/tool-use/handle-tool-calls