A parks and recreation assistant defines client-side tools for facility lookup and program registration. When the application returns tool output to the model, what must each tool_result block carry?
Select an answer to reveal the explanation.
Short Explanation
Every tool_use block arrives with its own id, and the answer has to come back wearing that same stamp. It is a coat-check ticket, not a place in line.
Full Explanation
The Messages API pairs tool calls with their results by identifier, not by position in the content array. That single design choice is what makes concurrent execution safe for a parks assistant firing a facility-availability lookup and a program-registration check inside the same turn.
When the model emits a tool_use block it assigns that block an id, and the matching tool_result must echo it in its tool_use_id field. Because the pairing is explicit, the application can execute tools in parallel and return results in whatever order they finish. The practical requirement is that the orchestrator carries the id through its own execution layer instead of discarding it on the way to the tool.
Relying on emission order assumes an ordering guarantee the API does not use for matching, and concurrent execution offers no such guarantee anyway. Generating a fresh application-side identifier breaks the pairing outright, since the model cannot associate an id it never issued. Substituting the tool's name collides the moment the same tool is called twice in one turn, and identifiers are not reserved for server-side tools.
Exam caveat: the identifier is opaque and scoped to the turn—do not persist it as a durable key in facility or registration records. Operational check: issue a turn with two parallel lookups, deliberately return the results in reverse order, and confirm the model still attributes each answer to the right call.