worker-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WORKER_BRIDGE_HOME | No | State root directory | ~/.worker-bridge |
| WORKER_BRIDGE_STORE | No | Override the SQLite path | |
| WORKER_BRIDGE_MAX_CONCURRENCY | No | Global concurrent workers (host-wide) | 4 |
| WORKER_BRIDGE_REPO_CONCURRENCY | No | Concurrent workers per repository | 3 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| worker_delegateA | Delegate a scoped coding task to an external AI coding worker in an isolated git worktree, then independently verify the result. USE for: implementing a feature, fixing a bug across files, a refactor or migration — work you'd otherwise do inline. Delegating keeps your context clean and gets an independent verification pass on the diff. The worker runs in the background; poll with worker_status(task_id). DO NOT USE for a trivial one-line edit, or non-coding work. Args: objective: What the worker must accomplish. Be specific and scoped. repository: Absolute path to the target git repository. worker: codex | claude-code | opencode | zcode-glm | vscode | mock (or a configured worker). permission: read_only | workspace_write | full_access | custom. verify: Shell commands worker-bridge runs itself to verify, e.g. ["pytest -q"]. base_ref: Git ref to branch the worktree from (default HEAD). wait: Block until finished and return the full result (default false). |
| worker_statusA | Check delegated worker tasks. With task_id: returns status, summary, changed files, the independent verification result, and artifact paths (diff + manifest). Without task_id: lists recent tasks. Use to poll a task started by worker_delegate. |
| list_workersA | List available coding workers on this machine (installed and healthy),
with their capabilities. Call this to see which |
| worker_cancelA | Cancel a running or queued delegated task and terminate its worker process tree. Returns the task's terminal state. |
| worker_logsA | Return the normalized event log for a delegated task (worker.started,
progress, worker.completed, verification, ...), for streaming-style progress.
Pass |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: listing workers, delegating tasks, canceling tasks, checking status, and retrieving logs. There is no ambiguity or overlap.
Most tools use a 'worker_' prefix followed by a noun (cancel, delegate, logs, status), but 'list_workers' reverses the pattern to verb_noun. This inconsistency could cause confusion.
With 5 tools covering discovery, delegation, cancellation, status polling, and logs, the set is appropriately scoped for a worker bridge server.
The lifecycle of delegated tasks is well-covered: list available workers, delegate, cancel, check status, and get logs. Minor gap: no explicit tool to get detailed worker health beyond 'list_workers', but that is sufficient.