Loading ToolBench
A remote MCP server providing calculator tools without authentication
This server has critical definition quality gaps. While the two tools are explicitly registered with Zod schemas in src/index.ts, the parameter descriptions are entirely absent (all marked null in the parsed input), and tool descriptions are generic one-liners lacking actionable context for LLM selection. The naming is acceptable but not optimal for agent discoverability. Schema definitions exist but lack documentation of output structure. No error handling guidance, no parameter constraints beyond type, and no indication of idempotence or side effects.
Simple addition tool
Calculator tool with multiple operations
All parameter descriptions are null/missing. Parameters 'a', 'b' in 'add' and 'a', 'b', 'operation' in 'calculate' have no descriptions, violating the requirement that every parameter must have a description explaining what it controls. This forces LLMs to infer meaning from names alone, which is error-prone.
Tool descriptions are extremely brief (13-45 chars) and lack actionable context. 'Simple addition tool' does not explain when to call 'add' vs 'calculate', what the return format is, or any prerequisites. Descriptions should be 50-200 characters and answer: What does it do? When to use it? What does it return?
Output schemas are not documented. The tool implementations return Content objects with type 'text' and a string result, but there is no formal documentation of the return structure visible to the LLM. LLMs need explicit output schema documentation to plan downstream calls and extract data correctly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
The 'calculate' tool has an 'operation' enum parameter (add, subtract, multiply, divide) but the 'add' tool duplicates the add operation. This creates tool redundancy and forces the LLM to reason about which to call, wasting reasoning cycles. Consider retiring 'add' or clarifying the distinction.
No error handling guidance. The 'calculate' tool catches division by zero and returns an error message as plain text, but there is no documented recovery path or categorization (retryable vs user-fixable vs fatal). LLMs need explicit guidance on what to do when errors occur.
Parameter constraints are minimal. Numeric parameters 'a' and 'b' have no documented min/max ranges, precision requirements, or examples. Without these constraints, LLMs may pass absurd values (e.g., 1e100 for a field expecting an integer between 1-100).