Tool Selection
Twenty tools in one list makes the model pick search when it needed sql_query.
A toolbox: the right wrench, not every wrench on the bolt.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Overview
Scroll inside the frame to explore · use + / − to zoom up to 200%
Scroll inside the frame to explore · use + / − to zoom up to 200%
Two-stage pick
Scroll inside the frame to explore · use + / − to zoom up to 200%
Optionally pick the tool first, then ask for arguments.
Key Takeaways
- 1.Selection is choosing which tool to call — or none. Good descriptions beat extra tools; too many tools confuse the model.
- 2.Route cheap: small model or rules can pick the tool, big model fills args. Wrong tool is often a prompt/schema problem, not a smarter model.
- 3.Limit the visible set. Write descriptions that say when not to use the tool.
- 4.For large catalogs, retrieve candidate tools or use a router. Log wrong picks as eval cases.
Learn elsewhere
- →Tool Registry
- →Dynamic Tool Loading
Real Example
Scenario
Catalog of 80 tools. Router keeps 4 candidates for 'invoice status'. The main model only sees those 4.
What you would do
In Tool Calling & Function Calling, apply Tool Selection to this scenario: Catalog of 80 tools. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
Fewer, clearer toolsDescribe when not to useRouter for large catalogsLog wrong picks
Cheat Sheet
Quick recap
quick ref- •Right wrench
- •Descriptions matter
- •Too many tools hurt
- •Route then fill
Common Mistakes
- ✕Dumping 100 tools into every call
- ✕Names like do_stuff and handle_it
- ✕No eval set of 'which tool for this question'