Loading ToolBench
A production-shaped MCP server template: timeouts, concurrency ceilings, a real error boundary, and logs you can trace.
Three tools with complete schemas and descriptions, but naming lacks action verbs and descriptions are minimal (10-60 chars, below the 50-200 char LLM-optimized baseline). All parameters have types and descriptions. No output schemas documented. Error handling present but generic. Tool names are descriptive but 'summarise_lengths' uses British spelling inconsistently with 'fetch_record'. Parameter descriptions are adequate but lack format/constraint details (e.g., 'seconds' has no min/max guidance despite default=60).
Look up a record by key. Returns found=false when absent; that is not an error.
Sleeps, to demonstrate the server's timeout behaviour.
Return per-item character counts and a total for a list of strings.
Tool names lack clear action verbs. 'summarise_lengths' and 'slow_operation' do not follow verb_noun pattern (get_, create_, update_, delete_, search_, list_). LLMs rely on names to infer intent before reading descriptions.
Descriptions are too short (10-60 chars vs. 50-200 char LLM-optimized baseline). 'Sleeps, to demonstrate the server's timeout behaviour' lacks context for when/why to call the tool. Descriptions should state WHAT, WHEN, and any prerequisites.
No output schemas documented. LLMs cannot plan downstream calls or extract data without knowing return structure. Tools should declare what fields are returned.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Parameter 'seconds' in slow_operation lacks min/max constraints. Description should state 'float, 0.1 - 600 seconds' to prevent LLMs from passing absurd values (e.g., 999999).
fetch_record's 'simulate_outage' parameter is a testing artifact, not a production tool feature. Exposing test-only parameters confuses LLMs about the tool's real purpose and wastes reasoning cycles.