Loading ToolBench
A multi-tool MCP server running on Cloudflare Workers with calculator, time conversion, web fetching, sequential thinking, and knowledge graph memory capabilities
This server has 6 tools with mixed quality. Most tool descriptions are minimal (10-50 chars), well below the 194-char production baseline. Parameter descriptions are sparse, many lack meaningful context. Schema definitions are present but lack depth. The tools themselves are READ_ONLY and pose low risk, but the definitions fall short of what LLMs need for robust tool selection and parameter inference. No error recovery guidance. The server uses proper Zod validation (visible in code), which is a positive, but the MCP interface itself lacks the descriptions and context needed for production use.
Simple addition tool
Calculator tool with multiple operations
Convert time between timezones
Fetch web content and convert to markdown
Get current time in a specific timezone
Sequential thinking for complex problem-solving
Tool 'add' has only 18-char description ('Simple addition tool'), falls far below 194-char production baseline. Lacks context for LLM tool selection and parameter inference.
Parameters in 'add' tool lack descriptions entirely. Schema shows z.number() for 'a' and 'b' but provides no guidance on meaning, constraints, or valid ranges. LLMs cannot infer parameter semantics from bare type names.
Tool 'calculate' has enum constraint for operation but parameter descriptions are empty. Descriptions must explain what each operation does and when to use this tool vs. 'add' (which does the same thing differently).
Tool naming: both 'add' and 'calculate' with operation='add' perform the same function. This creates ambiguity for LLMs and violates single-responsibility pattern. Consolidate into one canonical tool or clearly document when to use each.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool 'sequential_thinking' has 10 parameters with minimal descriptions. Parameter names are self-explanatory but lack guidance on valid ranges, when to use each, and how they interact. Undocumented parameter relationships are a major source of LLM errors.
Output schemas are not documented. Tools return text responses in {content: [{type: 'text', text: '...'}]} format, but the MCP tool definitions do not advertise what fields to expect. LLMs cannot plan downstream tool chains without knowing output structure.
Tool 'fetch' accepts 'max_length' and 'start_index' but no guidance on pagination semantics or limits. LLMs cannot reason about breaking large responses into chunks without explicit guidance on limits and cursor behavior.
Error handling in code includes user-friendly messages (e.g., 'Cannot divide by zero', 'Invalid timezone') but no recovery guidance. Error responses tell the user what went wrong but not what to do next, LLM cannot plan recovery.