Loading ToolBench
MCP server for managing todos with Supabase backend, supporting todo CRUD operations, resource listing/reading, and API key authentication
This server demonstrates solid tool design with proper naming conventions, complete schemas, and clear descriptions. All four tools follow verb_noun naming patterns (create-todo, update-todo, list-todos, delete-todo). Each tool has a non-empty description between 34-64 characters. All input schemas are properly defined with JSON Schema, including type constraints, enums, regex patterns for dates, and min/max bounds on numeric fields. Parameter descriptions are present and explain what each field controls. However, there are gaps in output schema documentation (not visible in the provided code), limited error guidance in descriptions, and missing tool annotations for risk categorization. The server uses HTTP transport and demonstrates stateless request handling appropriate for the current MCP spec.
Create a new todo item with optional priority and deadline
Delete a todo item permanently
List todos with optional filtering
Update an existing todo item
Output schemas not documented in tool definitions. The code shows input schemas for all tools, but tool descriptions do not specify what fields are returned (e.g., does create-todo return the created todo object with id, text, priority, deadline, completed flag, timestamps?). LLMs cannot plan downstream operations without knowing response structure.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). The FEATURES array indicates toolAnnotations=false. create-todo and update-todo are write operations; delete-todo is destructive; list-todos is read-only. These risk classifications should be explicit in tool definitions to help agents reason about side effects and retry safety per MCP spec 2026-07-28 tool annotation patterns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Error handling lacks recovery guidance in tool descriptions. Descriptions state what each tool does but do not explain what errors can occur or how the LLM should handle them (e.g., 'If deadline format is invalid, call will fail with HTTP 400'). Per the recovery-guide pattern, error responses should guide the agent on retryability and next steps.
delete-todo description is minimal (21 chars: 'Delete a todo item permanently'). While it exceeds the 20-character floor, it lacks actionable detail for LLM decision-making. Best practice per the rubric (194-char average for A+ tools) would add context like 'Permanently removes a todo from the database. This action cannot be undone. Use with caution.'
No confirmation step or dry-run for irreversible operations. delete-todo directly removes data with no confirmation or preview capability. Per the confirmation-request pattern, destructive operations should support a 'confirm_delete' parameter or separate confirmation tool to prevent accidental data loss from agent mistakes.
Pagination limit not capped in list-todos description. The schema shows maximum=100, but the description does not state this limit or explain that agents should use it to prevent large result sets from exhausting context windows. Per mxe:enforce-result-limits, tool descriptions should explicitly state result caps.