Loading ToolBench
Single tool 'route' has a generic name that violates verb_noun convention (should be 'route_query' or 'select_server'). Description is adequate (89 chars) but lacks WHEN/WHY guidance. Input schema is present with 4 parameters, all typed, but parameter descriptions are minimal (10-30 chars) and lack format/constraint details. No output schema documented. Tool appears to be a meta-router rather than a domain-specific tool, which is unusual for MCP. No error handling guidance visible.
Route queries to appropriate MCP servers and tools using hierarchical hybrid retrieval
Tool name 'route' is generic and does not follow verb_noun convention. Should be 'route_query', 'select_server', or 'dispatch_to_tool' to clarify intent.
Parameter descriptions are too brief (10-30 chars). 'server_intent' lacks guidance on what constitutes a valid intent. 'session_id' does not explain format or when it is required. Descriptions must be 50+ chars with format/constraint details.
No output schema documented. LLMs cannot plan downstream calls or extract routing results without knowing what fields are returned.
No error handling guidance. If routing fails (no matching server/tool), the tool provides no recovery hints or alternative suggestions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Tool is a meta-router that dispatches to other MCP servers, not a domain-specific tool. This is an architectural pattern mismatch, MCP tools should perform concrete actions (send email, create ticket), not route between servers.