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; the calling agent must check approval status and only proceed on an explicit 'approved'. Anything else means no (fail closed). |
| check_approvalA | Check the current status of an approval request. Statuses: pending, approved, denied, expired. Only 'approved' authorizes the action. |
| wait_for_approvalA | Block until a human decides the request, it expires, or the timeout elapses. Returns the final (or still-pending) request. A timeout returns status 'pending': treat it as NOT approved. |
| list_pendingB | List all approval requests currently awaiting a human decision. |
| decide_approvalA | Record a human decision on a pending request. IMPORTANT: this tool exists for setups where the human is driving this very session and asks the agent to record their decision. An agent must NEVER call this on its own initiative to approve its own request; self-approval defeats the gate. Prefer the out-of-band CLI: approval-gate approve . |
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 5 tools
Each tool maps to a distinct action in the approval lifecycle (request, check, wait, list, decide), and descriptions make the boundaries clear. The only mild overlap is check_approval vs wait_for_approval, which both return status but differ in blocking behavior, so an agent must read carefully to pick the right one.
Most names follow a verb_noun pattern with a consistent '_approval' suffix (request_approval, check_approval, wait_for_approval, decide_approval). list_pending breaks the pattern by naming on state rather than the resource, a minor deviation but still readable.
Five tools is well-scoped for a human-in-the-loop gate: each covers a necessary stage (create request, poll, block, enumerate, decide). No redundant or filler tools are present.
The surface covers the core lifecycle including creation, status checks, blocking waits, listing, and decision recording, with expiry handled implicitly. A cancel/revoke tool for withdrawing a pending request is the notable missing operation, but agents can work around it via expiry.