Loading ToolBench
Dead simple MCP (Model Context Protocol) server for exposing your app functions to AI agents
This MCP server has severe definition quality gaps across all dimensions. Most tool descriptions are minimal placeholder text ('Tool: <name>'), parameter descriptions lack context and constraints, and schemas have critical deficiencies. Of 14 tools examined, 8 use generic 'Tool: <name>' descriptions that provide zero LLM guidance for tool selection. Parameters frequently lack descriptions or use vague text. No output schemas are documented. Error handling is absent from descriptions. The codebase shows validation logic exists (validateArgsAgainstSchema, validateToolArguments in mcpServer.js), but tool definitions themselves do not reflect this rigor. This is typical of early-stage, example-focused code rather than production-ready tooling.
Tool: addTodo
Tool: clearAllTodos
Tool: clearCompleted
Tool: deleteTodo
Simulates a destructive operation — requires console approval
Echoes the message back
Tool: getTodoById
Tool: getTodoStats
Generic placeholder descriptions dominate. 8 of 14 tools use 'Tool: <name>' which provides zero context for LLM tool selection. Descriptions must explain WHAT the tool does, WHEN to use it, and what it returns.
Parameter descriptions are missing or trivial across todo tools. E.g. getTodos has 'status parameter, one of 'all', 'completed', 'pending'' but no guidance on when to use each status or default behavior. Parameters lack minimum/maximum ranges and dependency documentation.
No output schemas documented. Tools return results but descriptions do not explain the response structure. LLMs cannot infer what fields to expect or how to chain tool calls. E.g. getTodoById returns an object but the schema of that object is undocumented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 38 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Tool: getTodos
Returns server info as JSON
Tool: hello
Tool: toggleTodo
Tool: updateTodo
Waits N milliseconds then returns
additionalProperties: true in most schemas allows arbitrary parameters to pass validation. This defeats schema enforcement and can cause silent failures or unexpected behavior.
Destructive operations (deleteTodo, clearCompleted, clearAllTodos) lack confirmation flow. Code shows tool.confirm support exists (mcpServer.js line ~180), but no tools declare it. Users/agents risk accidental data loss.
camelCase vs snake_case naming inconsistency. Test tools (echo, wait, get_info) use snake_case; todo tools (addTodo, getTodos) use camelCase. LLMs expect consistent naming conventions.
No error handling guidance in descriptions. Validation code exists (validateArgsAgainstSchema) but tool descriptions do not explain what errors are possible or how to recover. E.g. getTodoById(id=999) will fail but description gives no recovery hint.
Missing field naming consistency in response context. If updateTodo returns an object with fields, those field names must match what other tools accept as parameters. No documented response schema means LLMs cannot verify this.