Loading ToolBench
A simple MCP server providing calculator tools without authentication
Two tools with basic schemas and minimal descriptions. Both tools have input schemas with proper types (number, string enum), but descriptions are extremely short (10-14 chars), falling well below the 50-200 char baseline for LLM-optimized descriptions. No output schema documentation. Error handling exists (divide-by-zero check) but lacks recovery guidance. Tool names are action-oriented (add, calculate) but lack verb_noun clarity. No parameter descriptions beyond type hints.
Simple addition tool
Calculator tool with multiple operations
Tool descriptions critically short (10-14 chars). 'Simple addition tool' and 'Calculator tool with multiple operations' lack context for LLM selection. Baseline is 50-200 chars; these are 5-10x too brief.
No parameter descriptions. Zod schema defines types (z.number(), z.enum()) but LLMs cannot read JSON Schema directly. Parameters 'a', 'b', 'operation' lack human-readable descriptions explaining their purpose, constraints, or expected ranges.
No output schema documentation. Tool responses return text content but LLMs have no formal schema describing return structure, field names, or data types. Prevents downstream tool chaining and forces LLM to parse unstructured text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. Divide-by-zero returns 'Error: Cannot divide by zero' but does not guide LLM on next steps (retry, use different operation, ask user). Per pattern:recovery-guide, errors must tell the agent what to do.
Tool naming ambiguity. 'add' and 'calculate' overlap in functionality, both can add. LLM must reason about when to use 'add' vs 'calculate' with operation='add'. Per pattern:tool, each tool should do exactly one thing with unambiguous naming.