A todo list MCP server with HTTP transport and interactive widget UI
The todo-app server has basic tool definitions with schemas and descriptions present, but falls short of production-grade quality. Both tools have clear verb-noun naming (add_todo, complete_todo) and Zod-based input schemas with descriptions. However, there are significant gaps in parameter descriptions, missing output schema documentation, no error guidance, and no demonstrated recovery patterns. The tool descriptions are adequate (60-80 chars) but lack context about when to use them or what they return. Parameter descriptions exist but are minimal (e.g., 'The ID of the todo item to mark as complete' lacks clarification on format or how to obtain the ID). Output is structured (tasks array returned via structuredContent), but the structure is not documented anywhere in tool metadata. No validation feedback for invalid inputs is evident. This lands solidly in the C-D range.
Creates a todo item with the given title.
Marks a todo item as complete.
Output schema not documented in tool metadata. The response includes a 'structuredContent' field with a 'tasks' array, but this structure is not declared in the tool definition. LLMs cannot plan downstream calls or extract data reliably without knowing the response schema.
Parameter descriptions are minimal and lack actionable constraints. 'The ID of the todo item to mark as complete (minimum 1 character)' tells the LLM the constraint but not where the ID comes from or what format it has (e.g., 'todo-1', 'todo-123'). This forces the LLM to guess or re-read prior responses.
No error guidance in tool descriptions. If an LLM calls complete_todo with an invalid ID, the tool returns a generic message. The description should hint at recovery: 'If the ID is not recognized, call add_todo first to see the available todos.'
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Tool descriptions are generic and lack context about when to use them. 'Creates a todo item with the given title' does not explain that this is the primary way to add tasks, or what happens after creation (e.g., the item appears in the widget). LLMs benefit from explicit guidance about tool selection.
No documented pagination or limits. The tools do not declare a limit on the number of todos that can be returned or stored. If the todo list grows large, returning all todos in every response will bloat the context window.
No validation feedback for invalid inputs. The tool handler checks for empty title/id and returns a message, but this is not documented in the tool description. LLMs cannot anticipate validation errors and may not know how to self-correct.