Signing, from inside an AI assistant.
Signclad is developing a Model Context Protocol server so an assistant can send an agreement, check what is waiting, and pull the audit trail — with the same permissions, the same limits, and the same audit record as any other client.
What is the Model Context Protocol?
MCP is an open standard for connecting an AI assistant to a system it knows nothing about. The assistant asks the server what it can do; the server answers with a list of typed tools — send_document, list_documents, get_audit_trail — and the assistant calls them the way it would call any function. There is no plugin to install inside Signclad and no prompt engineering on your side. The tool schemas are generated from the same OpenAPI document as the API reference, so an assistant cannot invent a parameter Signclad does not accept.
In practice it means you can say "send the standard NDA to Maya and tell me when she signs" in your assistant, review what it proposes, and approve it. A real document goes out under your own key, against your own plan allowance, and lands in your document list like any other.
MCP or the REST API?
They are the same API. MCP is a typed front end over the REST endpoints, with the same permissions, the same rate limits, and the same plan allowances.
- Use MCP when a person is in the loop
- Ad hoc sending, chasing a signature, checking what is outstanding, pulling an audit trail in the middle of a review. The work is conversational, someone is reading the result, and approval happens in the same place as the request.
- Use the REST API when software is in the loop
- Anything on a schedule, anything triggered by your own application, anything that has to be idempotent, retried, and reconciled. Bulk sends, embedded signing, webhook-driven state changes. The developer overview covers it.
- What MCP cannot do that a key can
- Nothing. There is no endpoint reachable through MCP that an API key could not already call, and none that is reachable only through MCP. Every action is written to the audit trail with source: mcp, so "who sent this" names the assistant.
One URL, no install
Signclad runs the server. Add the URL to your assistant, sign in with your Signclad account, and approve what it may do. There is nothing to download, no package to keep up to date, and no API key to paste into a config file.
Add this to your MCP client
https://api.signclad.com/mcp
What happens when you connect
1. Your client discovers the sign-in page
2. You sign in to Signclad
3. You approve the workspace and scopes
Revoke any time under connected applications. The tools
Generated from the same OpenAPI document as the API reference, so a tool schema can never drift from what the API accepts.
| Tool | What it does |
|---|---|
| upload_file | Send a local file once and get an id to use wherever a file URL would go. |
| send_document | Create a document from files and recipients and send it. Requires an explicit confirm flag. |
| create_document_from_template | Fill a template’s roles and fields and send the result. Requires confirm. |
| list_documents | Filter by status, recipient, label, metadata, free text, or last update. |
| get_document | One document in full, fields and coordinates included. |
| get_document_status | Where one document stands, and who it is waiting on. Cheap to poll. |
| download_completed_pdf | A download link for the sealed PDF that works with your API key, or the bytes written to a path. |
| remind | Nudge whoever has not signed. Requires confirm. |
| cancel_document | Stop a document that should not be signed. Requires confirm. |
| list_templates | The workspace’s templates, marking which can actually create a document. |
| get_template | A template’s roles and a flattened field list with its api_ids. |
| create_template_link | The template’s public fill link. |
| get_audit_trail | The event chain for a document, as structured data. |
| validate_text_tags | Check a local file’s text tags before it is sent. Runs entirely on your machine. |
| list_webhook_endpoints | Your receivers, their subscriptions, and their health. Never a secret. |
| get_webhook_health | Why an endpoint is degraded, failing, or disabled. |
Resources and prompts
Documents and templates are exposed as MCP resources so an assistant can read them without calling a tool. Two prompts ship with the server: "send this for signature" and "what is waiting on me".
Guardrails
An assistant sending contracts on your behalf is a real risk. These are the limits, and they are not optional.
- Sandbox keys are the default in development. You have to deliberately connect a live key.
- Every tool that sends, cancels, or completes a document requires an explicit confirm flag. There is no path where a stray sentence mails a contract.
- Tools carry scopes. A read-only connection cannot send, and an assistant given documents:read gets exactly that.
- Files travel as upload URLs, never as base64 in tool arguments, so a document never passes through a model's context window.
- Every action is written to the audit trail with source: mcp, so "who sent this" has an answer that names the assistant.
- The same rate limits, the same plan allowances, and the same permission matrix as any other client. MCP is not a back door.
Integrate directly with
Claude or ChatGPT.
- Claude
- ChatGPT
Connect Signclad to Claude, ChatGPT, or any MCP-compatible assistant and send documents for signature from your chat. Use your templates, check who’s signed, and download the completed PDF.
- Send contracts and agreements from saved templates.
- Check signing progress and remind anyone who hasn’t signed.
- Get signed PDFs and their audit trails.
Available on Light and above. Works with Claude, ChatGPT, and other MCP-compatible assistants: add the URL, sign in, done.
You approve before documents are sent.
Connect it in a minute.
Choose Light or above, create a sandbox key, and connect your MCP client. Every paid plan includes unlimited test-mode documents.