Server tools, server_tool_use and pause_turn

Try 3 questions on this

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

1. Your application, using the web search server tool, receives a response whose stop_reason is pause_turn. Your team has never seen this value and is unsure whether it indicates an error; your handler logs it beside the other failure paths and moves on. Which approach should you take?

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

   Not that one: D 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.Surface the request to the user as declined, because the value reports that the model would not answer this particular prompt at all.A refusal reports stop_reason: "refusal" and is the only case that populates stop_details with a category and explanation. It also arrives as HTTP 200, but it is not resumable.Your answerB.Send the same request again with a larger token budget, because the value reports that the response was cut short part way through its own generation.stop_reason: "max_tokens" means generation was cut off at the configured output ceiling. pause_turn reports a deliberate pause in server-side work, not truncation.Your answerC.Read the error out of the search result block, because the value reports that the tool call itself came back failed part way through this particular request.A failed server tool still reports its own stop reason and puts an error object inside the tool result block's content. pause_turn says nothing about success or failure.The answerD.Send the returned content back in a follow-up request, because the value reports that long-running server-tool work paused and the turn can continue.pause_turn is a stop reason for long-running server-tool work. The turn has not failed and nothing was truncated: sending the returned response content back in a follow-up request lets Claude resume where it paused.

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

2. Your agent on Claude Opus 5 (claude-opus-5) declares web_fetch_20250910 alongside a custom run_command tool. One response has stop_reason: "tool_use" and contains a server_tool_use block for web_fetch with no result block beside it. Your loop treats the missing result as a server failure and retries the whole turn. What change would most effectively resolve the 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.Re-send the assistant content unchanged, as with a pause_turn response.A response that leaves a client tool_use block waiting never carries stop_reason: "pause_turn". Re-sending the content as-is leaves that call unanswered.The answerB.Send one user message of only tool_result blocks, keeping the same tools array.When Claude calls a server tool and a client tool in the same group, the API returns immediately without running the server tool, with stop_reason: "tool_use". Return a user message carrying the client tool_result blocks and keep the same tools array; the API then attaches them to the still-open assistant turn and runs the deferred fetch.Your answerC.Send a tool_result for the srvtoolu_ id alongside the client tool's own result block.Server tools execute on Anthropic's infrastructure. Returning a tool_result for a srvtoolu_ id is rejected; the result block arrives in the next response instead.Your answerD.Re-issue the request without web fetch so the unfinished call is discarded.A resume request that no longer defines the waiting server tool fails with a 400 whose message ends "but no web_fetch tool was provided".

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

3. Your agent on Claude Opus 5 (claude-opus-5) receives a turn holding a web_fetch server_tool_use block with no result plus one client tool_use block. Your client answers with the tool result followed by a short text note asking Claude to be brief. The request fails with a 400 saying the web_fetch tool use was found without a corresponding result block. What is the most likely cause?

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

   Not that one: A 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.

   The answerA.The trailing text block ended the assistant turn, leaving the fetch unresolved.A follow-up user message answering a mixed server-and-client turn must contain nothing except tool_result blocks.Your answerB.The text block has to precede the tool_result blocks rather than follow them.Content placed before the results fails differently, with the message about tool_use ids found without tool_result blocks immediately after. Position is not the fix; the extra block has to go.Your answerC.The client omitted a tool_result for the srvtoolu_ id the fetch produced.Server tools execute on Anthropic's infrastructure and never take a tool_result from the client. The fetch result arrives at the start of the next response instead.Your answerD.The client must set is_error: true on any result returned beside a server tool.is_error: true marks a client tool's own failure. Nothing about a mixed turn requires it, and setting it would not close the pending server tool call.

   Show the full explanation and doc quotes

   A block added after the results, such as text, tells the API the assistant turn is over, which leaves the deferred web_fetch call unresolved and produces exactly this 400.

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