Loading ToolBench
A task management MCP server that allows users to add, list, mark tasks as done, and retrieve task information
TodoMCP is a basic in-memory task management server with three tools. Tool naming follows verb_noun patterns (add_task, list_tasks, mark_done), which is good. Descriptions exist but are minimal (10-34 chars), falling below the production baseline of 194 chars. Parameters have type definitions and basic descriptions, but lack constraints (enums, ranges, format specifications). No output schemas are documented, responses are inferred from code (strings or lists). Error handling is ad-hoc with generic fallback messages. No pagination, no input validation beyond type hints, no recovery guidance. The server uses in-memory storage, making it unsuitable for production. Resources and prompts are included but add minimal value without proper schema documentation.
Add a new task with an optional due date
List all tasks with their status
Mark a task as completed
Tool descriptions are too brief (10-34 chars vs. baseline 194 chars). Descriptions lack WHEN to use, prerequisites, and return type documentation. 'Add a new task with an optional due date' does not explain what side effects occur or what is returned.
Output schemas are not documented. list_tasks returns a List[str] of formatted strings, but the agent cannot parse structure, it must parse English text like '1. Buy milk (Pending) [Due: 2024-12-25]'. No schema defines fields like id, task, status, due_date.
Parameters lack constraints (enums, ranges, format specs). 'due' accepts any string with no format validation. 'task_id' has no bounds checking. No validation guidance for LLMs on what constitutes valid input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Error handling is minimal. mark_done returns 'Task with ID {task_id} not found.' but does not guide the agent on what to do next (e.g., call list_tasks() to find valid IDs). No recovery guidance.
No pagination support. list_tasks() returns all tasks as a flat list. If 1000 tasks exist, the entire list is serialized, wasting tokens and degrading LLM reasoning.
In-memory storage with no persistence. Tasks are lost on server restart. Not suitable for production use; acceptable only for demo/testing.
Resources (todo://task/{task_id}, todo://all, todo://today) lack documented schemas. Return types are plain strings, not structured. Resource 'todo://today' does not actually filter by today's date; it returns all tasks.