A tool router is the component that takes an agent's request, decides which tool and operation should serve it, and runs that call — so the agent describes a job rather than naming a specific API.
The agent still reasons and still decides that an external action is needed. The router's job starts after that: match intent to a capability, validate the input against that capability's schema, execute it, and return a normalized result and error shape regardless of which upstream service did the work.
Why it matters
Routing is what lets a catalog grow without the agent's context growing. If every capability were its own tool definition, a large catalog would be unusable — the schemas alone would fill the context window. A router lets the agent load a search operation and an execute operation, and reach everything else through them.
It also normalizes failure. Upstream services fail in their own dialects; a router can present one typed error object with a stable machine-readable code, so an agent branches on the code rather than parsing prose.
Note the name collision: Composio shipped a feature historically called "Tool Router" (now Sessions), and toolrouter.ai is a different company from toolrouter.com.
Tool routing is not model routing
A model router (OpenRouter is the best-known) chooses which language model answers a prompt. A tool router chooses which capability acts on the world. They solve different problems and are not substitutes — see tool routing vs model routing.
How ToolRouter does it
discover({query: "analyze a website"}) returns matching tools and skills with their schemas; use_tool(tool, skill, input) runs one. The catalog held 254 tools and 1,345 skills as of 3 September 2026, and none of that is loaded at connect time.