Loading ToolBench
Two tools present, both with basic Zod schemas and minimal descriptions. Tool naming lacks action verbs (neither tool name starts with get_, create_, search_, etc.). The 'add' tool is simplistic but reasonable; 'spectrum-tokens' is more complex but has significant documentation gaps. Parameter descriptions exist but are sparse (10-25 chars each, below the 72-char baseline). No output schemas documented. No error handling guidance. The server conflates two concerns (calculator and spectrum) in a single codebase without clear composition boundaries.
Tool names lack action verbs. 'add' should be 'add_numbers' or 'compute_sum'. 'spectrum-tokens' lacks a verb entirely, should be 'search_spectrum_tokens' or 'query_spectrum_tokens'. Verbs at the start of tool names help LLMs infer intent before reading descriptions.
Tool descriptions are missing or trivial. 'add' has no description in the schema. 'spectrum-tokens' has no explicit description parameter. Without descriptions, LLMs cannot determine when or why to select each tool. The rubric baseline requires 10 - 1024 characters; these tools have 0.
Parameter descriptions are too brief and generic. 'Query type (e.g., 'hue', 'name')' is 30 chars (baseline is 72). 'Search value (e.g., 'blue', '240')' puts example values in the description, which LLMs tend to reuse literally rather than adapt to context. Should use enum constraints instead. 'a' and 'b' in the add tool have null descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
No output schemas documented. Callers cannot predict response structure. The rubric requires '100% of A+ tools have documented return types.' Both tools return success/error content, but the shape and fields are not formally documented.
No error handling guidance. If 'spectrum-tokens' receives an invalid query type or malformed color value, the error response does not tell the LLM what to do next (retry, ask user, etc.). The rubric requires 'Error responses must tell the LLM what to do next.'
Parameter 'limit' in spectrum-tokens has no explicit minimum/maximum. Unbounded numbers let LLMs pass absurd values. Should constrain to e.g. 1 - 1000.
Example values embedded in descriptions ('blue', '240', 'hue', 'name'). LLMs latch onto examples and may reuse them literally in real calls, causing failures. Replace with enum constraints for 'query' (hue, name, color) and document valid formats for 'value'.
Two conceptually separate tools (calculator, spectrum) deployed in one server without clear composition guidance. No documentation of which tool to call first, dependencies, or recommended workflows. Violates the single-responsibility principle.