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 [email protected], 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
• Sandbox and test mode
• The MCP overview page