Loading ToolBench
A Model Context Protocol server for managing TODO items with support for creating, viewing, and managing tasks.
Three tools with explicit definitions in server.py. Tool naming is verb-based and clear (add_todo, remove_todo, clear_todo), following the verb_noun convention. Descriptions are present but minimal (8-34 chars), falling well below the 10-1024 character baseline and the 194-char average for production tools. Input schemas are visible and properly typed (string for value, integer for item_idx, empty for clear_todo), but lack detailed parameter descriptions. No output schemas are documented. Error handling is present in resource functions (boundary checks returning 'Item not found') but tools themselves lack explicit error guidance. No security annotations (destructiveHint, readOnlyHint) despite two tools being marked DESTRUCTIVE. The prompt feature (create_task) is well-structured with good parameter descriptions and formatted output, but is not a tool and does not affect tool scoring.
Add a TODO item.
Clear all TODO items.
Remove a TODO item.
Descriptions are critically short (8-34 characters) vs. production baseline of 194 chars. Descriptions do not explain WHEN to use each tool, WHAT it returns, or consequences of calling it. 'Add a TODO item' and 'Remove a TODO item' provide zero signal about effects, required parameters, or error conditions.
Parameter descriptions are completely missing. The 'value' parameter in add_todo has only 'The TODO item value to add' (minimal); 'item_idx' in remove_todo has 'The index of the TODO item to remove' (minimal). No guidance on format, constraints, or error cases (e.g., what happens if item_idx is out of bounds?).
No output schemas documented. Tools return free-form strings ('Added TODO item: ...' etc.) without typed field definitions. LLM cannot reliably extract structured data (e.g., the new index) for downstream tool calls or response composition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Destructive tools (remove_todo, clear_todo) lack security annotations (destructiveHint, readOnlyHint). No tool explicitly warns the LLM that calling clear_todo() irreversibly deletes all items. No confirmation/dry-run pattern offered.
Error handling provides no recovery guidance. When remove_todo receives an out-of-bounds index, it returns 'Item not found', but does not suggest the LLM call list_todo() first to discover valid indices, or offer a retry with corrected bounds.
State is stored in a module-level list (`items = []`), which is not thread-safe and will be lost on server restart. No persistence documented. Agents calling these tools expect durable state; in-memory lists break that contract.