Loading ToolBench
Per-env implementation roadmap board for WithVibe — Postgres-backed, with an MCP server the AI orchestrator drives directly.
Strong tool naming (verb_noun pattern throughout) and comprehensive parameter schemas with type definitions. All 10 tools have descriptions and input schemas visible in mcp.js. However, descriptions are inconsistent in depth, some are excellent (get_plan, propose_plan), others lack actionable context (update_plan). Output schemas are not documented. Error handling guidance is absent. Parameter descriptions vary: some are detailed (phase_id, task_id), others are minimal. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Composition is sound, tools chain well (get_plan → set_active_task → complete_task). Security: no secrets in params, but no explicit permission checks visible in tool definitions.
Append a new phase to the roadmap (mid-flight scope expansion). Pass `reason` so the change log explains why.
Append a task to an existing phase. Use when you discover work that wasn't in the original plan. Pass `reason` if it's a scope expansion.
Mark a task done. Pass a 1-line `outcome` describing what shipped / how you verified it. If this was the active task, also pass the next task to make active (or call set_active_task separately).
Remove a phase and all its tasks from the roadmap. Pass `reason` so the change log explains why.
Remove a task from the roadmap. Pass `reason` so the change log explains why.
Return the full implementation roadmap: phases, tasks, statuses, active focus, recent changes. Call this first when you start working in a session so you know what's done and where we are.
No output schemas documented. LLMs cannot predict response structure for downstream tool chaining. E.g., get_plan returns phases/tasks/active_task_id but this is not formally specified.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with Risk levels in comments but not exposed to the MCP client. Agents cannot distinguish safe reads from destructive writes without parsing descriptions.
Error handling lacks recovery guidance. No tool description explains what to do if a phase_id or task_id is invalid, or if a task is already completed. Agents will retry blindly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Replace the entire roadmap with a new structure. Use at the start of a feature (after agreeing with the user on the approach) or after a major re-plan. Pass `reason` so the change log records why.
Mark a task as the one currently in progress (the 'you are here' marker). Call this BEFORE starting work on a task. Automatically flips the task's status to in_progress and its phase to in_progress if not already.
Update the plan's title, summary, or status. Use to rename the roadmap or mark it complete.
Update one or more fields of a task (title, description, notes, status, outcome). Useful for mid-flight corrections or adding context.
update_plan description is vague ('Update the plan's title, summary, or status'). Does not explain when to use it vs propose_plan, or what 'abandoned' status means. Ambiguous descriptions cause wrong tool selection.
set_active_task description mentions automatic phase status flip but does not document the return value or side effects clearly. Agents need to know what fields change and what the response contains.