Tool Router
The agent examines a request, selects the appropriate tool from an available set, formats the call with typed arguments, and processes the result. This is the fundamental tool use pattern — the agent decides which tool to use and how to call it.
In modern APIs, this is implemented via function calling — the model natively outputs structured tool calls (JSON with function name and arguments) rather than free text.
Structure
The agent may call one tool or multiple tools sequentially (using each result to inform the next call). Tool descriptions in the prompt or API schema guide the model's selection.
How It Works
- Describe tools — each tool has a name, description, and typed parameter schema
- Classify intent — agent determines what capability is needed
- Select tool — agent picks the best-matching tool
- Format call — agent generates structured arguments matching the tool's schema
- Execute — runtime calls the tool and returns the result to the agent
- Process — agent incorporates the result into its reasoning
Tool selection quality depends on:
- Clear descriptions — unambiguous tool names and parameter docs
- Non-overlapping tools — distinct purposes minimize confusion
- Manageable set size — models degrade with 20+ tools (consider sub-routing)
Key Characteristics
- Universal pattern — every tool-using agent implements this
- Model-native — modern APIs support function calling as a first-class feature
- Selection errors — wrong tool selection leads to failures or incorrect results
- Schema enforcement — typed parameters prevent malformed calls
- Scales with tool count — but selection quality degrades with very large tool sets
When to Use
- The agent needs to interact with external systems (APIs, databases, services)
- You have a defined set of tools with distinct purposes
- Tasks require real-world data or actions beyond the model's knowledge
- You need structured, typed interactions with external services
- Any agent that does more than just generate text