Tool Selection

Give an agent one tool and it will use it. Give it thirty and a new problem appears: working out which one the current step actually needs. Tool selection is that decision — the model reading the available tool declarations and choosing the one whose purpose matches the subgoal in front of it, before it fills in a single argument.

What the choice is made from

• The tool descriptions in the schemas, which are the only evidence the model has about what each tool does.
• The task and the run so far, including the results of earlier calls.
• Whatever the framework filtered in — past a few dozen tools, a retrieval step narrows the candidates before the model ever sees them.

Where it goes wrong
Selection failures are quiet and expensive. Two tools with overlapping descriptions — search_docs and search_wiki — produce a coin flip, and the agent cheerfully retries the useless one until its step budget is gone. A tool that sounds generically helpful gets reached for in situations it was never meant for. And once the declaration list grows, accuracy falls simply because the schemas crowd the context window the reasoning needs. The practical fixes are unglamorous: sharp, mutually exclusive descriptions, dynamic loading so only relevant tools are offered, grouping related calls behind one façade tool, and keeping each Model Context Protocol server scoped to a single coherent capability rather than exposing everything at once.