Loading ToolBench
Zero-config goal-to-tasks engine for Claude Code (the Atlas engine). FastMCP server wrapping 32 tools for PRD parsing, task generation, validation, and execution orchestration.
29 tools with significant quality gaps. Most have descriptions (good), but parameter schemas are sparse or missing entirely. Many tools lack input parameter descriptions, critical for LLM reasoning. No output schemas documented. Error handling is present (HardenedMCP wrapper catches exceptions), but recovery guidance is minimal. Tool naming is mostly verb-noun (preflight, validate_prd, claim_task), but some are vague (engine_preflight, debrief). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Composition is reasonable, tools are single-purpose, but chaining IDs are not consistently returned. Baseline: 549 production tools average 18-char names and 194-char descriptions; this server averages ~20 chars and ~100 chars, with many descriptions under 50 chars.
Atomic compare-and-swap phase transition with evidence attached.
Append a workflow step to the pipeline history.
Timestamped PRD backup.
Recommend a task count from requirements, team, and scope phase.
Evaluate the gate rules for a phase against the supplied evidence.
Atomically select and mark the next task or subtask in-progress.
Compute Atlas Fleet dependency waves for the selected TaskMaster tag.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields. Tools like current_phase, detect_taskmaster, detect_capabilities, init_project, read_state, debrief return dicts but structure is opaque.
Many parameters lack descriptions. 'tag' appears in 10+ tools with no explanation of what it is or how to obtain it. 'evidence' dict parameters lack structure guidance. LLMs cannot reason about required fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Extract AST-based Python signature context for files.
Return the current pipeline phase plus completed-phase history.
Generate a human-readable debrief of the current project state.
Scan for plugins, skills, and external AI tools; recommend a mode.
Detect taskmaster availability (MCP > CLI > none).
One-call Phase 1: preflight + taskmaster + provider config/detect + capabilities, with a human-presentable summary. Prefer this over the individual probes.
Expand selected or all pending tasks through the resolved backend. When the resolved native backend's ai_ops is "agent", this can return ok=false with agent_action_required instead of doing headless AI work.
Record feedback on task execution or tool behavior.
Generate shell scripts for task execution.
Generate test/verification tasks for the current task set.
Initialise the resolved backend project state.
Load the named PRD template bundled with the plugin.
Log progress event to the pipeline history.
Select the next TaskMaster-compatible task or subtask.
Parse a PRD through the resolved backend. When the resolved native backend's ai_ops is "agent", this can return ok=false with agent_action_required instead of doing headless AI work.
Inspect project state and recommend the next pipeline action.
Rate task complexity through the resolved backend. When the resolved native backend's ai_ops is "agent", this can return ok=false with agent_action_required instead of doing headless AI work.
Alias for current_phase — read-only pipeline state snapshot.
Set a task or subtask status without terminating the MCP host. For status != "done": evidence_ref and reachability are ignored. For status == "done" on a wired/live task: reachability must be provided with verdict in {WIRED, EXEMPT}. Pass the dict returned by the reachability sweep (mcp__atlas-engine__check_gate / sweep_task). Evidence is persisted on the task when provided (any tier).
Record a suggestion for improvement.
Run the deterministic PRD quality checks and return a graded report.
Run the 6 Phase-0 SETUP checks and return per-check pass/fail.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk field is present in metadata but not exposed to LLM. Tools like claim_task, set_task_status, advance_phase are destructive but unmarked, risking accidental misuse.
Vague tool names: 'engine_preflight' (what engine?), 'debrief' (what does it debrief?), 'read_state' (alias for current_phase, redundant). Names should be verb_noun and unambiguous.
No pagination or result limits documented. Tools like compute_fleet_waves, expand_tasks, gen_scripts may return large lists but lack limit/offset/cursor parameters or cap guidance.