How an LLM Chooses the Right Tool
Learn how a model picks between tools, and why clear names and descriptions decide whether it picks well.
Give an agent ten tools and a request, and it has to pick the right one, or none, and fill in the arguments. How does it decide?
There’s no hidden magic. The model sees exactly what you wrote about each tool: its name, its description, and the descriptions of its parameters. It reads them the same way it reads any prompt, and picks the tool whose description best fits the request. Tool descriptions are prompts, and everything from Track 5’s prompt engineering applies.
That makes tool design a writing job. Good descriptions say:
- What it does, specifically: “search the company’s internal documents”, not “searches”.
- What it’s not for: “not for the public web”, so it isn’t confused with its neighbour.
- What the arguments look like: “an order ID such as N-4471”.
- When to hold back: “only send after the user has confirmed the recipient and the text”.
Vague descriptions cause classic mistakes: the internal search used for today’s news, mental arithmetic instead of the calculator (with a wrong answer), or an email fired off before anyone checked it. Too many overlapping tools cause the same confusion, so fewer, well-separated tools usually beat a huge toolbox.
Sometimes the right choice is no tool at all: answering directly, or asking the user a clarifying question first. A well-described toolbox makes those choices easier too.
Key takeaways
- Models choose tools from their names, descriptions and parameter descriptions alone.
- Tool descriptions are prompts: say what it does, what it isn’t for, what arguments look like, and when to hold back.
- Vague or overlapping tools cause wrong picks; fewer, clearly separated tools work better.
- Sometimes the right choice is no tool, or a clarifying question.
Check your understanding
Go deeper (more technical)
Practical guides from model providers recommend treating tool design like designing an interface for a new colleague: clear names, plain-language descriptions, examples of valid arguments, and helpful error messages when a call fails, so the agent can correct itself.
With very large toolboxes (hundreds of tools), some systems first retrieve the few most relevant tool descriptions for the request, the same similarity search as in Track 6, and only show those to the model.
The simulation’s choices are scripted to show typical behaviour.