Skip to main content
Glama
Knuckles-Team

Repository Manager

by Knuckles-Team
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Run

rm_merge_queue_run

Run a serialized merge queue for any git repository: gate candidate branches as merged, fast-forward the base, and prune landed worktrees and branches.

Instructions

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

NameRequiredDescriptionDefault
baseNoBranch to land onto. Defaults to the repo's declared base.
pushNoPublish a landed base through the repository's gated push path. Set false for the fast queue timer; the phased-push scheduler then owns publication.
pruneNoRemove 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).
branchNoCandidate branch for enqueue/withdraw. Defaults to that tree's HEAD.
reasonNoWhy a candidate is being withdrawn.
repo_pathNoAny 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_sizeNoCandidates gated together per run (0 = the repo's declared batch_size).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.5.1

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations: lease acquisition with a deferred result and named holder, differential gating semantics, refusal on a missing gate declaration, the landed-vs-pushed split with push_error on partial failure, and the guarded prune. The destructiveHint=false annotation is reconciled by the description's detail that prune writes a refs/lane-backup anchor first and uses 'git branch -d' never -D, so deletion is intentionally recoverable.

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?

Well front-loaded — purpose, then push semantics, then lease/push outcomes — but roughly 350 words with formatting emphasis. The middle section on what a gate is, the .mergequeue.yaml examples, and the anecdote about a deadlock stranding 19 branches explain the design rather than help an agent invoke this call, and belong closer to rm_merge_queue_config or rm_gates_explain.

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?

For a complex, lease-holding, multi-repo queue step the description covers the decision-relevant behaviors: deferral, refusal, gating model, push control, and outcome fields. Because an output schema exists it need not enumerate return values, yet it still explains landed/pushed/push_error. Only minor gaps remain (e.g. how batch_size interacts with a run, or the shape of the run summary).

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 all seven parameters are already documented in the schema, and each schema entry is itself detailed (notably prune and push). The description's push/landed discussion clarifies the meaning of the push flag conceptually, but it does not add syntax or value constraints the schema lacks. Baseline 3 is appropriate when the schema does the heavy lifting.

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 line plus the workflow sentence give a specific verb and resource: this is the canonical driver that takes handed-off lane branches, gates them as merged, fast-forwards the base, and prunes. That is far more concrete than the bare title 'Run'. It never names its siblings (rm_merge_queue_enqueue/status/withdraw/config), so the agent has to infer the boundary between 'run the queue' and 'enqueue a candidate' itself.

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 real conditional guidance: set push=false when a scheduler must leave publication to phased push, and 'defer, do not retry in a loop' when another runner holds the lease. It also states that a repo with no .mergequeue.yaml declaration is REFUSED rather than defaulted. It stops short of an explicit ordering against siblings (e.g. 'enqueue first, then run'), so it is strong context without full alternative routing.

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