Approval Gate MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APPROVAL_GATE_DIR | No | Override 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
| 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, |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
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.
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.
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.
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.