An MCP server that provides tools for managing a todo list with create, list, complete, delete, and update operations
This server has 6 tools with basic definitions but significant quality gaps. All tools have names and descriptions, but descriptions are minimal (10-27 chars, well below the 50-200 char production baseline). Schemas are present but sparse, only 2 parameters across all tools, no enums or constraints, no documented output schemas. No error handling guidance, no security considerations, and no parameter validation rules documented. The descriptions are too terse to guide LLM tool selection effectively ('Create a new todo item' vs 'Creates a new todo item and returns the created todo object with id, task, completed status, and timestamps'). No documentation of output structure or field meanings. Composition is reasonable (one concern per tool), but implementation lacks production-grade polish.
Clear all completed todo items
Complete a todo item
Create a new todo item
Delete a todo item
List all todo items
Update a todo item
All tool descriptions are under 20 characters and provide no selection context. 'Create a new todo item' does not explain when to use this vs alternatives, what the output contains, or any prerequisites. LLMs cannot reliably select tools based on these descriptions.
No documented output schemas. The tool implementations return JSON objects (todos with id, task, completed, createdAt, completedAt fields) but these are not declared in the tool definitions. LLMs cannot plan downstream calls without knowing what fields to expect.
TODO-List and TODO-ClearCompleted have empty input schemas ({}). While correct, the descriptions should explain what data they return and when to call them for discovery. Currently they read as placeholder implementations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Parameter descriptions are minimal (7-12 chars). 'The id of the todo item to complete' is functional but lacks constraints, format guidance, or error recovery hints. Production descriptions state format (UUID vs generated), optionality, and what to do if invalid.
No error handling guidance. The implementation calls getTodoById/deleteTodo/etc. and returns generic success/failure messages. If an ID is not found, the tool returns 'Todo completed: undefined' instead of 'Todo ID not found. Call TODO-List to see available todos.' Agents cannot self-correct.
Destructive operations (TODO-Delete, TODO-ClearCompleted) have no confirmation or dry-run capability. An agent mistake will silently delete todos without warning. Production implementations require a confirm step or explicit 'force' parameter.
No tool annotations for risk categorization. The server declaration includes capabilities but not tool-specific annotations. Risk levels are declared in the evaluation (WRITE, DESTRUCTIVE, READ_ONLY) but not visible in the tool definitions, LLMs cannot infer which tools are safe to retry or auto-execute.
No pagination or result limiting on TODO-List. If the user has thousands of todos, the tool returns all of them, wasting tokens and risking context window exhaustion. Production tools accept limit and offset/cursor parameters.