Loading ToolBench
A stateless HTTP MCP server for managing TODO items with file-based persistence and optional authentication
The TODO server has three well-named, verb-action tools (add_todo_item, list_todo_items, remove_todo_item) with clear descriptions. All tools have input schemas with type definitions and descriptions. However, output schemas are not explicitly documented in the source, error handling is minimal (only remove_todo_item hints at errors in its description), and parameter constraints are not enforced via enums or formal validation. The definitions are functional but lack the LLM-optimization depth and comprehensive error guidance expected of production-grade tools. Average per-tool score: 68.
Add a new TODO item with the given text.
List all TODO items currently stored.
Remove a TODO item by its ID and return the removed item. If the item does not exist, an error field will be returned.
Output schemas not documented. Tools return Dict[str,Any] or List[Dict[str,Any]] but the structure of returned fields (e.g., todo object fields like id, text, created_at, status) is not specified in docstrings or type hints visible to LLMs. LLMs cannot plan downstream operations without knowing what fields will be present.
Error handling is minimal and inconsistent. Only remove_todo_item documents error behavior ('If the item does not exist, an error field will be returned'). add_todo_item and list_todo_items provide no guidance on failure modes. No recovery hints are provided (e.g., 'If a TODO fails to add, try list_todo_items() to verify state').
No parameter validation or constraints. The 'text' parameter in add_todo_item and 'todo_id' parameter in remove_todo_item lack format constraints, length bounds, or character restrictions in descriptions. LLMs may pass empty strings, extremely long values, or special characters without guidance.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
list_todo_items lacks pagination support. Returns all TODOs as a single list with no limit, offset, or cursor. A user with thousands of TODO items would receive all of them, wasting context and token budget. No guidance provided on result limits or pagination patterns.
Descriptions are functional but generic. At 70-75 characters each, they lack context on WHEN to use the tool vs. similar alternatives, or WHAT structure is returned. E.g., 'Add a new TODO item with the given text.' doesn't explain whether the text can contain markdown, links, or if there are length limits.