Repository Manager

Config

rm_merge_queue_config

Configure a repository's merge queue to gate candidate branches, fast-forward the base, publish via gated push, and prune landed worktrees.

Instructions

Config (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.8/5.0

Behavior4/5

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

Annotations only declare write/non-destructive/non-idempotent; the description goes well beyond them, disclosing lease acquisition and deferral semantics, that an undeclared repo is REFUSED, that gating is differential against the base ref, and the split landed/pushed outcome with push_error. This is rich context an agent could not get from the structured fields, though some of it is internal implementation detail rather than callable behavior.

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

Conciseness3/5

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

The prose is dense, bold-marked, and back-loaded with concept IDs (CONCEPT:RM-MERGE-QUEUE), spec tags (D-W3WPS-3), and internal function names (_gate_before_push, push_project) that do not help selection. The genuinely actionable sentence (defer, do not retry) is buried mid-document rather than front-loaded. It is not padding, but it is poorly prioritized for an agent.

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

Completeness3/5

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

With an output schema present, return values need not be explained, yet the description spends most of its length on landed/pushed outcome semantics anyway. The behavioral story is complete, but the operational story (what this specific tool does versus the queue siblings) is missing, leaving the definition incomplete where it matters most.

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, and the baseline is 3. The description adds only one small semantic overlap, restating the push=false / phased-push scheduler relationship; base, branch, reason, and batch_size get no additional meaning here.

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 'Config (rm_merge_queue). Serialized merge queue for ANY git repository,' which characterizes the resource but never states the operation: it is unclear whether this reads config, writes config, or drives a run. The parameters (branch, reason, batch_size) look like queue operations rather than configuration, so the name and the content actively conflict. An agent cannot tell from the text what this call does to the system.

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 one genuinely useful directive — 'defer, do not retry in a loop' when the lease is held — but no guidance on when to choose this over the many queue siblings (rm_merge_queue_enqueue, rm_merge_queue_run, rm_merge_queue_status, rm_merge_queue_withdraw). No prerequisites or exclusion conditions are stated.

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

Deploy Server