Hierarchical Tool Selection
Organise tools into a tree of categories so the agent first picks a branch and then a specific tool within it.
Problem
A flat tool list collapses in two ways past roughly 30 tools. Token cost grows linearly in description length × tool count. Selection error rises non-linearly as the model confuses similar tools or misses the right one entirely. Worse, permissions and ownership are flat too — there is no scope at which a team can say 'these are the billing tools, this team owns them'. The agent ends up either under-tooled (some tools dropped) or unreliable (the model picks wrong).
Solution
Group tools into named categories (billing, identity, scheduling, search, code, files). At the top level the agent sees only the category names with one-line descriptions. After it picks a category, it sees the tools in that branch. Permissions can scope per branch (this user can read but not write billing tools). For very large catalogs nest the tree further. The cost is one extra decoding step at the top; the saving is paying full tool descriptions only for the chosen branch.
When to use
- Tool catalog exceeds roughly 30 tools.
- Tools naturally cluster into domain categories.
- Permissions or ownership can scope per category.
Open the full interactive page →
Diagram, neighbourhood map, code examples, related patterns and full provenance.