Skip to main content
Glama
Nauti-Labs

clearance-mcp

by Nauti-Labs
README.md
# clearance-mcp

> Model Context Protocol server for [Clearance](https://clearance.nauti-labs.com) — the human approval API for AI agent commerce.

Stop letting agents move money you didn't approve. One API call. The human approves with one tap. Any service verifies the signed token.

---

## What This Is

An MCP server that exposes Clearance as a set of tools Claude (and other MCP-compatible clients) can call natively. Your AI agent can:

- Request human approval before spending money
- Check approval status
- Approve, deny, or revoke a clearance
- Verify signed tokens
- Manage API keys and usage

---

## Installation

### Via npm (recommended)

```bash
npm install -g clearance-mcp
```

Or run directly via npx:

```bash
npx -y clearance-mcp
```

### Via GitHub (if npm not available)

```bash
npx -y github:Nauti-Labs/clearance-mcp
```

---

## Configuration

### Claude Desktop

Add to your Claude Desktop config (`~/Library/Application Support/Claude/claude_desktop_config.json`):

```json
{
  "mcpServers": {
    "clearance": {
      "command": "npx",
      "args": ["-y", "clearance-mcp"],
      "env": {
        "CLEARANCE_API_KEY": "clr_live_..."
      }
    }
  }
}
```

### Environment Variables

| Variable | Required | Description |
|----------|----------|-------------|
| `CLEARANCE_API_KEY` | ✅ | Your Clearance API key (get free at clearance.nauti-labs.com) |
| `CLEARANCE_BASE_URL` | ❌ | Override API base URL (default: https://clearance.nauti-labs.com) |

---

## Available Tools

| Tool | Clearance API | Description |
|------|---------------|-------------|
| `clearances_create` | `POST /v1/clearances` | Create a human approval request. Requires `title` and `scope`. |
| `clearances_get` | `GET /v1/clearances/{id}` | Get one clearance by ID |
| `clearances_list` | `GET /v1/clearances` | List clearances. Optional `status` and `limit` (API default 50). |
| `clearances_approve` | `POST /v1/clearances/{id}/decide` | Approve a pending clearance (`approved: true`) |
| `clearances_deny` | `POST /v1/clearances/{id}/decide` | Deny a pending clearance (`approved: false`) |
| `clearances_revoke` | `POST /v1/clearances/{id}/revoke` | Revoke an approved clearance so its token no longer verifies |
| `verify_token` | `GET /v1/verify/{token}` | Verify a signed approval token |
| `keys_create` | `POST /v1/keys` | Create a Starter API key. Requires `email`. |
| `usage_get` | `GET /v1/usage` | Check credits used, credits remaining, and the current period |

### Request fields

`clearances_create` sends `title`, `scope`, and any of `description`, `budget_amount`, `budget_currency`, `callback_url`, `metadata`, and `expires_in` (seconds, API default 3600). The response link for the human is `approval_url`. `webhook_url` is accepted and sent as `callback_url`.

`clearances_list` returns a JSON array. Status filters are `pending`, `approved`, `denied`, `expired`, and `revoked`. Pagination is `limit` only.

`clearances_approve` and `clearances_deny` both call `/decide`. Body is `{ "approved": true|false, "note"?: string }`. `reason` is accepted as an alias of `note`.

`keys_create` sends `{ "email", "name"? }`. New keys are always the free Starter tier. The response field for the secret is `api_key`.

`usage_get` returns `tier`, `credits_used`, `credits_remaining`, `clearances_this_month`, `period_start`, and `period_end`.

---

## Example Usage

In Claude, after the MCP server is connected:

> **You:** "I want to book a $500 flight. Can you ask for approval first?"
>
> **Claude:** *calls `clearances_create` with title="Book flight to Austin", scope="purchase:flight", budget_amount=500*
>
> **Claude:** "I've created an approval request. Open the `approval_url` to approve or deny: [Approve](https://clearance.nauti-labs.com/approve/clr_abc123). Once you approve, I'll proceed with the booking."

---

## Pricing

Clearance pricing:

- **Starter** — Free, 50 clearances/month
- **Pro** — $19/mo, 1,000 clearances/month
- **Scale** — $49/mo, 10,000 clearances/month

Get your free key at [clearance.nauti-labs.com](https://clearance.nauti-labs.com).

---

## Links

- **Product:** [clearance.nauti-labs.com](https://clearance.nauti-labs.com)
- **Company:** [nauti-labs.com](https://nauti-labs.com)
- **API Docs:** [clearance.nauti-labs.com/v1/docs](https://clearance.nauti-labs.com/v1/docs)

---

Built by [Nauti-Labs LLC](https://nauti-labs.com) · Mont Belvieu, TX

TDQS

A4/5.0

Scored across 9 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues