Skip to main content
Glama
BASHBOP

Òtítọ́

by BASHBOP
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Review Gate

review_gate

Gate changes for merge by evaluating local diffs or GitHub pull requests against risk, security, and policy checks, returning a PASS/WARN/FAIL verdict.

Instructions

Gate a change for merge and return a PASS / WARN / FAIL verdict. Omit pr to run the local, no-GitHub gate against a base ref (changed files, secret safety, risk-sensitive paths, release discipline, validation commands, dependency audit, policy profile). Set pr to gate an open GitHub PR via gh (PR state, review decision, CODEOWNERS approvals, unresolved conversations, branch protection, status checks). Merges the old merge_readiness and pr_merge_readiness tools. Use review_verdict instead when you want the full impact + review + gate composite, or review_context when you want diff/comment context with no verdict.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prNoOptional PR selector (number, URL, or branch). When set, runs the GitHub gate; when absent, runs the local gate.
baseNoBase ref for the local gate. Defaults to origin/main, then HEAD. Ignored in PR mode.
pathNoRepository path. Defaults to current working directory.
policyNoPolicy profile: standard (default), company, or high-risk.
stagedNoUse the exact Git index for changed-path, risk, secret, and convergence evidence. Release, validation-command, and optional analyzer checks still inspect the working tree. May create Git object or index-cache metadata; source files are unchanged. Ignored in GitHub PR mode.
receiptNoOptional convergence inputs hash, JSON object, or path to a JSON receipt artifact. Exact-subject v2 receipts require the full hash; legacy v1 display IDs remain accepted.
requestNoOptional change request for context evidence output.
governanceNoGovernance: team (default) or solo.
minConvergenceNoOptional minimum convergence score (0–100). Enables a failing gate when the task/diff score is below this floor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior3/5

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

Annotations indicate readOnlyHint=false; the description does not contradict this and adds useful context about what each gate mode checks. However, it never discloses actual side effects such as whether gh writes comments/statuses or whether any repository state is modified, leaving a meaningful behavioral gap.

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

Conciseness5/5

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

Every sentence is informative: the verdict, the two modes, the tool consolidation, and the sibling alternatives are all covered without fluff. The description is front-loaded with the core purpose and remains compact.

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?

Given the tool's two modes scatte and 9 parameters, the description provides a complete mental model: checks performed, return shape, and when to pick alternatives. It lacks explicit prerequisites like an authenticated gh CLI, but the 'via gh' phrasing reasonably implies it, so the gap is minor.

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%, and the input schema already explains pr, base, staged, and other parameters well. The description mostly restates the pr mode behavior rather than adding new meaning, so the baseline of 3 is appropriate.

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?

Description states a specific action ('Gate a change for merge') and a concrete outcome ('return a PASS / WARN / FAIL verdict'). It clearly differentiates from siblings by naming review_verdict and review_context and how they differ in scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to omit pr (local gate) vs set pr (GitHub PR gate). Also names alternatives: review_verdict for the composite and review_context for context with no verdict, leaving no ambiguity about when to use this tool.

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