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
- `signers`: Array of `{ label, email }`. Each 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". Signers without an address keep using the shared signing URL
- `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