Skip to main content
Glama
Sign In
cohors

cohors

by rushirb2001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Run a command in each repository

run
Destructive

Execute one shell command across selected repositories and collect each repo's exit code, stdout, stderr, timeout, and truncation status for fleet-wide audits, tests, or codemods.

Instructions

Run one shell command in each selected repo and collect per-repo {exit_code, stdout, stderr, truncated, timed_out} — the fleet codemod/audit/test primitive (e.g. "cargo fmt --check", "rg TODO", "npm test"). The command runs in each repo's own directory. Requires command and selector. Executing needs --allow-run AND confirm:true; dry_run:true previews the target set with neither. Each repo is bounded by timeout_secs (default 120).

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": {
      "command": "<command>",
      "selector": "<selector>"
    },
    "name": "run"
  }
}

Input Schema

NameRequiredDescriptionDefault
commandYesShell command run in each selected repo's directory.
confirmNoMust be true to actually act; preview first with dry_run.
dry_runNoPreview the resolved target set without acting.
selectorYesPredicate that selects repos across the fleet; set fields to AND them, omit a field for no constraint (ADR-024). Scope: all (bool — the whole fleet), ids[str], name (glob, e.g. "pay*"), path_glob (* stays within one path segment, ** crosses /), root, group (a config-defined cluster name, e.g. "payments"). Local state: dirty, ahead (alias unpushed), behind, diverged, no_upstream, unpublished (a branch never pushed although the repo has a remote), stale_fetch (remote not fetched for over 14 days), has_stash, detached, conflicted, in_operation (merge/rebase/… mid-flight), error, branch (exact name), attention ("any"|"notice"|"warn"|"risk"). Remote (needs a GitHub token): ci ("passing"|"failing"|"pending"|"none"), min_prs (int). Combine: any_of[selector] (OR), not (selector). The empty selector {} matches NOTHING by design — pass {"all": true} for the whole fleet.
timeout_secsNoPer-repo timeout in seconds (default 120).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag destructive and non-idempotent, and the description goes well beyond them: it discloses the execution gate (--allow-run plus confirm:true), that dry_run needs neither, that the command executes in each repo's own directory, the default 120s per-repo timeout, and the exact per-repo result fields. That is substantive behavioral context an agent cannot get from the annotations alone.

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

Conciseness5/5

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

Three tight sentences: the action and return shape first, then the per-repo execution context, then the gating rules. Every clause carries information, including the parenthetical examples and the timeout default, with no filler.

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?

For a destructive, open-world, 5-parameter tool with no output schema, the description covers the action, return shape, execution gating, working directory, and timeout — everything needed to call it safely. The nested selector's semantics are fully documented in the schema, so no burden shifts to the description.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds real value by tying confirm to actual execution, clarifying that dry_run bypasses both --allow-run and confirm, and restating the timeout default. It stops short of explaining selector combination logic, which it leaves entirely to the schema.

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?

States a specific verb and resource ("Run one shell command in each selected repo") plus the exact collected output keys, and frames it as "the fleet codemod/audit/test primitive" with concrete examples. Sibling tools like get_repo or commit operate on a single repo, and this description's fleet-wide framing makes the distinction immediate.

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?

Gives clear usage context ("fleet codemod/audit/test primitive") with three example commands, and specifies the prerequisites for execution (--allow-run AND confirm:true) versus preview (dry_run:true). It does not explicitly exclude or route to named alternatives, but the when-to-use context is unambiguous.

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