Repository Manager

Status

rm_merge_queue_status

Read-onlyIdempotent

Check the status of a repository's serialized merge queue. See the current lease, candidate gating results, and landed versus pushed outcomes.

Instructions

Status (rm_merge_queue). Serialized merge queue for ANY git repository (CONCEPT:RM-MERGE-QUEUE).

The canonical driver of parallel development: lanes take worktrees, work, then hand branches here, and the queue gates them as merged, fast-forwards the base, and prunes the worktree and branch. Set push false when a scheduler must leave publication to phased push.

The queue does not know what a gate is. Gates are declared in the target repository's own .mergequeue.yaml — a command, a tier, a timeout, and how to compare its result against the base ref. agent-connector-sdk declares pytest + ruff + its contract scripts; epistemic-graph declares cargo check --all-features + clippy; a docs repo could declare only a link check. A repository with no declaration is REFUSED rather than defaulted, because "declared no gates" and "has no queue configured" must not be the same value.

Gating is differential: only a failure the base ref does not already produce blocks a candidate — the base is legitimately red here, and an absolute gate once deadlocked a queue and stranded 19 branches. A baseline that cannot be produced REFUSES the candidate; it never degrades to allow-all.

run holds that repository's reconciliation-merge LEASE. If another runner holds it the call returns deferred: true with the holder — defer, do not retry in a loop.

landed vs pushed (D-W3WPS-3). Each outcome carries both, separately: landed means the declared base ref fast-forwarded in the LOCAL canonical checkout (proven by re-reading it); when push is true, pushed means that commit also reached the configured remote via the repo's own gated push path (_gate_before_push + push_project — the same pre-commit gates and GH013/divergent-remote handling a manual push gets). With push false, publication is deliberately deferred to the phased-push scheduler. A push failure never fails the landing — landed: true, pushed: false is a legitimate, visible intermediate state; check push_error on the outcome for why. The queue's own run summary also reports pushed/landed_unpushed counts.

Input Schema

Name	Required	Description
`base`	No	Branch to land onto. Defaults to the repo's declared base.
`push`	No	Publish a landed base through the repository's gated push path. Set false for the fast queue timer; the phased-push scheduler then owns publication.
`prune`	No	Remove each landed candidate's worktree and branch through the guarded prune (merge-base re-checked at delete time, a refs/lane-backup anchor written first, `git branch -d` never -D, and a worktree holding uncommitted work is refused).
`branch`	No	Candidate branch for enqueue/withdraw. Defaults to that tree's HEAD.
`reason`	No	Why a candidate is being withdrawn.
`repo_path`	No	Any working tree of the target repository. This is what makes the queue cross-project: one server, N repositories, each with its own lease, candidate store, and gates. Defaults to the server's cwd.
`batch_size`	No	Candidates gated together per run (0 = the repo's declared batch_size).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.5.1Oct 19, 2026

TDQS

C2/5.0

Behavior1/5

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

The description instructs the caller to configure publication ('Set push false...'), says the queue 'fast-forwards the base, and prunes the worktree and branch', and the schema exposes a default-true 'prune' that deletes worktrees and branches — all inconsistent with the annotations readOnlyHint=true and destructiveHint=false. The rich behavioral detail present (leases, deferred, gating refusal, landed/pushed) describes run-time semantics of a different operation, so it neither matches nor supplements the declared safety profile of this tool.

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

Conciseness2/5

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

Roughly 350 words of dense system lore — differential gating history, the deadlocked queue that stranded 19 branches, D-W3WPS-3 landed vs pushed — none of which is front-loaded toward what this tool does. The genuinely relevant content (what status reports) is absent while tangential detail dominates.

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?

An output schema exists, so return values need not be described, but the description still omits the essential context for a status tool: what state it reports, how it relates to rm_merge_queue_run/rm_merge_queue_config, and whether the mutation-shaped parameters actually apply here. The supplied context instead describes the surrounding system, leaving the tool's own contract unclear.

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 description coverage is 100%, so the schema already documents all seven parameters fully (base, push, prune, branch, reason, repo_path, batch_size). The description adds almost nothing at parameter level beyond echoing the push=false story. Baseline 3 applies when the schema carries the semantics.

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

Purpose2/5

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

The description opens with 'Status (rm_merge_queue)' and then describes the merge-queue system as a whole (lanes, worktrees, gates, leases, landed vs pushed) rather than what this status call does or returns. It never states the specific verb+resource of the operation, and it does not distinguish this tool from siblings like rm_merge_queue_run, rm_merge_queue_enqueue, or rm_merge_queue_config. The reader cannot tell what a call to this tool actually does.

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 statement of when to call this tool versus rm_merge_queue_run/enqueue/withdraw/config. The only imperative guidance ('Set push false when a scheduler must leave publication to phased push', 'defer, do not retry in a loop') reads as instructions for the run operation, not for a status query. Usage is implied at best by the word 'Status'.

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

Deploy Server