Should Your Bot Force a Tool Call, or Let Claude Decide?

The Four tool_choice Modes

Claude's Messages API accepts a tool_choice field on every request. The default, auto, lets Claude decide on its own whether a turn needs a tool call at all. The alternative is to force one: setting tool_choice to a specific tool name, or to any available tool, tells Claude it must produce a tool_use block instead of a plain text answer, even if Claude would otherwise have just answered in words.

Forcing a call changes more than which tool runs. When tool_choice is any or tool, Claude's response starts directly with the tool_use block, so there is no preceding explanation or reasoning text attached to that turn the way there is under auto. If you want Claude to narrate its choice while still nudging it toward a specific tool, the documented alternative is to keep tool_choice on auto and put an explicit instruction naming the tool in the prompt instead.

Sources: Define tools - Claude Platform Docs.

Not Every Model Accepts a Forced Call

Forcing a tool call is not universally supported. Claude's own documentation lists Claude Opus 5.5, Claude Sonnet 5.5, Claude Fable 5.1 and Claude Mythos 5.1 as models where tool_choice set to any or tool returns a 400 error, while auto and none keep working normally on those same models. The documented substitute is auto combined with strict tool use, which guarantees schema-valid inputs without forcing the call itself, or structured outputs when you need the response in a fixed JSON shape.

Extended thinking adds a second restriction that is independent of which model you're on. Manual extended thinking blocks any and tool outright and only accepts auto or none. Adaptive thinking, the kind that's on by default for some models, is different: it doesn't block a forced call, but a forced call does skip the thinking step, so the response starts with the tool call and carries no thinking block for that turn.

If your bot picks its model dynamically, or you're testing against a newer Claude release, check this restriction before you ship a flow that forces a call. A hard 400 on a turn your bot assumed would succeed is a bad place to discover the restriction for the first time.

Sources: Define tools - Claude Platform Docs.

Forcing a Tool Is Not the Same as Forcing One Call

tool_choice controls whether and which tool Claude requests. The disable_parallel_tool_use flag, set inside tool_choice, limits how many tool calls Claude may request in a single response. By default, Claude may call multiple tools in one response, which is useful for independent lookups but risky when calls have side effects or depend on an order.

The two settings combine predictably: with tool_choice set to auto, turning on disable_parallel_tool_use means Claude requests at most one tool in that response, but may still answer in plain text instead. With tool_choice set to any or tool, the same flag makes Claude request exactly one tool in that response. For a bot that writes to a calendar, a database, or sends a message, the application must still execute the call, verify its result, and deduplicate retries; this flag alone does not guarantee exactly-once effects.

Anthropic's own computer-use and browser-use tools have a stricter built-in rule for this problem: when Claude returns several calls to tools in the same toolset in one turn, the documentation says to run them sequentially in the order they appear and stop at the first failure, with each tool defining what to return for the calls you skip. That's a useful pattern to borrow even for your own custom tools if a batch of calls has to stay ordered and failure-stoppable.

Sources: Define tools - Claude Platform Docs, Parallel tool use - Claude Platform Docs.

Worked Example: A Calendar-Booking Bot

Illustrative example. Say a bot has three tools: check_availability, create_event, and send_confirmation. For most of the conversation, tool_choice stays on auto. The bot might check availability, discuss options with the user in plain text, revise the time, and check again. Forcing a tool call here would strip out the back-and-forth text that makes the conversation usable.

The moment changes at the confirmation step. Once the user says 'book it,' the bot should not be allowed to just reply with a friendly text message and silently skip the booking. This is the turn to set tool_choice to the tool mode, naming create_event directly, with disable_parallel_tool_use on so the model can't also fire off a second, unrelated tool call in the same turn. On models that support forced use, that combination makes one create_event request mandatory in the response. The application must execute it, confirm success, and use a booking idempotency key so a timeout or retry cannot create a second event.

Before shipping that confirmation step, check which model is serving the request. If it's one of the models that rejects forced calls, the fallback is to keep tool_choice on auto, add an explicit system or user instruction naming create_event, and turn on strict tool use so any tool arguments that do come back are schema-valid. This fallback does not guarantee a call: auto may still produce text only. Treat that as no booking, and never show a confirmation until create_event succeeds and its event ID is recorded.

Sources: Define tools - Claude Platform Docs.

A Checklist Before You Force a Call

Forcing a tool call is a narrow tool for a narrow problem: a step where the model must request a specific function in its next response. Execution, success, and retry safety remain application responsibilities. Reach for it sparingly, and verify model support before you depend on it in production.

• Default to auto for anything conversational, exploratory, or where the model answering in plain text is a valid outcome.
• Force tool_choice only at a commitment point: a write, a send, a charge, a booking.
• Check the model's forced-tool-use support before relying on it; some current Claude models return a 400 on any or tool.
• If the model rejects forced calls, fall back to auto plus an explicit instruction naming the tool, plus strict tool use for schema validity.
• Pair a forced call with disable_parallel_tool_use to limit the response to one call, then use idempotency and outcome checks for the side effect.
• Don't force a call under manual extended thinking; it's not supported regardless of model.