Tool distribution & tool choice
Distribute tools appropriately across agents and configure tool choice.
This subtopic (2.3) sits in Tool Design & MCP Integration (D2) on Anthropic's Claude Certified Architect — Foundations (CCA-F) exam. The bank holds 23 practice questions here — 5 easy, 12 medium, and 6 hard — with 5 free to try, answers and explanations included. 3 of the free questions are below; the rest are in the practice stream.
What the exam tests here
- restricting subagent tool sets to prevent cross-specialization misuse
- too many tools degrades tool selection reliability — 18 tools vs 4-5
- tool_choice options — auto, any, forced named tool selection
- scoped tool access — agents get only tools needed for their role
Free practice questions: Tool distribution & tool choice
A subagent in the support system should handle refunds but must never trigger escalate_to_human. What is the correct approach to enforce this restriction?
Show answer & explanation
Correct answer: B. Exclude escalate_to_human from the subagent's tool list at initialization
Excluding escalate_to_human from the subagent's tool list ensures it cannot call that tool — tool availability is the deterministic enforcement point. 'Add a system prompt instruction...' relies on probabilistic model compliance, not enforcement. 'Log a warning...' detects misuse but does not prevent it. 'Let the orchestrator intercept...' allows the call to occur before cancellation, which is not restriction.
Your support agent must always begin a new conversation by calling get_customer to verify identity before any other tool runs. Currently, on the very first turn the model occasionally responds with a clarifying question instead of invoking get_customer, then either of the other tools, depending on the customer's stated request. You want the first turn to be structurally constrained to a get_customer call. Which tool_choice configuration best enforces this on turn one only?
Show answer & explanation
Correct answer: B. Set tool_choice to {"type": "tool", "name": "get_customer"} on turn one and revert to auto for subsequent turns.
Forcing the named tool on turn one and reverting to auto satisfies the constraint that get_customer specifically must run first while still allowing free tool selection afterward. Setting tool_choice to any forces a tool call but does not pin which one — the model could still pick lookup_order or escalate_to_human. The auto-with-system-prompt approach relies on probabilistic compliance. Holding the forced named tool for the whole session blocks lookup_order and process_refund from ever being chosen.
A customer support system has a refund subagent and an escalation subagent. The refund subagent has access to all tools including escalate_to_human and cancel_account. Support managers report that the refund subagent occasionally escalates cases it should handle itself. What design change best addresses this?
Show answer & explanation
Correct answer: C. Restrict the refund subagent's tool list at initialization to only the tools needed for refund operations
Restricting the refund subagent's tool list at initialization to only refund-relevant tools removes escalate_to_human from its available options, making erroneous escalations structurally impossible. 'System prompt instruction' is probabilistic — the tool remains available and could still be selected. 'Confirmation step before escalation' reduces frequency but doesn't prevent it. 'Monitoring and alerts' is reactive, not preventive.
2 more free questions on this subtopic in the practice stream, plus 18 in the full bank. Keep practicing →