Skip to main content
Glama
README.md
# CanUSign MCP Server

MCP (Model Context Protocol) server for CanUSign. Allows Claude to create and manage contracts.

## Installation

```bash
git clone https://github.com/devin-lemcke/canusign-mcp-server
cd canusign-mcp-server
npm install
npm run build
```

## Configuration

### 1. Get your API Key

Go to [CanUSign Settings](https://canusign.com/settings) and create an API key.

### 2. Configure Claude Code

Add the following to your Claude Code MCP settings (`~/.claude/claude_desktop_config.json` or via Claude Code settings):

```json
{
  "mcpServers": {
    "canusign": {
      "command": "node",
      "args": ["/path/to/canusign-mcp-server/dist/index.js"],
      "env": {
        "CANUSIGN_API_KEY": "canu_your_api_key_here"
      }
    }
  }
}
```

Or if using npx (after publishing to npm):

```json
{
  "mcpServers": {
    "canusign": {
      "command": "npx",
      "args": ["canusign-mcp-server"],
      "env": {
        "CANUSIGN_API_KEY": "canu_your_api_key_here"
      }
    }
  }
}
```

## Available Tools

### `create_contract`

Create a new contract for signing.

**Parameters:**
- `title` (required): Title of the contract
- `content`: HTML content of the contract (give this or `document`)
- `document`: Your own PDF, as `{ path }` (a file on this machine) or `{ pdf }` (base64), up to 3 MB
- `language`: de, en, es or fr (default en)
- `signatureFields`: Array of `{ label }` for HTML content. With a `document` each field also
  takes `page`, `x`, `y`, `width`, `height` in percent of the page, origin top-left, where `x`/`y`
  is the top-left corner of the field
  and an optional `type`: `signature` (default), `initials`, `date` or `text`. Every type
  except `text` needs a `label`. `date` prints the day that label signs, so the label also needs
  a `signature` or `initials` field. `text` needs `text` (at most 500 characters) and prints it
  as is. Only `signature` works with HTML content
- `signers`: Array of `{ label, email?, title?, level? }`, one entry per field label. With an
  `email` the signer gets a signing link of their own by e-mail. The link opens only the fields
  of that label, and the audit certificate records the address as "link delivered to". Without
  an address the signer keeps using the shared signing URL. `title` such as "Managing Director"
  (at most 80 characters) presets what the signer signs as, with or without an address
- `tags`: Array of tags for organization
- `finalize`: If true (default), contract is ready for signing

**Example:**
```text
Create a service agreement contract between Acme Corp (client) and John Doe (provider) for web development services at $5000. Add signature fields for both parties.
```

**Example with delivered links:**
```text
Create a service agreement between Acme Corp and John Doe. Send the signing link for "Client" to anna@acme.example and let John sign on my laptop.
```

### `update_contract`

Rename, retag or finalize a draft, and send or resend signing links.

**Parameters:**
- `id` (required): Contract ID or token
- `title`, `tags`, `finalize`
- `signers`: Array of `{ label, email }`. The same address resends the link, a new address
  replaces it and the old link stops working. At most 5 sends per signer in 24 hours

### `list_contracts`

List all contracts with optional filtering.

**Parameters:**
- `status`: Filter by status (draft, pending, pending_payment, fully_signed)
- `limit`: Maximum number of results

### `get_contract`

Get details of a specific contract.

**Parameters:**
- `id` (required): Contract ID or token

### `delete_contract`

Delete a contract (refused once anyone has signed).

**Parameters:**
- `id` (required): Contract ID or token

## Environment Variables

- `CANUSIGN_API_KEY` (required): Your CanUSign API key
- `CANUSIGN_API_URL` (optional): API base URL (default: https://canusign.com)

## Development

```bash
# Install dependencies
npm install

# Build
npm run build

# Watch mode
npm run dev
```

## License

MIT

TDQS

A4/5.0

Scored across 6 tools

Disambiguation4/5

The tools are mostly distinct: create/update/list/get/delete cover contract lifecycle, and list_attachment_types is clearly a supporting lookup. Minor ambiguity exists between get_contract and list_contracts, but their descriptions (specific vs. list) make the boundary clear.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: create_contract, update_contract, list_contracts, get_contract, delete_contract, list_attachment_types. The pattern is uniform and predictable.

Tool Count5/5

Six tools is well-scoped for a contract-signing server: full CRUD plus a supporting lookup for attachment types. Each tool earns its place without redundancy or bloat.

Completeness4/5

The contract lifecycle is well covered: create, update, list, get, delete, plus attachment-type lookup. A minor gap is the lack of a dedicated tool to view signing status/activity beyond what update_contract returns, but the core workflows are complete.

Maintenance

ActivityMaintained
ResponsivenessNo issues