MCP vs API for e-signature: what changes when an AI agent sends the contract

An API is a set of endpoints a developer writes code against. An MCP server is a small program that sits on top of an API and describes those endpoints as tools an AI model can find and call by itself. That's the MCP vs API difference in one line: the API is for your code, the MCP server is for an agent. For e-signature it decides who picks the next step. With the Chaindoc REST API, your code decides when a contract goes out. With Chaindoc's MCP server, the agent decides, inside the limits of the key you gave it. The signature never moves to the agent, and that's where most of this guide spends its time.

So what is an MCP server? It's the server half of the Model Context Protocol (MCP), an open standard Anthropic published on November 25, 2024 for connecting AI applications to outside tools and data. In December 2025 the protocol moved to the Agentic AI Foundation under the Linux Foundation, so no single model vendor owns it now. The current specification is dated 2026-07-28.

MCP has three roles. The host is the AI app you talk to, the client is the connector inside it, and the server exposes what an outside system can do, in three kinds:

• Tools: functions the model may call, such as "create a signature request".
• Resources: data the model or the user can read, like the status of one contract.
• Prompts, which are named jobs a user can start.

Messages are JSON-RPC 2.0. A server runs either as a local process the client launches (the stdio transport) or behind an HTTP endpoint (Streamable HTTP).

Is an MCP server a real server, then? Sometimes. A stdio server is a process on your laptop that starts and stops with your AI client. An HTTP server is a service somebody has to host.

So why is MCP vs API a false choice? Because nearly every useful MCP server wraps an API that already exists. Chaindoc's maps its tools onto the same REST endpoints your backend would call. You don't pick one. You pick who's driving: your code, or a model.

The endpoints underneath are identical. The difference between MCP and API is everything around the call, and five parts of it show up the moment an agent is the caller.

1. 1.
   Discovery. Your code knows the API because a developer read the docs. An MCP client asks the server for its tool list (tools/list) at runtime and hands the names, descriptions and input schemas to the model. If you've used function calling, it's the same idea in a shared format, so one server works in every MCP client.
2. 2.
   Who chooses the call. In an API integration the sequence is written in code and runs the same way every time. Through MCP the model picks the tool and fills in the arguments from your sentence, so one request can run two different ways on two days.
3. 3.
   Errors go back to the model. The specification separates protocol errors from tool execution errors, and the second kind is meant to reach the model so it can fix an argument and retry. A backend would log it and stop.
4. 4.
   Credentials sit in a config file. A stdio server reads its key from an environment variable your AI client passes in. Whoever can edit that file decides what the agent may do.
5. 5.
   Approval is the client's job. The MCP specification's tools page says a human SHOULD stay in the loop "with the ability to deny tool invocations", and that clients should ask for confirmation on sensitive operations. A call from your backend has no such step unless you build one.

Honestly, number two is the one that matters for contracts. A script that sends an NDA sends exactly the NDA it was written for. An agent sends whatever it understood you to mean. For a document someone will sign, that gap needs a gate.

The Chaindoc MCP server is open source. The code is on GitHub under the MIT licence, and the package is @chaindoc_io/mcp-server on npm, version 0.2.0 when we checked on October 14, 2026. Most tools map to a single REST endpoint and hand the result back in a shape the model can read.

The tools, by group

The README's core tables list 35 tools in ten groups:

• Documents: create, update, set access rights, verify a version, read its verification status.
• Signatures: create a request, read its status, list your requests, and sign.
• Contracts, the longest group: create, list, read, send, cancel, terminate, read activity, attach a payment setup.
• Invoices and transactions for billing from a signed contract: create, send, charge, mark paid, list payments.
• Templates: turn one into a document or a contract, or send it for signing directly.
• Media upload, embedded signing sessions, two account checks, a webhook verifier.

Version 0.2.0 added search, versions, reminders, cancellations, downloads of the signed file and its certificate, and the template lifecycle.

Resources and prompts

Read-only resources such as chaindoc://contracts/{id}/status sit beside named prompts like prepare_signature_request that walk the model through a longer job.

Two things it doesn't do. It doesn't register webhooks: those are set per API key in the dashboard, and the webhook tool only checks an event you've already received. And there's no hosted Chaindoc endpoint, so you run it over stdio or host the HTTP mode yourself.

Verification is the Chaindoc-specific part. The server hashes a file on upload; when a version is published, that hash goes on chain, and each signer's proof is recorded when signing completes. The verify tools check a version against that record, so an agent can answer "is this the file that was signed?" without anyone opening the app.

There's no separate MCP API key. The server runs on an ordinary Chaindoc API key, and keys are created on the Business plan. Team accounts can ask for API access; Free and Personal can't create keys, and webhooks are Business-only.

Two limits shape how an agent behaves. The server throttles itself to 10 requests a minute by default, the limit Chaindoc's API guide sets, so an agent looping over fifty documents is slow on purpose. And agent traffic runs on your account like any other API call, so the requests it sends come out of the same monthly signature allowance. Check current pricing before you let an agent send in bulk.

Short answer: an agent can press the button, but the law never treats it as the signer. Whoever the agent acts for is, and that's where most worries about AI contracts end up.

In the US: ESIGN and UETA

ESIGN defines an electronic signature as a sound, symbol or process "executed or adopted by a person with the intent to sign the record" (15 U.S.C. § 7006(5)). Intent belongs to a person. For software, 15 U.S.C. § 7001(h) says a contract isn't denied effect because an electronic agent helped form it, as long as the agent's action is "legally attributable to the person to be bound". UETA, adopted by every state except New York, adds two rules. Under § 14 a contract can form between electronic agents even if no individual reviewed the terms. Under § 9 a signature is attributed to a person by showing it was their act, for instance through the security procedure used. With an MCP server, that procedure is the API key.

So you're bound by what your agent does within the authority you gave it, which in practice is the scope of the key. And UETA § 10 cuts the other way: an individual who dealt with your electronic agent and had no chance to prevent or correct an error can avoid the mistaken record if they act promptly. A flow with no review step is a risk you built yourself.

In the EU: eIDAS

Regulation (EU) No 910/2014 is stricter on paper. Article 3(9) defines the signatory as "a natural person who creates an electronic signature", so a model can't be one. A company that wants documents marked without a person behind each one has another instrument, the electronic seal, created by a legal person under Article 3(24). Our guide to electronic seals for companies covers when that fits.

For an MCP workflow the practical line is simple. Let the agent prepare, send, chase and verify. Keep the act of signing with the person whose intent the signature records, unless you've decided in writing that a given agent may sign a given kind of document for you. Treat this as the frame, not as legal advice for your contract.

Four points in a signing flow deserve a person. The boring middle isn't one of them.

• Before anything is sent. Your client's confirmation prompt should cover every tool that sends, signs, cancels, terminates or charges. Read-only calls can run without asking.
• Signers and their order. A request the agent creates invites every signer at once. If the order matters (a manager approves before the client signs), that's an approval route you set up in the Chaindoc app on the Business plan, not something the agent improvises.
• Identity, when the stakes call for it. KYC checks on signers are optional, through Chaindoc's identity verification with a monthly quota per plan. Decide per contract type; don't leave it to the model.
• What the agent reads. Text can carry instructions you didn't write: a line in an uploaded PDF, a note in a CRM record. The MCP specification treats tool annotations from a server you don't trust as untrusted for the same reason.

What can run unattended? Status checks, reminders to people who already have the document, verifying a file against its on-chain record. Each document keeps its own audit trail, so even the unattended calls leave a record you can read back.

DocuSign announced on September 4, 2026 that its MCP server would be generally available on September 30, callable from Claude, ChatGPT, Gemini, Copilot, Slack and any MCP client. DocuSign hosts it, and you connect through an OAuth sign-in and a consent screen instead of pasting a key into a config file. That's a real advantage for a company that doesn't want API keys sitting on laptops, and Chaindoc doesn't offer a hosted endpoint today.

On the MCP vs API axis the two are alike: each server wraps its vendor's own API. That said, the trade runs the other way on control. Chaindoc's server is MIT-licensed code you can read, fork and host inside your own network, and its tools reach the on-chain verification record as well as signing. If you're weighing a DocuSign MCP connection against Chaindoc's for an agent, ask three practical questions: who holds the credential, where the server runs, and which actions the agent can take without a person approving them.

Use the API when the flow is fixed. A deal moves to won, a contract goes out from a template, a webhook updates the CRM when it's signed. That's code, it should behave the same every time, and an agent only adds variance. If you want AI document automation inside a fixed flow, call a model from your own code and let the API do the sending. Our comparison of e-signature APIs covers what to check on that side.

Use the MCP server when the request is different every time and a person is in the conversation anyway: "send the contractor agreement to the two people from yesterday's call", "which NDAs from last month are still unsigned?", "is this PDF the version we signed?". Those are awkward to script and easy to say.

Most teams end up with both, on separate keys, and that's the honest answer to MCP vs API. The API runs what you've already decided. The agent handles what you haven't. In both cases the signature stays with a person.