Loading ToolBench
Automatically synchronize Git worktrees with remote branches - perfect for multi-branch development workflows
This MCP server exhibits strong definition quality with well-structured tool descriptions, clear parameter documentation, and comprehensive schemas. All 9 tools have explicit descriptions (ranging from 80-450 chars, well within the 10-1024 baseline). Parameter descriptions are consistently present and detailed. Input schemas are defined with proper type information and validation constraints (e.g., branch filters, path resolution). However, there are systematic gaps in output schema documentation, while handlers return structured Zod schemas (detectContextOutputSchema, listWorktreesOutputSchema, etc.), these schemas are not embedded in the tool definitions accessible to clients. This creates a blind spot where LLMs cannot see the return type structure before calling the tool. Error handling is present but inconsistent in actionability, some errors reference specific recovery steps (e.g., 'TARGET_EXISTS when the target path exists on disk'), while others lack guidance. Tool composition is excellent: tools are single-responsibility (detect vs. list vs. create vs. update), output includes IDs for chaining (worktree path, repoName context), and idempotency is addressed (sync and initialize are idempotent). Parameter naming is verb-clear and resource-specific (create_worktree, update_worktree, get_worktree_status). Naming does NOT use the verb_noun pattern consistently, tools like 'detect_context' and 'load_config' fit; but 'get_worktree_status' vs. 'list_worktrees' shows minor inconsistency (get vs. list). No critical security gaps: no secrets exposed as parameters, and the server is READ_ONLY except for worktree mutations (create/update/sync/initialize), each properly documented with WRITE risk. Defaults are conservative (e.g., detailed=false, includeSize=false, push=true for create). Missing: output schemas are not visible in the MCP tool definitions, only inferred from handler code.
Worktree-mode only; clone-mode repos error here. Create worktree for a branch. Existing branch (local/remote) = checkout. New branch = create from baseBranch + push to origin (default). baseBranch required only for new branches — pass defensively if unsure. push=false opts out. Preconditions: repo initialized (auto-runs). Never moves, trashes or deletes an existing directory: errors with code TARGET_EXISTS when the target path exists on disk but is not a registered worktree (clean it up manually or via sync). Errors with code BRANCH_FILTERED when branchInclude/branchExclude/branchMaxAge exclude the branch, since sync prunes worktrees
Detect sync-worktrees structure from path (default: CWD). Reads .git, resolves bare repo, walks up to auto-load sync-worktrees.config.{js,mjs,cjs,ts}. Returns: configuredRepositories (server-wide loaded-config inventory; independent of params.path), bareRepoPath, allWorktrees, siblingRepositories, currentWorktreePath, configPath, capabilities {available,reason}, notes. Lean configuredRepositories entries are mode-discriminated: clone → {name, mode:'clone', checkoutPath, isCurrent}; worktree → {name, mode:'worktree', worktreeDir, isCurrent}. detailed=true adds repoUrl, branch?, sparseCheckout?, localReady, plus bareRepoDir for worktree mode. Use at session start or to bootstrap from unknown checkout.
Detailed status for one worktree: dirty files, unpushed commits, stashes, upstream gone, ops in progress. Returns: status + divergence {ahead,behind} + resolved path.
Initialize a repository for sync-worktrees: create bare repo, add remotes, fetch all remote branches, and initialize the object store lock. Idempotent: safe to run on already-initialized repos. Errors when repoUrl is invalid, network is unreachable, or the bare repo exists with a mismatched remote.
Output schemas not visible in tool definitions. Handlers reference Zod output schemas (detectContextOutputSchema, listWorktreesOutputSchema, etc.) but these are not embedded in the McpServer tool registrations that clients see. LLMs cannot inspect return types before calling tools.
Error handling lacks consistent actionability. Examples: 'Errors with code TARGET_EXISTS when the target path exists' is clear, but errors for branch filters or network failures don't include recovery steps (e.g., 'retry initialize', 'check remote branch exists'). Some errors are thrown without guidance for LLM retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2025-06-18+ | v2 |
List worktrees with status. No repoName + config loaded = all configured repos grouped by repoName. With repoName = single repo. Entries: {path, branch, isCurrent, label (clean|dirty|stale|current|unknown), status, divergence, safeToRemove, lastSyncAt, sizeBytes}.
Load sync-worktrees.config.{js,mjs,cjs,ts} from a directory (auto-walked from path or CWD). Returns: configPath, repositories (all configured repos with resolved paths), defaults, parallelism, etc. Errors when the file is invalid, exports nothing, or has schema violations.
Set the current repository context for this client session. Subsequent tool calls that omit repoName will use this repo. Returns: repoName, mode, bareRepoPath, worktreeDir, repoUrl.
Run one sync cycle: create missing worktrees, remove diverged/stale ones (via trash), fast-forward dirty ones, and update clean ones. Worktree-mode: uses branch filters + age. Clone-mode: single worktree, skips creation/removal, updates the checkout. Runs under cross-process lock (blocks contending operations). Returns outcome: {started, reason, outcome} where outcome.actions details what was done.
Worktree-mode only; clone-mode repos error here. Fast-forward or rebase an existing worktree to its upstream branch. Fails when not cleanly fast-forwardable (local changes exist). Succeeds when up-to-date.
Inconsistent parameter naming convention. Most tools use verb_noun (create_worktree, update_worktree), but some use adjective_noun (get_worktree_status, load_config). LLMs benefit from uniform naming for pattern matching.
Long, complex descriptions may overload LLM context. detect_context description is ~450 chars (above the 194-char average for production tools and p90=392). Shorten by separating 'lean' vs. 'detailed' behavior into distinct usage notes rather than inline explanations.
Missing dependency hints in tool descriptions. No description tells LLMs 'call detect_context first' or 'must initialize before create_worktree'. Agents must infer prerequisites from trial and error.