Loading ToolBench
A specialized Model Context Protocol server that provides TODO management functionality.
Tiny TODO MCP is a STDIO-only server with basic tool definitions. All 4 tools are explicitly registered with names, descriptions, and Zod schemas (TodoCreateSchema, TodoItemSchema, TodoSearchSchema). Tool names follow verb_noun convention (update_todo, add_todo_item, get_latest_todo, search_todo). However, descriptions are verbose and contain procedural guidance rather than clear WHAT/WHEN/HOW intent statements. Parameter descriptions are minimal but present. No output schemas are documented, only generic 'content: [{ type: text }]' responses visible. Error handling returns error text but provides no recovery guidance. Input validation exists (Zod schemas) but no enum constraints on the string parameters. The server does not use tool annotations (readOnlyHint/destructiveHint/idempotentHint), which would clarify that update_todo and add_todo_item are destructive write operations.
SINGLE ITEM ADDITION: Adds just one new TODO item to the existing list. Use this when you want to add a specific task without modifying the rest of the list. Input should be just the task text without any formatting.
Retrieves the latest TODO task with formatting prompt.
Searches for a TODO by text and returns it with formatting prompt.
COMPLETE REPLACEMENT: Replaces the entire TODO list with new content. Use this when you want to send a completely formatted TODO list. Previous versions are preserved as history. Input should be a full, formatted TODO list with all items.
Procedural descriptions instead of intent-driven ones. All 4 tools use imperative instructions (e.g., 'COMPLETE REPLACEMENT', 'SINGLE ITEM ADDITION', 'Use this when') rather than declarative statements of what the tool does and when an LLM should select it. This violates the pattern:tool-description rule: 'Write descriptions as if prompt-engineering. State WHAT the tool does, WHEN to use it, and any prerequisites.'
No output schemas documented. All 4 tools return a generic content array with text type, but the actual structure of returned TODO objects, search results, and prompt text is never specified. LLMs cannot predict what fields are available downstream, forcing guesswork and extra parsing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 8 | - | v1 |
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools update_todo and add_todo_item are write operations with side effects (create revisions), but are not marked with destructiveHint. get_latest_todo and search_todo should have readOnlyHint. These annotations are required by the 2026-07-28 spec and help agents understand retry safety and caching implications.
Error handling provides no recovery guidance. When errors occur (e.g., 'An error occurred: [message]'), responses include the error text but no actionable next steps. Per pattern:recovery-guide, errors must tell the LLM what to do: 'User not found. Try search_users() with a partial name.' Current errors give the agent nothing to act on.
No result limits or pagination on search_todo. The description states 'Searches for a TODO by text and returns it' but does not specify max results, pagination support, or limits. If search matches many items, context window could be exhausted. Per mxe:enforce-result-limits, 'cap results at a reasonable limit (e.g. 20-50) and offer pagination.'
update_todo violates idempotent-operation pattern. Calling with the same content twice creates two separate revisions. Per pattern:idempotent-operation: 'Make tools produce the same result on repeated calls with the same input. Agents retry on ambiguous failures, non-idempotent tools risk duplicate side effects.' This tool should detect if content is unchanged and return success without creating a revision.
Parameter descriptions for search_text lack format constraints. No mention of min/max length, case sensitivity, or search semantics (substring vs. regex vs. fuzzy). Per review:param-validation-rules: 'Describe the expected format, range, and allowed values directly in the parameter description.'