Loading ToolBench
Task management MCP for Claude Code with dependency resolution, on top of Obsidian
Task Manager MCP has well-structured tool definitions with complete schemas and descriptions for all 17 tools. Naming follows verb_noun convention (create_task, list_tasks, update_task, etc.). Most parameters include type definitions and descriptions. However, descriptions vary in quality, some are verbose and include implementation details rather than LLM-optimized guidance. Parameter descriptions occasionally lack format constraints (e.g., date format YYYY-MM-DD is stated but not enforced via schema). Error handling is minimal; tools do not provide recovery guidance. Output schemas are not formally documented. The server lacks tool annotations (readOnlyHint, destructiveHint) despite having clear read/write semantics.
Add a dependency to an existing task. Runs cycle detection.
Append a comment to a task under the ## Comments section.
Mark a task as Blocked with a reason string.
Return all Ready tasks that are currently blocked by unfinished dependencies.
Apply multiple update_task calls in one round trip. Each entry must contain `task_id` plus any subset of the fields update_task accepts (title, status, priority, assignee, project, area, due, tags, body). Unknown keys are rejected so a typo doesn't silently no-op.
Mark a task Done. Sets completed date, records transition, and returns unblocked/promoted dependents.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools like create_task, update_task, complete_task, add_blocker are clearly destructive/write operations, but lack explicit annotations to guide agent planning and prevent unsafe retries.
Output schemas not documented. Tools return structured data (task objects, lists, trees) but the response schema is not formally specified. LLMs cannot plan downstream calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Create a new task. Auto-generates ID (T-001, T-002, ...). title: Task title (required) priority: P1-P4 (default P3) assignee: actor handle from your vault's `.task-manager/config.yml` (default 'me'; falls back to 'me'/'agent'/'claude' when no config). Legacy 'claude' is a synonym for 'agent'. status: Backlog/Ready/In Progress/Done/Blocked/Cancelled (default Backlog) project: Project name or [[wikilink]] (optional) area: Area like 'Backend', 'Frontend' (optional) due: Due date YYYY-MM-DD (optional) tags: Comma-separated tags (optional) blocked_by: Comma-separated task IDs (e.g., 'T-001,T-002') body: Task description / acceptance criteria in markdown (optional)
Get full details of a task including body content.
Read status-change audit log entries, newest first.
List tasks with optional filters. status: filter by status (e.g., 'Ready', 'In Progress') assignee: filter by any actor configured in the vault (legacy 'claude' is treated as 'agent') priority: filter by P1/P2/P3/P4 project: filter by project name (partial match) tags: comma-separated; task must carry every listed tag (exact match, case-sensitive)
Return tasks assigned to a given actor, grouped by overdue/due-today/in-progress.
Return the next workable task. Selection criteria: status == 'Ready', assignee matches (if provided), all blocked_by tasks are Done or Cancelled, sorted by priority (P1 first) → due (sooner first) → created (older first).
Transition a task from Backlog/Ready to In Progress. Validates that all blockers are Done/Cancelled.
Build a dependency tree rooted at task_id. direction='blockers' walks downstream (what task_id is waiting on), direction='dependents' walks upstream (tasks whose blocked_by contain task_id).
Flip a checklist item in a task body. Index is 1-based.
Update fields on an existing task. Only provided fields are changed. Pass empty string to leave a field unchanged. For list/optional fields that you want to *clear* rather than ignore, pass the literal sentinel "-": - blocked_by="T-001,T-002" replaces the dependency set; "-" clears it. Cycle detection runs against the proposed value, and missing ids are rejected, mirroring create_task / add_blocker. - completed="2026-05-07" sets the completion date; "-" clears it. complete_task is still the right tool for marking Done — this parameter exists for cleanup and backfill, not the happy path.
Validate the entire task dependency graph for cycles, missing blockers, and other inconsistencies.
Minimal error handling and recovery guidance. Tools do not provide actionable error messages. E.g., if a task_id is invalid or a blocker creates a cycle, the error response should guide the LLM on what to do next (e.g., 'Call list_tasks to find valid task IDs').
Parameter descriptions lack format constraints. Date parameters (due, completed) state 'YYYY-MM-DD' in text but do not enforce via JSON Schema pattern or format keyword. This invites LLM hallucination of invalid dates.
Descriptions for simple tools (get_task, block_task, blocked_tasks) are under 70 characters and lack context on when to use them vs. similar tools. E.g., get_task says 'Get full details of a task including body content' but does not explain when to call it vs. list_tasks.