Skip to main content
Glama

merjax_merge_pr

Destructive

Merge an open PR. Enforces the same checks as the HTTP merge flow: not a draft, head SHA resolves, GateTest+AI-review hard gates pass, branch-protection rules satisfied. M3: soft-blocks when the pre-merge risk score is critical unless confirm_high_risk: true is passed. Returns {merged, sha?, reason?, riskScore?}.

Input Schema

NameRequiredDescriptionDefault
repoYesRepo name
ownerYesRepo owner — username or organisation slug
numberYesPR number
confirm_high_riskNoWhen true, bypass the M3 risk-score soft-block on critical-band PRs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the destructiveHint=true annotation: it discloses the gate chain that will reject the call, the soft-block on critical pre-merge risk scores, and the bypass mechanism. The return shape {merged, sha?, reason?, riskScore?} tells the agent how failure is surfaced rather than thrown.

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?

Three dense sentences, front-loaded with the action, then the gate list, then the risk exception and return shape. Minor cost from unexplained jargon ('M3', 'GateTest') that a first-time caller must infer.

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 high-risk mutation with no output schema, the description supplies preconditions, the soft-block exception, and the return shape, which is enough to call it correctly. It stops short of stating whether hard gate failures throw versus returning merged:false with a reason.

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% and the schema's confirm_high_risk description nearly duplicates the description text ('bypass the M3 risk-score soft-block on critical-band PRs'). The description adds only the contextual link between the critical risk band and the bypass, which is marginal beyond the schema baseline.

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

Purpose5/5

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

States a specific verb and resource ('Merge an open PR') and immediately scopes it against the surrounding workflow by naming the gates enforced. An agent can distinguish this from merjax_set_auto_merge, merjax_approve_pr, or merjax_close_pr without opening a schema.

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 explicit preconditions for a successful call (not a draft, head SHA resolves, GateTest+AI-review gates pass, branch protection satisfied) and the exact condition under which confirm_high_risk is required. It does not explicitly route the agent away from set_auto_merge for pre-approval flows, so it stops short of full when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources