Skip to main content
Glama
Approval Gate MCP

Approval Gate MCP

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
APPROVAL_GATE_DIRNoOverride the default state directory. Everything lives in ~/.approval-gate/ by default: requests/*.json for current state, audit.jsonl for the append-only history.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
request_approvalA

Register a consequential action for human approval BEFORE performing it. Returns a request id. The action is NOT executed by this server; status 'approved' does NOT authorize anything by itself. Right before acting, call consume_approval with the same id, the exact action text and the same operation/payload if you supplied them; proceed only on ok:true. Anything else means no (fail closed).

check_approvalA

Check the current status of an approval request. Informational only: no status here authorizes execution (authorizesExecution is always false). See effectiveStatus (approved_unconsumed, approved_expired, consumed, revoked, ...). Only consume_approval ok:true authorizes.

wait_for_approvalA

Block until a human decides the request, it expires, or the timeout elapses. Returns the final (or still-pending) request. Informational only; it never authorizes execution. A timeout returns 'pending' (not approved). After 'approved', call consume_approval and proceed only on ok:true.

list_pendingA

List approval requests awaiting a human decision, oldest first, one page at a time. Returns {items, nextCursor}; nextCursor is present only when more requests exist (pass it back as cursor). Items omit payload text; use check_approval for one full request.

decide_approvalA

Deny a pending request, or revoke an approved-but-unconsumed one. Approvals are not possible through MCP; a human must run approval-gate approve <id> in their own terminal.

consume_approvalA

Call this IMMEDIATELY before performing an approved action. Succeeds exactly once per request, only if the request is approved, not past its expiry, action is byte-for-byte the text that was approved, and operation/payload (if the request had them) are identical. ok:false for any reason means do NOT proceed. An approval cannot be reused for a second or different action. The returned JSON is not a transferable credential: no other component may accept it as proof of approval.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 6 tools

Disambiguation4/5

Each tool maps to a distinct lifecycle stage: register, poll, block, enumerate, deny/revoke, and consume. The only fuzzy cluster is check_approval vs wait_for_approval vs consume_approval, all of which report status; the descriptions do explicitly separate them (informational poll vs blocking wait vs single-use authorization), which keeps misselection recoverable but still requires careful reading.

Naming Consistency4/5

Five of six tools follow a clean verb_noun pattern (request_approval, check_approval, wait_for_approval, decide_approval, consume_approval). list_pending breaks the pattern by omitting the noun object (implied 'approvals'), a minor deviation but still readable and unambiguous.

Tool Count5/5

Six tools is well-scoped for an approval gate: one per lifecycle operation with no redundant entries. Nothing feels padded or missing on the surface.

Completeness4/5

Covers the full request-poll-wait-list-decide-consume loop, with the notable and intentional absence of an MCP-side approve (humans approve out-of-band). Minor gap: there is no way to enumerate decided/expired/consumed requests by status, so an agent that lost a request id can only recover via paginated list_pending.

Maintenance

ActivityActive
ResponsivenessSyncing