Loading ToolBench
An MCP server for managing coding project todos with priority, status tracking, and project organization
The server defines 5 tools with basic structure, but suffers from inconsistent naming conventions, shallow descriptions, and incomplete parameter documentation. Tools lack context on when to use them relative to similar operations, error handling is minimal, and output schemas are not documented. The hello_world tool is trivial (READ_ONLY, no real value). CRUD operations on todos are present but lack guidance on idempotency, retry safety, and field relationships. Descriptions average ~30-40 chars (well below the 194 char baseline for A+ tools) and many parameters have descriptions but lack type/constraint detail expected of production tools.
Add a new todo item
Delete a todo item
A simple hello world tool
Update a todo item's details
Update the status of a todo item
Critical: Parameter constraints not expressed as JSON Schema enums/minValue/maxValue. Status values ('pending/in_progress/completed') and priority range (1-5) are documented only in description text, not as schema constraints. LLMs cannot parse free-text constraints reliably, this invites hallucinated invalid values.
High: Destructive operation (delete_todo) lacks confirmation or dry-run step. Agents make mistakes, delete is irreversible and should require explicit user confirmation before execution. No error recovery guidance if deletion fails.
High: Output schemas are not documented for any tool. Code returns string summaries (e.g., 'Added todo ... with ID: todo1'), but the tool definition does not specify what fields or structure the agent should expect. LLMs cannot plan downstream tool calls or extract IDs reliably without documented output schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 11 | - | v1 |
High: Tool descriptions are too short (average ~30-40 chars, well below 194 char baseline for A+ tools). Descriptions lack WHEN to use each tool, dependencies, and usage context. E.g., add_todo vs update_todo distinction is unclear, agents cannot determine which to call without reading code.
Medium: Overlapping tool names (update_todo vs update_todo_status) signal multiple responsibilities for 'update'. Code shows update_todo handles all fields, while update_todo_status handles only status. Names do not make the distinction clear, agents will conflate them.
Medium: Optional parameters (project, priority, tags in add_todo; all update params) lack guidance on semantics. Does omitting an optional param mean 'keep the old value' or 'set to null'? In update_todo, all params are optional, no clear contract on partial vs full updates.
Medium: Error messages in code are descriptive (e.g., 'Invalid status: ... Must be one of: ...'), but tool descriptions do not document error conditions or recovery paths. LLMs do not know what errors are possible or how to respond, no pattern:recovery-guide compliance.
Medium: Idempotency and retry safety not declared. In-memory storage with ID generation (todo{len(todos)+1}) means retries risk creating duplicate todos if the same call is issued twice. Tool descriptions do not state whether tools are idempotent or safe to retry.
Low: hello_world tool adds no functional value and wastes reasoning tokens. Trivial demo tools should be removed from production servers.