A Model Context Protocol server for managing TODO items with TypeSpec-generated tool definitions
Five tools with clear verb-noun naming (addTodo, listTodos, deleteTodo, completeTodo, updateTodoText) and basic descriptions. All tools have input schemas with typed parameters and descriptions. However, descriptions are minimal (10-50 chars), lacking context on when to use each tool, prerequisites, or state-modification warnings. Output schemas are not documented. No error handling guidance, no pagination support for listTodos, and no idempotency hints for destructive operations. Schemas are present but sparse, parameters lack format constraints, ranges, or validation rules. This is a functional but minimal implementation typical of demo/tutorial servers.
Add a new TODO item with the given text
Mark a TODO item as completed
Delete a TODO item by its ID
List all TODO items, optionally filtered by status
Update the text content of a TODO item
Descriptions are too brief (10-50 chars) and lack context. Missing WHEN to use each tool, state-modification warnings for destructive ops, and dependency hints. LLMs cannot reliably select the right tool without richer descriptions.
No output schemas documented. LLMs cannot plan downstream calls or extract return values without knowing the structure of responses (e.g., does addTodo return {id, text, status} or just {id}?).
deleteTodo and completeTodo lack confirmation or dry-run support. Irreversible operations should warn the LLM or require explicit confirmation to prevent accidental data loss.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
listTodos lacks pagination (limit, offset, cursor) and result count. Returning all todos in one call risks context window exhaustion and violates the pattern of capping results at 20-50 items.
No error handling guidance. Errors like 'Todo with id X not found' are bare messages. Should guide LLM on recovery: 'Todo not found. Call listTodos() to see available IDs.'