Loading ToolBench
Task Tree MCP Server — persistent hierarchical task management for LLM agents, with a Claude Code channel bridge and web UI
Conductor has 16 tools with generally clear naming (verb_noun pattern) and comprehensive descriptions (avg 180 chars, within baseline 194). However, critical gaps exist: input schemas are present but lack full type definitions for complex nested objects (plan_proposal, tasks_proposal, tasks_diff); parameter descriptions are inconsistent (some params like 'status' in set_status lack enum constraints); output schemas are entirely undocumented; error handling is minimal (no recovery guidance or categorization). The core task-management tools (create_task, update_task, set_status) are well-described but lack structured output documentation. Agent-facing tools (agent_update, agent_done, plan_proposal) have sparse descriptions and incomplete schemas. Composition is strong (tools chain well via IDs), but schema rigor and error guidance fall short of production baseline.
Signal that agent work was cancelled in response to a cancel control message.
Signal that all agent work is complete.
Report progress on an agent task. Call this as you make progress.
Archive a completed or abandoned plan, hiding it from default listings while preserving its full task tree. Use this when all root-level work is done or the plan is no longer active. Archiving is reversible — open_plan restores it. Plans are never deleted; the history of what was tried and why it succeeded or failed is preserved.
Create a new plan and open it as the active context. Use this at the start of any goal that has multiple steps, unknown complexity, or may require backtracking — before doing any work. A plan is the container for a persistent task tree that survives across sessions, so create one even if you expect to finish in a single session.
Create a new task. Pass parent_id to create a child of an existing task. Omit parent_id only when creating the very first root task on an empty tree. Decompose work into sub-tasks before starting it — not after problems arise. For sequential work, create all sibling tasks upfront with depends_on and status="pending" so the dependency graph is explicit from the start. Prefer smaller, concrete tasks over large vague ones; a task should have a clear completion condition.
Output schemas completely undocumented. No tool returns a documented schema, LLMs cannot predict response structure or plan downstream calls. Affects all 16 tools.
Agent-facing tools (agent_update, agent_done, agent_cancelled, plan_proposal, tasks_proposal, tasks_diff) have sparse descriptions (<60 chars). Descriptions lack WHEN to use, prerequisites, or expected outcomes. Agents cannot determine correct tool selection.
set_status 'status' parameter lacks enum constraint. Description says 'pending, active, completed, or abandoned' but no formal enum in schema. LLMs may hallucinate invalid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Read-only. Returns the context view for a task: the task itself, its parent, siblings, children, and tree-wide stats. Omit task_id to get the root task ("1"). Call this to inspect any task at any time. If no plan is open, it will tell you — use list_plans and open_plan first.
List existing plans on the server. Call this at the start of every new session before creating anything — the work you need may already exist with progress recorded. Returns active plans by default; use status="all" to include archived ones.
Open an existing plan. Use this at the start of a session when resuming prior work. Opening an archived plan automatically restores it to active. Returns the list of root tasks so you can pick up where you left off. All task tools operate on the open plan, so you must open one before doing any task work.
Submit a structured plan proposal with a root task and child tasks.
Create multiple tasks in a single call by providing a map of absolute task IDs to task specs. Use this instead of repeated create_task calls when you want to lay out an entire plan or sub-tree at once. IDs are hierarchical addresses ("1", "1.1", "1.2.3"); parent IDs must exist in the DB or be included in the batch. All tasks are inserted atomically — either all succeed or none do. Focus moves to the shallowest, lowest-numbered task created. Duplicate IDs (already in DB) are rejected; use update_task to modify existing tasks.
Change the status of a task. Provide task_id explicitly. When an approach fails or hits a hard blocker, abandon it with a specific reason before creating an alternative sibling — the reason is visible to sibling tasks and prevents repeating the same mistake. When completing a task, make sure its children are all resolved first. Activating a task with unmet depends_on will return an error; complete the dependencies first.
Collect the results and state from all children of a task into a single consolidated view. Provide task_id explicitly. Call this before marking a parent task complete — it gives you a full picture of what each sub-task produced, what was abandoned and why, and what is still pending. Do not complete a parent task without synthesizing first.
Submit a plan modification diff.
Submit decomposed child tasks for a task.
Record progress on a task. Provide task_id explicitly. Call this after completing meaningful work, not just at the end — intermediate results are valuable if the session ends or an approach fails. Use result for a human-readable summary of what happened. Use state_patch for structured data (file paths, counts, flags, API responses) that this task or downstream sibling tasks will need programmatically. Use notes for freeform observations, corrections, or context — unlike result, notes can be updated at any point and cleared by passing null. Use goal to rename the task (pending tasks only).
Complex nested schemas (plan_proposal.children, tasks_proposal.tasks, tasks_diff.modified) lack full type definitions. 'modified' array has no item schema. Incomplete schemas force LLMs to guess structure.
No error handling guidance. Tools return no recovery hints, error categorization, or actionable next steps. If a task dependency fails or a plan is locked, LLMs have no guidance on retry vs. alternative paths.