Skip to main content
Glama
README.md
# addsign-mcp

MCP server for [AddSign](https://addsign.io) — lets AI agents send documents
for signature, track signing status, remind signers, and download signed,
hash-verifiable PDFs.

Stateless by design: it speaks only AddSign's public v1 API with **your** API
key. No database access, no shared secrets. Revoking the key at
[addsign.io/settings/api](https://addsign.io/settings/api) kills the
integration instantly.

## Setup

1. Create an API key at **addsign.io → Settings → API Keys** (free on every
   plan; Free includes 8 documents/month).
2. Set it in the environment — never in prompts or config committed to git:

```bash
export ADDSIGN_API_KEY=sk_...
```

### Claude Code

```bash
claude mcp add addsign --env ADDSIGN_API_KEY=sk_... -- npx -y addsign-mcp
```

(Until the npm package is published, point at a checkout instead:
`claude mcp add addsign --env ADDSIGN_API_KEY=sk_... -- node /path/to/simple-sign/mcp/dist/index.js`)

### Claude Desktop (`claude_desktop_config.json`)

```json
{
  "mcpServers": {
    "addsign": {
      "command": "node",
      "args": ["/path/to/simple-sign/mcp/dist/index.js"],
      "env": { "ADDSIGN_API_KEY": "sk_..." }
    }
  }
}
```

### Environment

| Variable | Required | Default | Purpose |
|---|---|---|---|
| `ADDSIGN_API_KEY` | yes | — | Your AddSign API key (`sk_...`) |
| `ADDSIGN_BASE_URL` | no | `https://addsign.io` | Point at a different deployment |

## Tools

| Tool | Kind | What it does |
|---|---|---|
| `list_templates` | read | Templates + the signer roles each expects + field summary |
| `send_for_signature` | write | Create from template + email signers; idempotent via `request_id` |
| `check_status` | read | Document + per-signer state + recent audit events |
| `download_signed` | read | 5-minute signed URL + the ledger's SHA-256 for verification |
| `remind` | write | Nudge pending signers (4h per-signer server-side cooldown) |
| `list_documents` | read | Paginated document list, filterable by status |

No destructive tools: an agent cannot cancel or delete a legal document
through this server.

## A typical agent flow

```
list_templates                      → find "Contract to Lease", roles: [tenant_1, tenant_2]
send_for_signature {template_id,
  signers: [Artem…, Valeria…],
  request_id: <uuid>}               → document_id, status: pending, usage 3/8
check_status {document_id}          → Artem signed, Valeria viewed
remind {document_id, valeria@…}     → reminded (or skipped: reminded_recently)
download_signed {document_id}       → url + sha256 → fetch, verify, file it
```

## Error semantics

Every AddSign error carries a stable `error_code`; this server appends the
right next step for the agent. The two that matter most:

- `rate_limited` (429) — back off `retry_after` seconds, retry.
- `plan_limit_reached` (402) — **never retry**; the monthly cap resets on the
  1st or the human upgrades.

## Development

```bash
cd mcp
npm install
npm run build     # → dist/index.js
ADDSIGN_API_KEY=sk_... node dist/index.js
```

TDQS

A4.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct action: checking status, downloading signed documents, listing documents, listing templates, sending reminders, and sending for signature. No overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores, e.g., check_status, download_signed, list_documents. Even 'remind' is a verb alone but fits the pattern of single-action tools.

Tool Count5/5

With 6 tools, the set is well-scoped for a document signing server. It covers listing, sending, and managing documents without being overly sparse or bloated.

Completeness4/5

The tool set covers the core workflow: list templates, send for signature, check status, remind, and download. Minor gaps exist, such as no tool to create templates or void documents (must be done via dashboard), but these are acceptable for the focused scope.

Maintenance

ActivityMaintained
ResponsivenessNo issues