A consumer business runs a Customer Support Resolution Agent on the Claude Agent SDK. Over eighteen months the single coordinator session has accumulated thirty-four tools: the four support tools get_customer, lookup_order, process_refund and escalate_to_human, plus inventory, logistics and analytics tools mounted from three further MCP servers. A review of 600 transcripts shows the agent picking a tool that cannot answer the customer's question in 11 percent of turns, most often reaching for a logistics shipment tool when the customer is disputing a charge. First-contact resolution has fallen to 68 percent against a target of 80 percent. Which change most effectively addresses the reviewed behaviour?
- AKeep every tool mounted on the coordinator and add a numbered decision table to the system prompt describing which of the thirty-four tools applies to each category of customer request.
- BSplit the work into specialist subagents, each defined with a scoped allowedTools list holding the few tools its task needs, and have the coordinator delegate to them through the Task tool. Correct
- CSet tool_choice to any on every request so the coordinator is obliged to call a tool rather than answering from its own memory, and log each selection for weekly review.
- DPaste the full documentation for all three mounted MCP servers into the project CLAUDE.md so that every tool description is available in context at the moment of selection.
Why A is wrong: Documenting the mapping is reasonable practice and may shave a few points off the error rate, but it leaves all thirty-four tools competing for attention on every request. It buys probabilistic compliance where reducing the candidate set gives a structural improvement.
Why B is correct: Selection reliability degrades as the candidate set grows, so the durable fix is to shrink the set each agent chooses from. Scoping allowedTools per AgentDefinition means a billing specialist is never offered a shipment tool, which removes the observed error rather than discouraging it.
Why C is wrong: Forcing a call is tempting because it sounds like tighter control of tool use, but the logged fault is choosing the wrong tool, not failing to call one. Obliging a call from the same crowded set leaves the misselection untouched and stops the agent replying in prose when that is correct.
Why D is wrong: Richer descriptions do help a thin tool definition, but these definitions are not thin and the volume added here dilutes attention further. Treating a larger context as a cure for attention spread across thirty-four similar tools makes the selection problem worse.