Skip to main content
Glama
Sign In
PowerSwarm

PowerSwarm

by willykeenan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

powerswarm_run

Start a run where each target gets its own git worktree and headless agent, gated by a kill check. Returns launch truth without merging or pushing.

Instructions

Start a run: each target gets its own git worktree and headless agent, gated by its kill check. Returns launch truth (worker-live only when a worker process exists). Nothing is merged or pushed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "request": "<request>",
      "root": "<root>"
    },
    "name": "powerswarm_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
rootYesclean git repository (absolute path)
soloNo
modelNo
requestYes
runtimeNogrok
max_concurrencyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses side effects (creates a git worktree and a headless agent per target), a safety gate (kill check), and an important non-effect ('Nothing is merged or pushed'). It still omits failure behavior, permission requirements, and what happens to worktrees afterwards.

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?

Three dense sentences, front-loaded with the action and its mechanism, and the parenthetical on 'launch truth' adds precision without padding. No wasted prose, though the phrasing is terse enough to be slightly cryptic.

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

Completeness2/5

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

For a complex launch tool with a nested request object, 6 parameters, no annotations, no output schema, and low schema coverage, the description covers behavior but not the inputs an agent must supply. An agent can understand what happens but not how to configure it.

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

Parameters2/5

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

Schema description coverage is only 17% (only 'root' is documented), so the description is expected to compensate and does not. Key parameters ('request' nested object, 'solo', 'model', 'runtime', 'max_concurrency') are never explained, leaving half the input surface opaque.

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

Purpose4/5

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

States a specific verb and resource ('Start a run') and immediately clarifies the mechanism (per-target git worktree + headless agent). It is distinguishable from siblings like powerswarm_spec/validate/cancel/status, but it does not explicitly contrast itself with any of them.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to call this versus powerswarm_spec, powerswarm_validate or powerswarm_status, nor any statement of prerequisites or ordering. The intended lifecycle position (validate first, then run) is left entirely to inference.

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

Deploy Server

Other Tools