Loading ToolBench
Task management MCP server for tracking work across sessions. Tasks are scoped to the current workspace directory.
The server provides 6 well-structured task management tools with consistent naming patterns and reasonable descriptions. All tools follow verb_noun naming (task_create, task_list, task_get, task_update, task_add_note, task_delete). Input schemas are fully defined with types and descriptions for all parameters. However, output schemas are not documented in the source code, and several parameter descriptions lack specificity around constraints, enums, and error recovery guidance. Error handling and field mapping details are absent from the visible code.
Add a timestamped note to a task. Use for progress updates, decisions, blockers, or any information worth recording. Notes are append-only and cannot be edited or deleted.
Create a new task. Use for tracking multi-step work, bugs, features, or any unit of work that needs to be done.
Delete a task and all its subtasks
Get full details of a task including subtasks, tags, and dependencies
List tasks in the current workspace. Returns top-level tasks by default (not subtasks). Use parent_id to list subtasks of a specific task.
Update an existing task. Only specified fields are changed. IMPORTANT: Always set status to 'done' when a task is complete. Use task_add_note to add progress notes.
Output schemas not documented in source code. No evidence of response format documentation for any tool. The rubric requires documented return types for A+ tools (100% of A+ tools have documented return types).
Enum constraints not declared for status and priority parameters. task_create and task_update accept 'status' (todo, in_progress, done, blocked) and 'priority' (low, medium, high, critical) but lack formal enum definitions. Free-form strings invite hallucinated values.
task_delete description is too brief (51 chars). Does not explain consequences, irreversibility, or warn about cascading deletes. No confirmation/dry-run pattern visible for destructive operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Parameter descriptions lack constraint details. Example: 'max_notes' in task_add_note states 'default: 5, 0 for all, max: 10000' in description but no formal min/max constraints in schema. 'assignee' field does not clarify whether it accepts names, emails, or IDs, forcing LLM guesswork.
No error recovery guidance in descriptions. task_update notes 'will fail if dependencies are not yet done' but provides no guidance on how the LLM should respond (retry, check dependencies first, ask user). Error responses should tell the LLM what to do next.
No pagination parameters visible for task_list despite being a list operation. Large task lists could exhaust context; no limit, offset, or cursor parameters shown. Rubric requires pagination for tools returning lists.
Task composition chains not clear. If task_get returns full task details, which fields are included? Are subtask IDs, dependency IDs, tag arrays returned to enable chaining with task_update? No visible output schema definition.