A research assistant is given two independent, read-only tools, `get_stock_price` and `get_weather`. Given a user question that needs both pieces of information, Claude's response comes back as a single assistant turn containing two separate `tool_use` content blocks, one for each tool, rather than one tool call followed by a second turn requesting the next. According to Claude's tool-use API, what must the calling application do before sending the next request to Claude?
- Execute only the first tool_use block, since Claude's API silently discards any additional tool_use blocks appearing in the same assistant turn
- Merge both tool_use blocks' arguments into a single combined tool call before executing anything, since the API does not allow two separate tools to be invoked from one turn
- Execute both tool calls, in whichever order or concurrency suits the tools since the API does not prescribe an order, then return one tool_result block for each tool_use block, all together in the next message, each matched to its call by the tool_use_id
- Wait for a separate follow-up request from Claude naming the second tool before running the get_weather call, since only one tool result can be returned per message
Why C? And why not the others?
Correct answer: C. Execute both tool calls, in whichever order or concurrency suits the tools since the API does not prescribe an order, then return one tool_result block for each tool_use block, all together in the next message, each matched to its call by the tool_use_id
By default a single assistant turn can contain several tool_use blocks when the requested tools are independent; the API does not mandate a fixed execution order for multiple calls in one turn -- concurrent, sequential, or any mix is acceptable depending on what the tools do -- but whatever order is chosen, every tool_use block must get a matching tool_result in the same next user message, tied together by tool_use_id so Claude can attribute each result correctly. The option describing silently discarding extra blocks is wrong: nothing in the API drops additional tool_use blocks, and ignoring one would leave that request unanswered. The option describing merging both calls' arguments into one combined call is wrong: each tool_use block names a specific, separately defined tool with its own arguments, and conflating them would corrupt both requests, since the two tools take entirely different parameters. The option describing waiting for a second follow-up request is wrong: batching multiple tool_result blocks into a single message is exactly what the API supports, so there is no need to split them across separate round trips.
Source: Anthropic, 'Parallel tool use' (platform.claude.com/docs/en/agents-and-tools/tool-use/parallel-tool-use): 'the response...can contain several tool_use blocks in a single assistant turn'; 'return one tool_result for each tool_use block...Match each result to its call with tool_use_id'