An agent has two tools: `check_inventory` and `charge_customer`. A checkout flow must always check inventory and confirm the item is in stock before it charges the customer for it -- charging first, or charging without checking, would be a serious bug. Given a user request that could plausibly trigger both tools, what does setting `tool_choice: {"type": "auto", "disable_parallel_tool_use": true}` help prevent, and what does it NOT by itself guarantee?
- It prevents Claude from requesting both tools together as simultaneous parallel calls within one turn -- so `charge_customer` cannot be issued in the same batch as `check_inventory` before that inventory result is even known -- but it does not by itself guarantee Claude will always call `check_inventory` before `charge_customer` across separate turns; the calling application's own logic still has to enforce that ordering
- It guarantees Claude will always call `check_inventory` before `charge_customer` in the correct order across every future turn, because the parameter itself encodes a dependency graph between the two named tools
- It prevents Claude from ever calling `charge_customer` under any circumstances, since disabling parallel tool use removes any tool involved in a financial action from consideration entirely
- It has no effect on tool-calling behavior at all and only changes how the response is formatted for logging purposes
Why A? And why not the others?
Correct answer: A. It prevents Claude from requesting both tools together as simultaneous parallel calls within one turn -- so `charge_customer` cannot be issued in the same batch as `check_inventory` before that inventory result is even known -- but it does not by itself guarantee Claude will always call `check_inventory` before `charge_customer` across separate turns; the calling application's own logic still has to enforce that ordering
Setting `disable_parallel_tool_use: true` restricts Claude to at most one tool call per turn, which stops it from ever bundling `check_inventory` and `charge_customer` together as simultaneous parallel calls in a single response before the inventory result is available to inform the charge decision. It does not, by itself, encode any notion of which tool must come before which across separate turns -- it only limits how many calls can go out together in one turn, so the calling application still needs its own logic (such as only exposing `charge_customer` once a successful inventory check has already happened) to actually enforce the required ordering. The option claiming it guarantees correct ordering across every future turn is wrong because the parameter carries no dependency information between specific named tools; it is a blanket limit on concurrency, not a sequencing rule. The option claiming it blocks `charge_customer` from ever being called is wrong because the parameter only limits how many tools can be requested at once, not which tools are eligible to be called at all. The option claiming it has no effect on tool-calling behavior is wrong because it directly changes how many tool calls Claude can request in a single turn, which is a behavioral effect, not merely a formatting or logging change.
Source: Anthropic, 'Tool use with Claude' (platform.claude.com/docs/en/agents-and-tools/tool-use/overview) -- example request setting `tool_choice: {type: "auto", disable_parallel_tool_use: true}` with the comment 'Ask for at most one tool call per turn.'