clearance-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLEARANCE_API_KEY | Yes | Your Clearance API key (get free at clearance.nauti-labs.com) | |
| CLEARANCE_BASE_URL | No | Override API base URL | https://clearance.nauti-labs.com |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| clearances_createA | Create a human approval request. Requires title and scope. Returns the clearance, including approval_url. The human opens that URL to approve or deny; poll clearances_get or pass callback_url to hear the decision. |
| clearances_getA | Get one clearance by ID. Returns status, approval_url, expiry, and the signed token when status is approved. |
| clearances_listA | List clearances for this API key. Optional status filter and limit (API default 50). Returns a JSON array, newest first. Status values: pending, approved, denied, expired, revoked. |
| clearances_approveA | Approve a pending clearance. Calls POST /v1/clearances/{id}/decide with approved=true. Returns id, status, decided_at, and the signed token. |
| clearances_denyA | Deny a pending clearance. Calls POST /v1/clearances/{id}/decide with approved=false. Optional note is stored as the decision note. |
| clearances_revokeA | Revoke an approved clearance. Calls POST /v1/clearances/{id}/revoke. The signed token will no longer verify. |
| verify_tokenA | Verify a signed clearance token via GET /v1/verify/{token}. No authentication is required by the API. Returns valid, clearance_id, scope, budget, approved_at, expires_at, and error when invalid. |
| keys_createA | Create a new Clearance API key. Email is required. Keys always start on the free Starter tier (50 clearances/month); tier cannot be chosen here. Returns api_key, tier, credits_remaining, and a message. The raw key is only shown once. |
| usage_getA | Get usage for this API key: tier, credits_used, credits_remaining, clearances_this_month, period_start, and period_end. |
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 9 tools
Each tool maps to a distinct clearance lifecycle action or auxiliary operation: list, create, get, approve, deny, revoke, verify token, create key, and get usage. Approve and deny are related decisions but are clearly separated by intent and outcome. There is no meaningful overlap between tools.
Most tools follow a consistent resource_action pattern such as clearances_list, clearances_create, keys_create, and usage_get. The only notable deviation is verify_token, which uses verb_noun ordering. The convention is still highly predictable overall.
Nine tools is a well-scoped set for a clearance approval workflow API. Each tool earns its place by covering a distinct operation rather than duplicating functionality.
The core clearance lifecycle is well covered: create, list, get, approve, deny, revoke, and token verification. API key management is only partially covered because keys can be created but not listed or revoked, and usage is limited to a single get operation. These are minor gaps rather than blockers for the primary clearance workflow.