Repository Manager

Status

rm_gates_status

Read-onlyIdempotent

Run and inspect two-tier fast/heavy pre-commit gates across repositories, with status, failure analysis, profiling, and retest support.

Instructions

Status (rm_gates). Run and inspect the two-tier (fast/heavy) pre-commit gate across repos.

The single tool that can actually drive both tiers of the two-tier gate model: stage="fast" exercises a repo's pre-commit-stage hooks, stage="heavy" exercises its pre-push-stage hooks (pytest, cargo, uv lock --check, ...) via pre-commit run --hook-stage <stage>.

Input Schema

Name	Required	Description	Default
`repo`	No	Target one repo's latest gate job for 'status'/'explain'/'profile' (alternative to job_id).
`fleet`	No	For 'audit_fail_fast': scan every repository in the workspace rather than the ones named by 'repos'.
`repos`	No	Comma-separated repo names or absolute paths to target. Omit for 'run'/'retest' to target the whole workspace.
`stage`	No	'fast' -> `pre-commit run --hook-stage pre-commit` (formatters/linters, no network/tests). 'heavy' -> `--hook-stage pre-push` (pytest, cargo, `uv lock --check`, ...). For 'run'/'retest'.	fast
`start`	No	For 'phase_direction_here': directory to resolve the repository from (default: this process's current working directory).
`top_n`	No	'profile' with no job_id/repo: how many slowest hooks to report fleet-wide.
`job_id`	No	Target one gate job for 'status'/'explain'/'profile'.
`dry_run`	No	For 'xdist_apply': report what would change without writing. Defaults to True on purpose -- rewriting ~40 repositories' pre-commit configs must be an explicit choice, never the consequence of omitting an argument.
`summary`	No	'status': compact roll-up (counts + failed set) vs the full per-job detail.
`threads`	No	Parallel workers.
`timeout`	No	Per-repo pre-commit timeout in seconds.
`escalate`	No	'retest' only: when a repo's narrowed retest passes every requested hook, also submit a SECOND job for that repo's full wave (a narrowed pass alone is never sufficient evidence of shippability -- see gate_ledger.is_shippable).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.5.1Oct 19, 2026

TDQS

C2.7/5.0

Behavior1/5

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

Annotations declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, but the description says this is 'the single tool that can actually drive both tiers' by executing pre-commit hooks, and the dry_run parameter explicitly warns about 'rewriting ~40 repositories' pre-commit configs'. Whatever the default path does, a tool that runs hooks and can write configs is not read-only, so the description contradicts the annotations.

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?

Short and reasonably front-loaded: purpose first, then the two-tier stage mechanics. The title prefix 'Status (rm_gates)' and the scattered backtick/line-break formatting add a little noise, but there is no filler prose.

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?

With 12 parameters, an output schema and annotations, the description should at minimum tell an agent what a default call (all params defaulted) actually does and how job_id/repo/repos interact. Instead it leaves the multi-action dispatch unexplained and, worse, implies write/execute behavior that the annotations deny, so an agent cannot confidently predict the outcome of invoking it.

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

Parameters3/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 the conceptual frame for `stage` (fast = formatters/linters, heavy = pytest/cargo/uv lock) but no parameter semantics beyond what the schema already documents, and it never explains how the many action-scoped parameters (status/explain/profile/run/retest/xdist_apply) are selected, since no action selector is visible.

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 concrete verb+resource: running and inspecting the two-tier (fast/heavy) pre-commit gate across repos, and explains the fast/heavy stage split with the underlying `pre-commit run --hook-stage` calls. It never distinguishes itself from siblings that appear to do the same thing (rm_gates_run, rm_gates_retest, rm_gates_explain, rm_gates_profile), which is a real gap for a tool named only 'Status'.

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?

No when-to-use / when-not-to-use guidance is given. The only selection advice is implicit in parameter descriptions (stage='fast' vs 'heavy', summary flag), and nothing tells the agent whether to reach for this tool or for rm_gates_run / rm_gates_explain / rm_gates_retest when several of those actions are apparently reachable here too.

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

Deploy Server