Loading ToolBench
MCP server with Server-Sent Events (SSE) transport and math/prompt tools
Single tool 'math-tool' has moderate quality issues. Schema is present and properly typed using Zod, but the description is generic and lacks LLM-optimized guidance. Parameter descriptions exist but are minimal (10-20 chars each). No output schema documentation. Tool naming does not follow verb_noun convention (should be 'calculate_arithmetic' or 'compute_math'). No error handling guidance to help LLM recover from invalid inputs. Tool is READ_ONLY which is correct, but lacks rich context for when/why an agent should call it.
Performs basic arithmetic operations (add, subtract, multiply, divide) on two numbers
Tool name 'math-tool' violates verb_noun naming convention and lacks action clarity. LLMs infer intent from names, 'math-tool' is vague. Should be 'calculate_arithmetic' or 'compute_result' to signal what happens when called.
Tool description is only 123 characters and lacks LLM-optimized guidance. Does not answer: What does it do? When should the LLM call it instead of alternatives? What are the constraints? Current description is generic: 'Performs arithmetic operations (add, subtract, multiply, divide) on two numeric inputs'. Missing WHEN (use case context) and HOW (error cases, edge cases).
Parameter descriptions are too brief and lack format guidance. 'num1': 'First numeric operand (will be parsed as float)' is only 50 chars and does not specify constraints (range, precision). 'num2': 'Second numeric operand (will be parsed as float)' is identical.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 5 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No output schema documentation. Tool returns { content: [{ type: 'text', text: `Result: ${result}` }] } but this is never declared in the tool definition. LLMs need to know what fields to expect in responses. Per pattern:tool, 'Document the output schema.'
Error messages in implementation are descriptive ('Division by zero is not allowed', 'Invalid input: num1 and num2 must be valid numbers') but tool definition and description give LLM NO guidance on how to recover. Per pattern:recovery-guide, errors must tell the LLM what to do next. No indication that invalid input is user-fixable.
Parameters num1 and num2 accept strings and parse to float. This is loose typing. No documentation of acceptable input formats (e.g., '123', '-45.6', scientific notation?).