A todo application MCP server that manages todo items stored in a JSON file
Two tools with minimal documentation. save-todo has a generic description ('Save, create, make, generate, a todo to a file') that conflates multiple intents and lacks clarity on when to use it. get-todo description is missing entirely from visible code. Both tools have basic input schemas with type strings and descriptions, but lack output schema documentation. No error handling guidance, no parameter constraints (enums, ranges), and no indication of idempotency or side effects. Parameter descriptions are minimal (e.g., 'UUID of the todo' does not explain format or constraints). No tool annotations (readOnlyHint, destructiveHint). The schema for save-todo includes three required parameters (todo, time, uuid) but provides no guidance on how to generate or validate UUIDs, or what time format is expected.
Get todo list from a file
Save, create, make, generate, a todo to a file
get-todo has no visible description in source code. LLMs cannot determine when or why to select this tool.
save-todo description is vague and conflates multiple intents ('Save, create, make, generate'). Does not state that this tool modifies state or is idempotent. LLMs cannot reliably decide when to call it.
No output schemas documented for either tool. LLMs cannot plan downstream calls or extract required data (e.g., does get-todo return a single Todo object or a list?).
Parameter 'time' in save-todo lacks format specification (ISO 8601? Unix timestamp? Natural language?). Parameter 'uuid' lacks validation guidance (UUID v4? v1? custom format?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
No error handling guidance. If get-todo is called with a non-existent UUID, what is returned? An empty result? An error? LLMs have no recovery path.