Loading ToolBench
MCP server exposing worktree-optimiser to coding agents. Run every git worktree of a repo as its own containerised dev server, behind one dashboard.
Strong tool naming (verb_noun pattern throughout) and comprehensive descriptions (avg 180 chars, within 10-1024 baseline). All 12 tools have clear, actionable descriptions explaining WHAT, WHEN, and consequences. Input schemas present for all tools with typed parameters. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are solid but lack format/constraint details (e.g., 'slug' format, branch naming rules). Error handling guidance is minimal; tools do not explain recovery paths or categorize failures as retryable vs fatal.
Materialise a branch as a git worktree and start its dev server container. Returns immediately after the container starts — dependencies install and the server boots asynchronously, so poll probe_worktree until it returns 200. The first run for a branch is slow (cold dependency install).
Destroy a worktree: stop its container, delete the checkout directory, and remove its git worktree entry. This is irreversible — uncommitted work is lost. Only registered when WT_MCP_ALLOW_DESTRUCTIVE=true.
Work out WHY a worktree is not responding, in actionable terms. Reads what the container is actually listening on (via /proc/net/tcp inside it) rather than guessing from the proxy response, so it distinguishes cases that look identical from outside: still installing, nothing listening yet, listening on the wrong port (names the right one), bound to 127.0.0.1 so the proxy can never reach it, exited, or killed for exceeding its memory cap. Call this instead of guessing when probe_worktree is not 200.
What this branch changed relative to its base: commits ahead/behind, files changed in commits, and uncommitted working-tree changes. Use it to confirm whether an edit is committed and whether the running container reflects it.
Bounded tail of a worktree container log, as structured lines with timestamps and stdout/stderr separated, ANSI colour codes removed. Use this to find out why a dev server failed to start or is returning errors.
Output schemas not documented. LLMs cannot predict response structure (e.g., what fields list_worktrees returns, what get_logs returns). This breaks tool chaining and forces agents to guess field names for downstream calls.
Parameter format constraints missing. 'slug' and 'branch' parameters lack format documentation (e.g., allowed characters, max length, naming rules). LLMs may pass invalid values like 'feature/my-branch' if slash handling is undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
List local and remote branches of a project. `checkedOutAt` is non-null when a branch already occupies a worktree — git allows a branch in only one worktree at a time, so those cannot be used for a new one.
List repositories registered with worktree-optimiser. Returns each project id, name, repo path on disk, and the dev command used to run it. Use the id with the other tools.
List every git worktree of a project and its container state. `status` is the container ('running', 'exited', 'absent'), `url` is the hostname route, `localUrl` is a direct loopback port that works regardless of *.localhost resolution, and `dirty` means the checkout has uncommitted changes.
Readiness check through the proxy, exactly as a browser would reach it. `reachable: false` means nothing answered; a 502 or 404 with reachable true means the proxy answered but the dev server did not — usually still starting, or bound to 127.0.0.1 inside the container instead of 0.0.0.0. Poll this after starting.
Stop and start a worktree container. Useful when a dev server is hung or needs to pick up environment changes.
Start (or create) the dev server container for an existing worktree.
Stop a worktree container without destroying it. The worktree directory remains; start it again to resume.
Error handling lacks recovery guidance. Tools do not explain what to do on failure (e.g., 'If probe_worktree returns 502, call diagnose_worktree to determine root cause'). Errors are not categorized as retryable vs fatal.
Destructive tool (delete_worktree) lacks confirmation/dry-run pattern. No mention of a preview or confirmation step before irreversible deletion. Agents may accidentally destroy work.
Pagination not documented for list_* tools. list_projects, list_worktrees, list_branches do not specify if results are paginated, capped, or unbounded. Large repos could return thousands of items, exhausting context.