Loading ToolBench
Local MCP coordination server for multi-agent workflows
Server has 8 tools with complete input schemas and descriptions. Naming follows verb_noun convention (status_get, task_create, task_claim, etc.). Descriptions are present and contextual (avg ~150 chars), explaining complexity/isolation semantics. However, many parameter descriptions are missing or minimal. task_create has good complexity/isolation guidance, but task_update, task_approve, task_request_changes lack parameter-level detail. No output schemas documented. Error handling is basic (errorResponse helper exists but no recovery guidance in descriptions). No tool annotations (readOnlyHint/destructiveHint). Composition is sound, tools chain logically (create → claim → submit → approve). Missing: per-parameter descriptions for optional fields, output schema documentation, error recovery hints.
Get coordinator config and state summary
PLANNER ONLY: Approve a task that is in review status, marking it done
PLANNER ONLY: Approve multiple tasks at once. More efficient than approving one by one.
Claim a task and set status to in_progress
Create a task. Complexity determines review requirements: simple=no review, medium=verify on completion, complex/critical=planner approval required. Isolation determines whether implementer works in shared directory or isolated git worktree.
PLANNER ONLY: Request changes on a task in review, sending it back to in_progress
Submit a completed task for planner review (required for complex/critical tasks, recommended for medium)
Missing output schema documentation. No tool describes what fields are returned or their types. LLMs cannot plan downstream calls or extract required data (e.g., task IDs for chaining).
Parameter descriptions incomplete or missing. task_approve, task_request_changes, task_update lack descriptions for optional fields (title, description, status, complexity, owner, tags, metadata). LLMs cannot infer when to use optional params.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). status_get should be marked read-only; task_approve, task_request_changes, task_create should be marked destructive. Agents cannot distinguish safe from risky calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Update a task
Error handling lacks recovery guidance. errorResponse() returns plain text with no actionable next steps. E.g., if task_claim fails because task is already claimed, the response should suggest task_update or task_request_changes.
task_approve and task_request_changes descriptions do not explain PLANNER-ONLY restriction or how to verify caller role. Agents may attempt these without authorization, causing silent failures or permission errors.