Loading ToolBench
A Haskell implementation of the Model Context Protocol (MCP) server and client with support for resources, tools, and prompts
Two tools defined with basic schemas and minimal descriptions. Both tools have proper JSON Schema with type definitions and required fields, but descriptions are extremely terse (10-28 chars, well below baseline of 194 chars). Parameter descriptions are completely absent, no descriptions for 'text', 'operation', 'a', or 'b' parameters. No output schemas documented. No error handling guidance. No composability hints. Naming is acceptable but descriptions fail to explain WHEN to use each tool or WHAT to expect back.
Performs basic arithmetic
Echoes text back
Tool descriptions are critically under-specified. 'Echoes text back' (17 chars) and 'Performs basic arithmetic' (26 chars) are far below the 194-char baseline. No explanation of WHEN to use each tool, WHAT it returns, or HOW its output integrates with other tools.
ALL parameters lack descriptions. The 'text' param in echo has no description. The 'operation', 'a', and 'b' params in calculator have no descriptions. LLMs cannot infer that 'operation' is an enum or that 'a' and 'b' are operands, they rely on explicit descriptions.
No output schemas documented. What does echo() return? Just the echoed string, or an object with metadata? What does calculator() return, a number, or {result, calculation_type}? LLMs need this to plan downstream tool calls and extract values correctly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
No error handling or recovery guidance. If calculator receives invalid operation or divides by zero, what happens? The agent has no guidance on what to do next. Error responses should state: 'Invalid operation, must be one of: add, subtract, multiply, divide' and 'Cannot divide by zero. Try different operands.'
Parameter constraints not documented. calculator's 'operation' is an enum, but the description does not state the valid values. 'a' and 'b' are numbers, but have no documented range, precision, or special case handling (e.g., divide by zero).
No composability documentation. If an upstream tool returns a number (e.g., a price), can that number be passed directly to calculator's 'a' or 'b' params? This should be explicit in parameter descriptions to guide multi-step planning.