Loading ToolBench
MCP server for Evolution of Todo task management with create, read, update, delete, complete, and reschedule operations
This MCP server implements 6 task management tools with generally well-structured schemas and descriptions. Tool naming follows verb_noun conventions (create_task, read_tasks, update_task, delete_task, complete_task, reschedule_task), which is excellent. Descriptions are present and substantive (ranging 85-200 chars), providing context for when to use each tool. Input schemas are complete with proper JSON Schema typing, constraints (enums, minLength, maxLength, minimum, maximum), and descriptions for all parameters. However, there are gaps in output schema documentation (no explicit response schemas visible in the source), missing error handling guidance, and no tool annotations (readOnlyHint/destructiveHint/idempotentHint). The read_tasks tool lacks output pagination documentation despite supporting pagination parameters. Security and audit logging are present in the logging configuration but not explicitly tied to the tools. Overall, the tools are well-defined but lack the error recovery guidance and output schema clarity expected of A-grade tools.
Mark a task as complete. Records completion timestamp and updates status.
Create a new task with description, priority, tags, and due date. Returns the created task with its unique ID.
Permanently delete a task by ID. This action cannot be undone.
Read/list tasks with advanced search, filter, and sort capabilities. Supports pagination for large task lists.
Reschedule a task by updating its due date.
Update an existing task's properties. Only provided fields will be updated.
Output schemas not documented. Tools lack explicit response schema documentation (no visible response_schema or documented return type structure), forcing LLMs to guess what fields are returned. This blocks downstream tool chaining and forces extra discovery calls.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server does not declare which tools are read-only (read_tasks) vs destructive (delete_task) vs write-only (create_task, complete_task, reschedule_task), missing Spec Alignment (2026-07-28). LLMs cannot infer retry safety or impact scope without these hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | <=2025-11-25 | v2 |
No error recovery guidance. Tool descriptions lack actionable error guidance (e.g., 'If task not found, call read_tasks() to discover available task IDs'). Errors are not described as retryable, user-fixable, or fatal. This blocks agent planning on failure.
read_tasks pagination output not documented. Despite accepting page/page_size parameters, there is no description of the response structure (whether it returns total_count, next_page, has_more, or total_pages). This prevents the agent from knowing when pagination is complete.
Destructive tool (delete_task) lacks confirmation pattern. No mention of dry-run or confirmation step. Agents should be required to confirm before permanently deleting a task.
task_id parameter lacks validation guidance in descriptions. While minLength=1 is enforced in schema, descriptions do not explain the format or expected ID pattern (UUID, integer, string slug, etc.), forcing LLMs to guess the format of task IDs returned by create_task.