Loading ToolBench
Production-grade routing classifier that maps natural queries to specific API endpoints based on keyword overlap analysis.
The GenPark Query Intent Router defines a single tool, route_query, with a reasonably complete schema and moderate documentation. The tool name follows verb_noun convention (good), has a description, and parameter types are specified. However, the description is generic and lacks LLM-optimization details about when/why to use it. The output schema is implicit (not formally documented in the tool definition itself), and error handling is minimal. The implementation shows basic input validation but no actionable error messages. The tool is READ_ONLY (routing, no state mutation), which is appropriate. Overall, this is a functional routing utility but falls short of production-grade definition quality expected for A/B tier tools.
Classifies query based on keyword overlap ratio and targets dispatch endpoints.
Output schema not formally documented in tool definition. The tool description does not specify what fields the LLM should expect in the response (matched_intent, confidence_score, dispatch_url). LLMs cannot plan downstream calls or validate responses without explicit output documentation.
Description lacks LLM-optimization details. The description 'Classifies query based on keyword overlap ratio and targets dispatch endpoints' does not explain WHEN to use this tool, what happens after routing, or what the confidence_score means. A 55-character description is too brief for agent decision-making.
Parameter 'registry' lacks validation guidance. The description states it is 'List of intent definitions with keywords and target endpoints' but does not specify: what happens if keywords array is empty? What if target_endpoint is malformed? What order matters? LLMs will pass arbitrary registry structures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Error handling is silent, not actionable. When max_score < 0.2, the tool returns a fallback result with confidence_score=0.0, but provides no guidance to the LLM about what went wrong or how to recover. The LLM cannot distinguish between 'no good match' and 'invalid registry' and doesn't know whether to retry, refine the query, or escalate.
No input validation with clear error messages. Empty user_query is caught, but invalid registry (e.g. missing 'intent' or 'target_endpoint' fields, empty keywords) will silently produce incomplete or incorrect routing. The code uses .get() without defaults, risking KeyError in downstream processing.