Skip to main content
Glama

Spawn worker pool

spawn_workers

Spawn a pool of queue workers in one call to claim tasks, run your command per task, and exit when the queue drains.

Instructions

Spawn a pool of queue workers in one call (#6). Opens pane(s) running the native hyperpanes worker runner bound to queue: it claims tasks and runs command (via sh -c, so $HP_TASK_PAYLOAD / $HP_TASK_ID / $HP_FENCING_TOKEN / $HP_QUEUE are in the environment) for each, acking on exit 0 and nacking on non-zero, until the queue drains — then the pane exits. count = how many competing workers; by default each gets ITS OWN pane (layout:"pane-per-worker") so you can watch one agent per pane — pass layout:"single-pane" for the legacy one-pane-runs-N behaviour. isolation:"worktree" runs each task in a throwaway git worktree that auto-removes (needs cwd to be a git repo) and REQUIRES base — the explicit committish each task worktree forks from, passed to the runner as --base (the call fails without it). stream:true renders a Claude child's --output-format stream-json events as readable progress instead of the silence a bare claude -p gives you; logDir tees each task's raw output to a file that outlives the pane; lingerSecs keeps the pane open after the queue drains. The runner binary defaults to hyperpanes on PATH (override with HYPERPANES_WORKER_BIN on the bridge). env/accounts/meta/project/subtitle pass through to each worker pane spec — merge order: env is the shared base, accounts[i % len] sets each pane's CLAUDE_CONFIG_DIR and wins over env (rotation requires layout:"pane-per-worker" when count > 1; single-pane shares one process env, so the call fails loudly). Every worker pane is stamped with default org meta role="worker", task="queue:", parent=<this bridge's pane> (so worker send_to_parent works out of the box); caller meta wins over those defaults. Returns the spawned pane ids.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNorunner working directory; required (a git repo) for isolation:"worktree"
envNoenv vars set on every worker pane
baseNofork point committish for isolation:"worktree" task worktrees (REQUIRED with it): "main" for independent work, the goal's integration branch for a dependent wave
metaNofree-form org metadata merged OVER the stamped defaults (role="worker", task="queue:<queue>", parent=<this bridge's HYPERPANES_PANE_ID>) — an explicit key always wins
colorNo
countNocompeting workers (default 1); one pane each unless layout:"single-pane"
queueYesthe work queue to drain
layoutNo"pane-per-worker" (default) = one visible pane per worker; "single-pane" = one runner pane multiplexing all N
logDirNotee each task's raw output to <dir>/<queue>-<taskId>.log, so the transcript survives the pane closing
streamNorender the child's Claude stream-json events as readable progress (pair with `--output-format stream-json --verbose` in `command`)
commandYesshell command run per claimed task; reads the task from $HP_TASK_PAYLOAD etc.
projectNoopen worker panes in a remembered project (see list_projects): defaults cwd + color from it
accountsNoCLAUDE_CONFIG_DIR account rotation: under layout:"pane-per-worker" (default), worker pane i gets env.CLAUDE_CONFIG_DIR = accounts[i % accounts.length], winning over env.CLAUDE_CONFIG_DIR. Rotation needs one pane per worker: with layout:"single-pane" and count > 1 the call FAILS (one process env cannot rotate per-worker); single-pane with count 1 gets accounts[0]
subtitleNosecondary header line set on every worker pane
windowIdNo
isolationNo"worktree" = run each task in a throwaway git worktree (default "none"); requires `base`
lingerSecsNohold each worker pane open this many seconds after the queue drains (default 0 = close immediately)
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and excels. It discloses ack/nack semantics (exit 0 ack, non-zero nack), pane exit after queue drain, worktree auto-removal, the necessity of `base` for worktree isolation, loud failure for single-pane account rotation, and the env var merge order (accounts wins over env, caller meta wins over defaults).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but every clause carries dense, relevant information for a 17-parameter tool. It is front-loaded with the core runner behavior and then proceeds through parameters in a logical order, using emphasis (caps, backticks) to highlight constraints. It could be slightly more scannable with bullet points, but it is not padded with fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, execution model, lifecycle (queue drains → pane exits), return value (pane ids), configuration interactions, failure modes, and even defaults. With 17 parameters and no output schema, this description provides everything an agent needs to invoke the tool correctly and anticipate edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even with 88% schema coverage, the description adds extensive meaning beyond the schema: environment variables available in the command, the exact behavior of `count`, `layout`, `isolation`, `stream`, `logDir`, `lingerSecs`, and the nuanced merge order for `env`/`accounts`/`meta`. This goes well beyond the property descriptions and provides actionable invocation guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Spawn a pool of queue workers in one call (#6).' which is a specific verb+resource statement that clearly distinguishes it from sibling queue tools like enqueue_task or claim_task. It further specifies the runner behavior, bound queue, and the commands executed, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly describes the function of spawning workers and provides context on configuration choices (layout, isolation, stream, lingerSecs) and failure conditions (explicit 'the call fails' statements). It doesn't explicitly name alternative tools, but the context is strong enough that an agent knows when to use it: whenever a pool of queue workers is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Eyalm321/hyperpanes-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server