AnthropicClaude Certified Architect – Foundations2026-102.3 Distribute tools appropriately across agents and configure tool choice
Gate required first steps before enrichment
Completed by the knowledge check
Learning objective
Use any or named-tool forcing for required first-step calls only on supported models and thinking modes; otherwise enforce required order in application control flow.
Core idea
A required first step has two parts: requesting the prerequisite operation and accepting its successful result before dependent work runs. Supported tool forcing can control the first request. It does not establish that extraction succeeded or that enrichment is now authorized.
Use named tool_choice when the first operation is specifically extract_metadata. Use any only when every tool exposed at that stage is an acceptable first operation. If enrichment appears in the same unrestricted menu, any does not guarantee extraction comes first. See 2.3.4 for the four selection modes.
When the chosen model or thinking setting does not support forcing, move the required order into application control flow. Expose prerequisite operations first, withhold dependent tools until the prerequisite result passes validation, and reject dependent execution without trusted prerequisite state. Prompt instructions can guide selection; they do not replace that gate.
How it works
Check the forcing configuration
Anthropic’s tool-use documentation identifies two support boundaries. Manual extended thinking with thinking: {"type": "enabled"} does not support tool_choice types any or tool; these combinations result in an error. Use auto or none instead.
The documentation also names Claude Opus 5.5, Claude Sonnet 5.5, Claude Fable 5.1, and Claude Mythos 5.1 as models that reject any and tool with a 400 error regardless of thinking settings. Changing the prompt or disabling thinking does not make forcing valid for those models. The support check must include the selected model, not only the presence of a thinking field.
Adaptive thinking itself does not block forced tool use. The page identifies Claude Opus 5 and Claude Haiku 5.5 as models with thinking on by default that accept forcing. However, a forced call skips thinking: the response starts with tool_use and contains no thinking block. Do not describe supported forcing as a way to require both deliberation and a particular first call.
These are documented support boundaries, not a beta-header workaround. Select a valid configuration for the workflow. If thinking before tool selection is required, use auto and retain the application gate rather than expecting the forced turn to include thinking.
Force only the initial operation
For a supported configuration, the first-stage request can use this tool_choice object:
{
"type": "tool",
"name": "extract_metadata",
"disable_parallel_tool_use": true
}extract_metadata is an application-defined client tool supplied in the request’s tools array. The nested disable_parallel_tool_use: true means exactly one call under supported named-tool forcing. It is not a top-level request field. This removes ambiguity about both the operation’s identity and the number of initial calls.
Alternatively, {"type": "any", "disable_parallel_tool_use": true} requires exactly one provided tool on a supported configuration. It is appropriate if the first-stage menu contains only prerequisite operations the workflow accepts. If extract_metadata is the only entry, the remaining choice is that operation. If the menu also contains enrich_record, the requirement to extract first is no longer expressed by any.
The application reads the resulting tool_use.name, tool_use.id, and tool_use.input, runs the corresponding operation, and returns a matching tool_result. It validates the extraction result before exposing enrichment tools in a follow-up request. See 1.1.2 for history formatting and 1.4.1 for the general prerequisite gate.
Change tool_choice to the mode needed for the next stage, often auto. Leaving named extraction forcing in every follow-up request keeps requesting extraction rather than expressing a transition to enrichment. The required order belongs to the staged workflow, not to a permanently forced tool.
Preserve order without forcing
For an unsupported configuration, the application constructs a first-stage tools array containing only eligible prerequisite tools and uses tool_choice: {"type": "auto"}. Claude can still respond without a call. That response does not satisfy the prerequisite and must not advance the workflow to enrichment.
If the prerequisite is deterministic and its inputs are already available, the application can execute its own extraction function before the model turn and supply the validated result as context. This is an application-owned operation, not a Claude-selected call. If the model must supply extraction arguments, stay in the prerequisite stage until an acceptable call and result exist, or return an explicit incomplete outcome.
Before running enrich_record, the dispatcher checks trusted extraction-success state for that record, using the prerequisite gate taught in 1.4.1. Restricting the menu guides selection; this execution check rejects an ineligible request even if its model-generated arguments claim extraction is complete. Forced or not, the workflow reaches enrichment only through a validated extraction result.
When an attempted client-tool call is rejected, return its correlated tool_result with is_error: true and a brief explanation. If several calls arrive, every call still needs a result. Anthropic’s parallel-tool documentation explicitly permits marking a skipped call as not executed with is_error: true. Do not execute enrichment merely to avoid producing an error result.
Key distinctions and trade-offs
First requested call versus first successful stage: Forcing selects a requested operation. Only its accepted result establishes completion. An extraction error leaves enrichment blocked.
Supported model versus supported thinking mode: Both checks matter. Some models reject forcing regardless of settings; manual extended thinking rejects forcing even on an otherwise eligible model. Adaptive thinking acceptance does not mean thinking appears in the forced response.
Single call versus required order: disable_parallel_tool_use controls how many calls the response requests. The application gate establishes whether the next stage is eligible. Serializing calls alone does not verify prerequisite success.
Schema conformance versus sequencing: For models that reject forcing, the documentation suggests auto with strict tool use when schema-valid inputs are the goal, or structured outputs when the response itself must follow a fixed JSON shape. strict: true constrains tool inputs to the schema; neither mechanism requires a call or proves that another operation already succeeded.
Architecture / decision scenario
A structured-data extraction service must extract document metadata before enrichment. On a forcing-supported configuration, the service exposes extract_metadata, uses named tool_choice, and nests disable_parallel_tool_use: true. It executes the requested extraction and validates the returned metadata before constructing the enrichment-stage request with auto.
A deployment using Claude Sonnet 5.5 cannot reuse that forced request: the documented result is a 400 error. The architect keeps the same stage gate but uses auto and a prerequisite-only menu. If Claude answers directly, the service reports that extraction remains incomplete instead of treating the text as a completed first step.
A separate configuration enables manual extended thinking. It also uses the gated auto path because any and named tool are unsupported with that setting. An adaptive-thinking configuration that accepts forcing can use the forced path, but the team accepts that its forced response has no thinking block.
In every deployment, the dispatcher rejects enrich_record until trusted extraction state exists for the record. Failed extraction returns a correlated error and leaves the gate closed. The model-specific selection path varies; the required extraction-before-enrichment behavior remains enforced by the application.
Common exam traps
- Using
anywith extraction and enrichment both eligible in the first menu. - Assuming every model accepts named-tool forcing.
- Assuming manual and adaptive thinking have identical forcing restrictions.
- Expecting a forced call to contain a preceding
thinkingblock. - Unlocking enrichment when extraction was requested rather than validated.
- Treating
strict: trueor structured outputs as a guarantee of required order. - Leaving named forcing on every follow-up request, which keeps requesting extraction and never reaches enrichment.
Where the exam guide differs
The exam guide recommends forced selection to ensure a tool is “called first” and presents any as a required-call mechanism without model or thinking qualifications. The product documentation limits forcing as described here. In an exam item, preserve the prerequisite intent, but choose application-controlled staging when the stated model or thinking mode rejects forcing.
What to remember
Check model and thinking support before choosing any or named tool. Use a prerequisite-only menu and disable parallel calls when exactly one initial call is required. Validate the result before follow-up work. If forcing is unavailable, keep auto selection behind an application-owned prerequisite gate.
Knowledge check
An extraction service on Claude Opus 5, without manual extended thinking, must run extract_metadata on each document before enrich_record. Under auto, Claude occasionally skips extraction. Which configuration enforces the order?
extract_metadata by name on every request in the conversation{"type": "any"} with both tools available on the first requestenrich_record from the service’s tools for the whole conversationauto after validationauto once a validated result exists. Forcing on every request keeps requesting extraction and never reaches enrichment, any with both tools eligible can start with enrich_record , and removing enrichment orders nothing — it drops the second step.The same workflow moves to Claude Sonnet 5.5, and the forced first request now returns a 400 error. How should the team keep extraction before enrichment?
tool_choice for extractionauto with an extraction-only menu and an enrich_record gateauto with a system instruction to extract firststrict: true on extract_metadata and expose both tools under autoany and tool regardless of thinking settings, so the order moves into application control: a prerequisite-only menu, a dispatcher that refuses enrichment without trusted extraction state, and a direct text answer treated as an incomplete stage. A prompt instruction guides selection without enforcing it, and strict: true constrains inputs to the schema without requiring a call or an order.The dispatcher receives an enrich_record call whose input includes "metadata_extracted": true, but no trusted extraction result exists for that record. What should it do?
is_error: true resulttool_use still needs a result — a skipped call is marked not executed with is_error: true — and running enrichment to avoid an error defeats the gate.On a supported model, a forced extract_metadata call is returned and executed, but its result fails the application’s validation. What should the workflow do next?
enrich_record , since the forced first call has taken place{"type": "any"} with both tools on the next requeststrict: true for enrich_record and continue the workflowany available with both tools, or tightening enrichment’s input schema, does nothing to establish that extraction succeeded.References
- Anthropic, Define tools
- Anthropic, Parallel tool use
- Anthropic, Handle tool calls
- Anthropic, Strict tool use
- Anthropic, Structured outputs
- Anthropic, Claude Certified Architect – Foundations Exam Guide