# MCP

> Connect an MCP client to Signclad: the endpoint, the OAuth sign-in, the tool list, the guardrails, and what shows up in the audit trail.

Source: https://signclad.com/docs/mcp/

Signclad runs a Model Context Protocol server so an assistant can send documents, check what is outstanding, and read audit trails, with the same permissions and limits as any other client.

## Connect

One URL, and nothing to install:

```
https://api.signclad.com/mcp
```

Add it to your client as a remote or custom MCP server. There is no package to download: Signclad hosts the server, so there is no local copy to keep up to date and no version of it that can fall behind the API.

The first connection signs you in. Your client discovers the sign-in page from the endpoint, you sign in to Signclad in a browser, and you approve which workspace the assistant may act in and what it may do. Your client stores the resulting token, so you never paste an API key into a config file.

To end a connection, remove the server in your client and revoke the authorization with `DELETE /v1/oauth/authorizations/{id}`; `GET /v1/oauth/authorizations` lists what is connected. Revoking takes effect within sixty seconds and touches no other integration.

| Client | Where to add it |
|---|---|
| Claude | Settings → Connectors → Add custom connector |
| Claude Code | `claude mcp add --transport http signclad https://api.signclad.com/mcp` |
| Cursor | Settings → MCP → Add server, as an HTTP server |
| Anything else | Wherever it takes a remote or Streamable HTTP MCP server URL |

To try things without sending real documents, connect from a sandbox workspace: its documents are watermarked and excluded from billing. Sandbox emails are still delivered, so use addresses you control.

## Tools

Generated from the same OpenAPI document as the SDKs and the reference, so a tool schema cannot drift from what the API accepts.

| Tool | Does | Needs `confirm` |
|---|---|---|
| `upload_file` | Upload a local file and return its ID | no |
| `send_document` | Create and send from files | yes |
| `create_document_from_template` | Assign recipients and fields, then send | yes |
| `list_documents` | Filter and search documents | no |
| `get_document` | Read a document, including fields | no |
| `get_document_status` | Check signing progress | no |
| `download_completed_pdf` | Get the completed PDF | no |
| `remind` | Email recipients who have not finished | yes |
| `cancel_document` | Stop signing | yes |
| `list_templates` | List templates and placeholders | no |
| `get_template` | Read placeholders and field IDs | no |
| `create_template_link` | Create a public template link | no |
| `get_audit_trail` | Read document events | no |
| `validate_text_tags` | Validate local PDF or DOCX tags | no |
| `list_webhook_endpoints` | List subscriptions and receiver health | no |
| `get_webhook_health` | Diagnose webhook delivery problems | no |

## Resources and prompts

Documents and templates are exposed as MCP resources, so an assistant can read one without calling a tool: `signclad://documents/{id}`, `signclad://templates/{id}`, and the listings `signclad://documents`, `signclad://documents?status={status}`, and `signclad://documents?q={q}`. Every tool result carries a `resource_uri` so the two halves join up.

Two prompts ship with the server:

- **`send-for-signature`** ("Send something for signature") walks from a file or a template to a sent document, asking for the recipients it does not have. It takes optional `what` and `who` arguments.
- **`whats-waiting-on-me`** ("What's waiting on me") lists outstanding documents grouped by who is holding them up, optionally narrowed to one `email`.

## Guardrails

An assistant sending contracts is a real risk. These are not optional:

- **Use sandbox keys for development.** Test documents are watermarked and excluded from billing, but emails are delivered.
- **Confirm before sending.** Sending, reminding, and cancelling require `confirm: true`. Show the preview and ask for approval before calling again.
- **The key decides, not the tool.** Every tool the server registers is offered to the assistant; what it can actually do is whatever the API key behind the connection can do, checked on the server the same way any other client is. There is no client-side widening.
- **Files travel as upload URLs**, never as base64 in tool arguments, so document contents never pass through a model's context window.
- **Provenance is recorded.** Every request the server makes carries `X-Signclad-Source: mcp`, and a document created that way is stamped `source: mcp`, so "did a person or an assistant send this" has an answer. It is a label, never a permission: it changes nothing about authorization, billing, or rate limits.
- **Same limits as anything else.** The same rate limits, plan allowances, and permission matrix. MCP is not a back door.

## A worked example

> **You:** Send the standard NDA to jane@example.com, and use the sandbox.
>
> **Assistant:** calls `list_templates`, finds "Mutual NDA", calls `create_document_from_template` with `confirm: false` to preview the recipients and fields, shows you what it will send, then calls it again with `confirm: true`.
>
> **You:** What is waiting on me?
>
> **Assistant:** calls `list_documents` filtered to `status=Sent`, groups by the recipient who has not signed, and offers `remind` per document.

## Troubleshooting

| Symptom | Cause |
|---|---|
| The client asks you to sign in again and again | The connection was revoked, or the token expired and your client did not refresh it. Remove the server from the client and add it back. |
| Tools appear but every call is refused | The connection is to a workspace on a plan without API access, or the scopes you approved do not cover what was asked. Check it under **Settings → Connected applications**. |
| `send_document` returns a confirmation prompt every time | Working as intended. The assistant must pass `confirm: true` explicitly. |
| No email arrives | Check the recipient address and delivery status. Test mode sends real emails too. |
| Rate limited quickly | Creates and mutations share a 10-a-minute bucket, on sandbox and live keys alike. `upload_file` is the exception: uploads have their own 120-a-minute bucket, so a batch of files does not spend the sending budget. |

## Related

- [Authentication and keys](https://signclad.com/docs/authentication/)
- [Sandbox and test mode](https://signclad.com/docs/sandbox-and-test-mode/)
- [The MCP overview page](https://signclad.com/mcp/)