Few tools per agent, and tool_choice

Giving an agent every tool “just in case” looks prudent and turns out expensive: with 15 or 18 options, selection degrades, and an agent with tools outside its role tends to misuse them. A synthesis agent that can search the web ends up searching instead of synthesizing.

How many and which

• Few per agent: 4 or 5 tools for its role. If a generalist has 15 covering research, billing and scheduling, use a coordinator with three specialized subagents.
• Scoped tool access: each subagent gets only what it needs for its job.
• One cross-role tool for the frequent case: if the synthesis agent hands control back to the coordinator for every verification and 85% are simple checks (a date, a name), give it a scoped verify_fact. Complex verifications still go through the coordinator. Giving it every search tool would be overdoing it; leaving everything as is means paying the latency.

With few tools that are chosen badly, the first step is still improving the descriptions. With 18, not even the best description makes up for the number.

Least privilege in the interface

Least privilege belongs in the tool’s design, not in the prompt:

• replace fetch_url, which accepts any URL, with a constrained tool such as load_document, which validates that the target is a document and rejects everything else;
• replace execute_sql, which can also write, with get_sales_report(start_date, end_date, region), a fixed read-only query.

An instruction in the prompt guides, but doesn’t prevent; a log detects misuse after it has happened.

The three tool_choice modes

tool_choice defines whether the model may answer with text on that turn:

Mode	What it forces	When
"auto"	Nothing: it may answer in text or call any tool	Conversations where many turns are text (greetings, FAQs)
"any"	Calling some tool, and the model picks which	Pipelines where text breaks everything and you don’t know which tool fits (unknown document type)
{"type": "tool", "name": "..."}	Calling that tool	A mandatory, known step

The question that sorts it all out: is a text-only answer valid on this turn? Yes: auto. No, and it has to choose among several: any. No, and you know which: forced tool selection.

Force only the mandatory step

If extract_metadata must run before any enrichment, force it on the first call and switch back to auto afterwards. Forcing a tool on every request prevents the model from answering and traps the agent in a loop: the classic case is search_kb forced every time, with an agent that never replies.

The usual traps

• Switching to any “so it uses tools more” in an assistant that also chats: it forces a call even for “Hello”.
• Using any when you know which tool: it allows another tool on the step that admits no other.
• Relying on the order of the tools array to impose a sequence.
• Fixing a poor description with tool_choice: if the assistant doesn’t search for recent news, the fix is to say in web_search’s description that it’s required for facts that change over time.

In the exam

Look in the scenario for whether text is allowed and whether the right tool is known. For problems of quantity or permissions, the answer is to distribute and restrict, not to instruct.