Repository Manager

Enqueue

rm_merge_queue_enqueue

Enqueue a candidate branch into a repository's merge queue to gate, fast-forward the base, and optionally push or prune.

Instructions

Enqueue (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

A4.1/5.0

Behavior5/5

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

Far exceeds the annotations: it explains differential gating, that an undeclared repo is REFUSED rather than defaulted, the lease/deferred behavior, and the landed vs pushed distinction with push_error on failure. These are exactly the non-obvious traits an agent needs before invoking a mutation tool.

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 key scoping statement is front-loaded, but the body is dense with tangential material (example gate declarations across repos, history of a deadlock) that, while useful background, is not strictly needed to call enqueue correctly. Tightening would improve signal.

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

Completeness4/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 spelled out, yet the description still clarifies the landed/pushed/push_error outcome fields. For a 7-param mutation tool with a lease and refusal semantics, coverage is strong though thinner on the withdraw-vs-enqueue boundary.

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, but the description adds genuine meaning: push=false defers to the phased-push scheduler, prune uses a guarded delete with a backup anchor, and repo_path is what makes the queue cross-project. It enriches several parameters beyond their schema text.

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?

The opening states a specific verb (enqueue) and resource (rm_merge_queue) and explains the mechanism: lanes hand branches here, the queue gates them, fast-forwards the base, and prunes. It is largely clear, but much of the prose describes the queue's overall gate/lease machinery rather than the enqueue action specifically, blurring the line with rm_merge_queue_run.

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?

Offers concrete operational guidance — set push false when a scheduler must leave publication to phased push, and 'defer, do not retry in a loop' when the lease is held. It does not explicitly route the agent between rm_merge_queue_run, rm_merge_queue_withdraw, and this tool, so sibling selection is left 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