Loading ToolBench
One list every AI tool you use can write to — across every project, before the work is worth a ticket. Local-first, self-hostable.
Docket is a STDIO-based todo management MCP server with 10 tools covering list, add, edit, complete, delete, claim, unclaim, export, import, and stats operations. Most tools have solid schemas with type definitions and enum constraints, and descriptions are present across all tools. However, several critical gaps limit score: (1) Missing output schemas, no documentation of what fields are returned by any tool, forcing LLMs to guess what data is available after a call; (2) Tool naming lacks verb-noun clarity, 'claim' and 'unclaim' are vague compared to 'mark_as_claimed' or 'mark_as_in_progress'; (3) Parameter descriptions are present but often minimal (under 20-30 chars for many); (4) No error handling guidance, tools describe happy paths but omit recovery instructions; (5) No evidence of idempotency, confirmation steps for destructive ops, or per-item success/failure reporting for batch operations. The server targets a narrow domain (todo management) and executes it competently, but lacks the depth and LLM-orientation of production-grade tools.
Add a new todo
Claim a todo (mark as being worked on by this agent)
Mark a todo as done
Delete a todo
Edit an existing todo
Export todos in JSON or Markdown format
Import todos from JSON or Markdown format
List todos in the current workspace or across all workspaces
No output schemas documented for any tool. LLMs cannot determine what fields a successful response contains, what pagination structure list() returns, or how to extract IDs for downstream tool chaining.
Tool names lack action verb clarity. 'claim' and 'unclaim' are vague, LLMs conflate them with other stateful operations. Rename to 'mark_as_claimed', 'mark_as_unclaimed', or 'assign_to_agent' / 'unassign_from_agent' to clearly signal intent.
No error handling guidance. Error responses do not tell LLMs what to do next. E.g. if delete fails because the todo does not exist, the response should suggest 'Call list() to verify the todo ID' rather than a bare error code.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
Show statistics about todos
Unclaim a todo (mark as no longer being worked on)
Destructive operations (delete) lack confirmation/dry-run support. Agents make mistakes, delete should offer a confirm step or require explicit 'force=true' to prevent accidental data loss.
list() lacks pagination documentation. No indication whether results are capped at a limit, what happens if there are 1000+ todos, or how to fetch the next page. Cannot scale to large workspaces.
Parameter descriptions are minimal. E.g. 'workspace' in list() says 'Filter to a specific workspace (optional)' but does not explain: Is workspace name or ID? What workspaces are available? What's the default behavior if omitted? LLMs must guess.
No indication whether operations are idempotent. If an agent retries 'complete' due to transient failure, does it send a 200 or error? If an agent retries 'add' with the same title, are duplicates created? LLMs need this to plan retries safely.
stats() lacks both description and input schema documentation. No indication what statistics are returned, whether filtering is possible, or how to interpret the output.
Tool chain dependencies are not documented. E.g. 'claim' requires an ID from list(), but this dependency is not stated. LLMs must infer multi-step sequences rather than being explicitly guided.
No batch variants. Agents cannot bulk-add todos, bulk-edit, or bulk-claim. This forces N sequential calls and wastes tokens/latency when the LLM wants to create 5 todos at once.