Chaindoc MCP Server (Beta): Turn Claude and ChatGPT Into Your AI Document Employee

An MCP server is a small program that lets AI assistants like Claude Desktop or ChatGPT call external services as if they were built-in tools. The Model Context Protocol (MCP) was introduced by Anthropic in November 2024 as an open standard for connecting AI agents to real-world systems. Instead of telling the AI "explain how Chaindoc works," you can say "send this NDA to John for signature" and the AI executes it directly through the MCP server, no copy-paste, no logins, no workflow switching.

Chaindoc MCP is the first e-signature-native MCP server, currently in private beta. It turns Claude Desktop, ChatGPT (via the OpenAI Apps SDK), Cursor, and Zed into a working interface for the entire contract lifecycle: drafting, signing, verifying, and tracking. Honestly, the first time you watch Claude draft and send a contract for you, it feels like cheating.

The shift is real. According to a 2024 Salesforce State of Sales report, sales reps spend only 28% of their week actively selling; the rest goes to admin work like contract drafting, document chasing, and CRM updates. AI employees built on MCP can collapse most of that 72% into chat instructions. Aberdeen Group research shows that organizations using e-signature workflows close contracts 80% faster and process 22.6 proposals per rep per month, compared to 10.4 with manual workflows. Combine those gains with an AI agent that handles the work end to end, and the productivity ceiling moves up significantly.

This guide explains what the Chaindoc MCP server does, how it differs from a traditional API integration, what's available in the beta, and how to request access. For broader integration context, see our REST API for e-signature and document automation page and our existing CRM integration with Chaindoc and Pipedrive guide.

An AI employee, in this context, isn't a chatbot pretending to be a person. It's an AI agent with a specific set of tools and the authority to use them on your behalf. The MCP protocol gives the AI three things it didn't have before: a directory of available tools (Chaindoc operations like "create document" or "verify signature"), a structured way to call them, and a path to read back results so it can plan the next step.

Think of how a human employee handles a contract task. You email them "send the NDA to John, copy our standard IP clauses, follow up if he hasn't signed in a week." They open Chaindoc, find the NDA template, fill it in, send it, set a calendar reminder for follow-up, and check status when the deadline arrives. Each of those steps maps to a Chaindoc MCP tool: `chaindoc_create_document`, `chaindoc_create_signature_request`, `chaindoc_get_status`, `chaindoc_subscribe_webhook`. The AI agent reasons about which tools to call, in what order, and adapts based on what each step returns.

What changes for you, the human:

• You stop opening 14 browser tabs to do contract work. Most contract operations move into a single chat interface.
• The AI agent handles the boring middle (filling templates, watching for signatures, sending reminders) so you only get involved at the start (intent) and the end (review).
• Audit trails get stronger, not weaker, because every AI action is recorded by Chaindoc the same way a human action would be, with the same blockchain anchoring described in our audit trail compliance guide.

Fair warning: AI agents make mistakes. They occasionally pick the wrong template, miscount signers, or send to the wrong email when given ambiguous instructions. The MCP server returns full error messages, so the AI usually catches its own mistakes mid-task, but a human review step is still recommended for high-value contracts.

Most early MCP servers connect AI agents to read-only data: search the web, query a database, read a file. E-signature is different because it's the rare workflow where the value sits not in retrieval but in action. The AI doesn't just tell you about a contract; it sends one. That changes the productivity math by a full order of magnitude.

Three reasons e-signature fits MCP unusually well:

1. 1.
   Discrete, well-defined actions. Contract operations decompose into clean primitives (create, send, sign, verify, status, list). AI agents are good at picking the right primitive for an instruction; they're worse at improvising fuzzy multi-step workflows. E-signature operations are inherently the kind of thing you'd describe to a junior employee in one sentence.
2. 2.
   High audit-trail rigor. Most workflows that AI agents touch have weak provenance. Did the agent really send that email? Was the data clean? With Chaindoc, every AI action lands in a tamper-evident audit trail anchored to a public blockchain, the same record you'd get from a human user. This makes AI-driven contracting compliant by default for ESIGN, eIDAS, and SOX purposes; see our audit trail and legal evidence guide.
3. 3.
   Long-tail of contract variants. A typical company runs dozens of contract types (NDAs, MSAs, SOWs, vendor agreements, employment contracts, contractor agreements). Each one has slight variations by jurisdiction, industry, and counterparty. AI agents handle that variability well because they can reason about templates and clauses; rule-based automation can't.

For specific contract scenarios where Chaindoc MCP is being tested in beta, see our existing pieces on the contractor NDA for software companies, W-9 form guide for contractors, and independent contractor vs employee classification.

The Chaindoc MCP server in beta exposes seven tools that cover the full contract lifecycle. Each tool maps to a specific Chaindoc REST API endpoint, with the MCP layer handling auth, response parsing, and error context so the AI agent gets back something it can actually reason about.

Tools available in beta

• `chaindoc_create_document` , uploads a file or template variant and returns a document ID and viewer URL. The AI uses this to draft from a template based on chat instructions.
• `chaindoc_create_signature_request` , sends a document for signature to one or more signers, with optional KYC verification, signing order, and reminder schedule.
• `chaindoc_get_status` , returns the full state of a signature request: who has signed, who's pending, signing URLs for active signers, and the audit trail to date.
• `chaindoc_verify_document` , runs a Chaindoc-signed document through tamper-evident verification, returning the signature certificate, blockchain anchor, and integrity result.
• `chaindoc_list_documents` , paginated list of documents with optional filters (status, date range, signer email). Lets the AI pick up the right document when given a fuzzy reference.
• `chaindoc_get_template` — fetches a stored template plus its variable schema, so the AI knows exactly which fields to fill in.
• `chaindoc_subscribe_webhook` — registers a webhook for status events, returning the webhook ID and HMAC secret. Used to set up async notifications the AI can poll later.

What's not in beta yet

Invoicing tools, KYC orchestration, and multi-tenant OAuth are on the roadmap (see the section below). The current beta is API-key based, which is fine for individual users and small teams but doesn't yet support the per-user OAuth flow that production multi-tenant deployments will need.

If you've already integrated Chaindoc through the REST API and SDKs, the question is fair: why add a new layer? The answer is that MCP isn't a replacement for the API; it's a different surface for a different consumer. Traditional API integrations are written for code (a backend service, a CRM plugin). MCP is written for AI agents (Claude, ChatGPT, Cursor).

Once the MCP server is configured (see the beta access section below), the user-side flow is conversational. Here's a real example from beta testing.

Step 1: Open Claude Desktop and describe what you need

You type: "Send the contractor NDA to John Smith at john@acme.example, signing deadline next Friday, copy IP assignment clause from our software template."

Step 2: Claude reasons about which tools to call

Claude calls `chaindoc_get_template` to fetch your contractor NDA template, identifies the variable slots (counterparty name, email, deadline, jurisdiction), and merges in the IP assignment clause from your standard library. Then it calls `chaindoc_create_document` with the populated template.

Step 3: Claude sets up the signature request

Claude calls `chaindoc_create_signature_request` with John's email, the signing deadline, and (optional) KYC verification. It returns a confirmation: "Document drafted from template `Contractor NDA v3`, sent to john@acme.example, signing URL active until Friday May 9 at 23:59 UTC."

Step 4: Claude registers a status webhook

Claude calls `chaindoc_subscribe_webhook` to listen for the `signature.completed` event, so you'll get a notification in Claude when John signs without you having to poll. The whole flow takes about 60 seconds from your initial message to the signature request being live in John's inbox.

Step 5: Verification on completion

When John signs, the webhook fires, and Claude reports the result. You can then ask Claude to verify the signature, and it'll call `chaindoc_verify_document` to confirm the blockchain anchor, signature certificate, and audit trail. The same verification you'd do manually at /verify-document, but inside the chat where you started.

Look, the experience varies by AI model. Claude Desktop is currently the smoothest because Anthropic built MCP. ChatGPT via the Apps SDK works well but has slightly more latency. Cursor and Zed are great if you live in a code editor anyway. The protocol is standardized, so over time the experience should converge across clients.

Every action an AI agent takes through the MCP server flows through the same Chaindoc backend that handles human actions. There's no shadow path, no separate logging, no "AI bypass" mode. The audit trail captures the same seven required fields described in our audit trail compliance guide, with one addition: the AI agent's session is tagged so you can see which actions were AI-initiated versus human-initiated.

Specifically:

• Identity: the API key (in beta) or OAuth user token (at GA) identifies the human account on whose behalf the AI is acting. Every action is traceable to a real person, not a generic "AI agent" identity.
• Authentication: API keys can be scoped (read-only, write, admin) so beta users can grant minimum-necessary access to specific AI clients.
• Action provenance: the audit log records that the action came through MCP, plus which client (Claude Desktop, ChatGPT, Cursor, etc.) and which tool was called. So if a contract was sent by Claude on your behalf, the trail shows "sent via MCP, client: claude-desktop, tool: chaindoc_create_signature_request, user: alex@chaindoc.example."
• Tamper-evidence: every audit entry is hash-chained and anchored to a public blockchain, exactly the same as direct human actions. AI-driven contracts are no less defensible than manually sent ones; in some ways they're more defensible because the structured tool call is preserved alongside the human chat instruction.

For the underlying compliance frameworks, see our digital signature compliance with eIDAS, GDPR, and NIST and legal strength of blockchain e-signatures. For team-level access controls that govern who can connect AI clients to your account, see /team-management.

As of May 2026, no major e-signature vendor has launched a public MCP server. The closest comparisons are AI-feature announcements within existing products (Docusign IAM and Docusign AI, Ironclad's AI review tools), but none expose those capabilities to external AI agents through an open standard. The table below summarizes the field.

The beta is invite-only, with limited slots prioritized for active Chaindoc customers and developer-heavy organizations. Beta participants get free access through general availability, dedicated Slack support from the engineering team, and a direct line for feature requests.

Three ways to request access

1. 1.
   Existing customers: log into your Chaindoc dashboard and look for the "AI Agents" section under Settings. The beta toggle is there.
2. 2.
   New evaluators: sign up via /api-integration and check the "MCP beta" box on the developer onboarding form.
3. 3.
   Direct request: email beta@chaindoc.io with your use case (1-2 sentences), team size, and which AI client you want to connect (Claude Desktop, ChatGPT, Cursor, Zed). We respond within 2 business days.

Installation, once you have access

The beta ships as an npm package. After receiving your API key, add the following to your Claude Desktop config (`~/Library/Application Support/Claude/claude_desktop_config.json` on macOS, equivalent paths on Windows and Linux):

Restart Claude Desktop. The 🔌 icon should show "chaindoc" connected with 7 tools available. The first tool call typically completes in 2-3 seconds.

For Cursor, Zed, and Windsurf, the config is similar; full instructions ship with your beta invite. ChatGPT support via the OpenAI Apps SDK is in private testing and will roll out after Claude Desktop reaches GA.

The current beta covers contract drafting, signing, verification, and tracking. Three capabilities are in active development for later beta phases and general availability:

Invoicing automation

A `chaindoc_create_invoice` tool that generates an invoice tied to a signed contract, with payment terms, line items, and Stripe / wire instructions. The tool reads the contract's payment schedule, generates the invoice on the right date, and (optionally) sends it via the existing Chaindoc audit trail. See our existing contract-linked payments and billing automation for the human-side workflow this builds on, plus the automating billing after eSignature deep dive.

KYC orchestration

A `chaindoc_request_kyc` tool that triggers identity verification for a signer before they sign. The AI agent can reason about which signers need full KYC (high-value contracts, regulated industries) versus light verification (standard NDAs), and configure the signing request accordingly. Currently, KYC is configured at the request level by humans; the goal is to let the AI handle that decision.

Multi-agent workflows

Looking further out, MCP supports agent-to-agent communication. So a Chaindoc MCP server can call out to a CRM MCP server (HubSpot, Salesforce), a calendar MCP server (Google, Outlook), or a payment MCP server (Stripe). A signed contract can trigger a CRM update, a calendar reminder, and an invoice issuance, all coordinated by the AI agent rather than by hardcoded webhooks. This is the architecture that turns AI from a writing tool into a real operations layer.

AI features tacked onto existing products are everywhere right now. Auto-drafting clauses, smart redlining, contract review summaries: every legacy vendor is shipping these. They're useful, but they're features. They live inside the vendor's UI and require the human user to drive the workflow.

AI-native e-signature is structurally different. The unit of value isn't "what can our product do for you" but "what can your AI agent do on your behalf, anywhere it lives" (Claude Desktop, ChatGPT, Cursor, your own custom client). That changes the buying criteria. Speed of contract execution stops being measured in minutes per signature and starts being measured in chat-instructions per outcome. Audit trails stop being a defensive compliance feature and become a precondition for trusting AI-driven workflows at all.

Chaindoc is making an early bet that this category becomes the dominant one over the next 24 months. The MCP server is the first concrete step. If you're an existing customer, the beta toggle is in your dashboard now. If you're evaluating e-signature tools with AI on the roadmap, request beta access through /api-integration and tell us what AI client you want to connect.