consentgate-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONSENTGATE_API_KEY | Yes | Your ConsentGate API key (cg_…). | |
| CONSENTGATE_BASE_URL | No | Override base URL for self-hosted instances (default https://consentgate.fyi). |
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 |
|---|---|
| check_actionA | Check whether an action is permitted by the ConsentGate owner's consent policy BEFORE you perform it. Call this for any potentially sensitive, irreversible, or high-impact action — e.g. sending email or messages, posting publicly, spending money, deleting or overwriting files, calling external/destructive APIs, or changing system state. Returns a decision: "allow" (you may proceed), "deny" (do NOT proceed), or "ask" (no rule matched — not approval; use request_approval to get a human decision, or ask the user). This call does not block. FAIL CLOSED: if the result is anything other than "allow", do not perform the action. |
| request_approvalA | Request a human's explicit approval for an action and BLOCK until they decide or the timeout elapses. Use for high-stakes actions, or whenever check_action returned "ask". The owner gets an Approve/Deny prompt on Telegram. Returns "allow" ONLY if a human tapped Approve. Returns "deny" on tap-deny, on timeout (fail-closed), or when interactive approvals are unavailable (owner not on Pro, or Telegram not linked — see upgrade_required / telegram_linked). NEVER treat a non-"allow" result as permission. |
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 2 tools
check_action and request_approval have clearly distinct purposes: one performs a policy check, the other requests human approval. There is no overlap or ambiguity between them.
Both tools follow the same verb_noun pattern with snake_case: check_action and request_approval. The naming is consistent, descriptive, and predictable.
With only two tools, the set feels minimal but not unreasonable for a focused consent gate. It is borderline according to the calibration, as 1-2 tools tends to be thin, but here the two tools cover the core consent workflow.
The core consent flow is covered: check_action for policy evaluation and request_approval for handling 'ask' results or high-stakes actions. There is no dead end, though a gap exists for managing or viewing the consent policy itself, which is likely configured outside the tool surface.