Build a Docusign Agreement Bot With Claude and MCP

04 Jun 2026

7 min

MCP

If you have spent any time in r/anthropic or r/Docusign lately, you have seen the same question over and over: how do I get Claude to actually do things in Docusign, not just talk about them? The honest answer used to be "write your own tool wrapper around the eSignature API and pray". As of late 2025, there is a better one: use the Docusign MCP server (beta).

This guide is the one we wish existed when we wired our first agreement bot. It assumes you know what Docusign envelopes are, you have used the eSignature REST API at least once, and you have heard of MCP but have not built against it yet.

What MCP gives you over a raw API

The Model Context Protocol is an open spec that standardizes how an LLM client (Claude Desktop, Claude Code, Cursor, ChatGPT desktop) talks to external tools. Instead of you hand-rolling a function-calling schema for EnvelopesApi.createEnvelope and another for EnvelopesApi.listStatusChanges, the server publishes a list of tools, resources, and prompts, and any MCP-aware client picks them up.

For Docusign specifically, that means three concrete wins:

No glue code for tool definitions. Docusign maintains the tool schema. When they add a new capability to the MCP server, every connected Claude instance gets it on the next session.
OAuth is handled by the connector. Authentication uses Docusign OAuth credentials, with existing permissions, access controls, and audit policies enforced server side. You are not minting JWTs in your prompt.
The model sees Docusign-shaped data. Tool outputs come back as MCP resources the model can re-reference later in the conversation. That matters more than it sounds. The first time Claude correctly answers "and what was the status of that NDA we sent five turns ago" without you re-pasting the envelope ID, you get it.

What MCP does not give you: a full replacement for Workflow Builder, a document assembler, or anything that touches Extension App steps inside an active workflow run. Those limitations are real and worth internalizing before you scope your bot.

Setting up the Docusign MCP server

The server is in beta. There are two paths.

Path A: developer sandbox. You can point at the Docusign demo environment immediately, no enrollment needed. This is where you should build and test. Sandbox data is fake; nothing you do there will sign a real contract.

Path B: production. Production account access requires enrollment in the beta program through the Docusign developer portal. Submit the request, wait for approval, then connect.

Once approved, the Claude side is straightforward:

Open Claude Desktop or claude.ai.
Settings -> Connectors -> Browse Connectors.
Find Docusign, click Connect, complete the OAuth handshake in the popup.
Confirm the connector shows green in your active session.

If you are building agentic workflows outside of Claude.ai (Claude Code, the Agent SDK, your own host), the same MCP endpoint is what you point at. Same OAuth, same tool surface.

A quick smoke test in Claude after connecting:

text

Using the Docusign connector, list the five most recent envelopes
in my account and summarize their status.

If you get back a real list with envelope IDs, statuses, and recipient emails, you are wired up. If you get a polite refusal or an auth error, your OAuth scopes were not granted properly. Re-run the connector setup.

Permissions: scoping the bot

This is the section most teams skip and then regret. The MCP server inherits whatever permissions the OAuth user has. If you connect as a Docusign admin, your bot is an admin. If your prompt says "void any envelope that looks weird", and the connected user can void envelopes, the bot can void envelopes.

Our rules of thumb:

Create a service user in Docusign with a dedicated role. Do not connect as a human admin. Even for development.
Start read-only. Give the bot signature scope plus read access to the accounts and templates you want it to see, and nothing else. Add write capability only after you have watched it run for a week.
Use template-only sending. A bot that can only send from approved templates cannot accidentally send a contract with the wrong indemnity clause. Lock it down at the Docusign permission level, not in the prompt.
Audit through Docusign, not through the model. The MCP server runs through Docusign's existing access controls and audit log. That is your source of truth. Do not rely on Claude's transcript.

When you do need broader scopes (envelope creation, voiding, recipient updates), grant them deliberately and write the scope in your runbook. Future-you debugging "why did the bot do that" will thank you.

A worked example: an NDA bot

Let's build the smallest useful agreement bot. Goal: a sales rep types a Slack-style message in Claude, the bot sends a mutual NDA from a pre-approved template to the right counterparty, and it can answer status questions later.

Assume you have:

A Docusign template called Mutual NDA v3 with two roles: Sender and Counterparty.
A connected Docusign MCP connector in Claude.
A Claude project (or Claude Code system prompt) for this bot.

System prompt

text

You are an NDA assistant. You can only send the template named exactly
"Mutual NDA v3". Never send any other template.

When the user asks you to send an NDA:
1. Confirm the counterparty's full name, company, and email.
2. Read the user's name and email back from the Docusign account profile.
3. Send the NDA using the Docusign MCP connector.
4. Reply with the envelope ID and a one-line status.

If the user asks about status, look up by envelope ID or by
recipient email and report current state. Never void or correct
an envelope without explicit confirmation.

Sample run

text

User: send an NDA to Priya Shah at Northwind, priya@northwind.example

Claude: Sending Mutual NDA v3 to Priya Shah (priya@northwind.example)
from your account. Confirming...

[tool call: docusign.create_envelope_from_template]
  templateId: <id of Mutual NDA v3>
  roles:
    - roleName: Sender, name: <you>, email: <you>
    - roleName: Counterparty, name: Priya Shah, email: priya@northwind.example
  status: sent

Claude: Envelope sent. ID: 8a2c-... Status: sent. Priya should get
the email within a minute.

Two things this example gets right that most demos do not

The system prompt names a single template by exact string. The bot has no path to send anything else, even if the user asks. Combined with template-only Docusign permissions, this is double belt-and-suspenders.
The bot reads the sender identity from the Docusign profile, not from chat. If you let the model populate sender details from prompt context, you will eventually send an NDA "from" whoever the user said they were that morning.

Production hardening

A bot that works in Claude Desktop on your laptop is a demo. A bot that runs as part of your team's agreement workflow is something else. Three places we always shore up before calling it production:

1. Get off interactive Claude Desktop for anything scheduled. If your bot only fires when a human types in chat, you do not need this. If it runs on a schedule or in response to a CRM event, host it through the Claude API or Agent SDK with the Docusign MCP endpoint configured server side, not through a human session.

2. Use each Docusign surface for its job. The MCP server gives an agent envelope, template and agreement-read operations and can start a Workflow Builder workflow; multi-step approvals, routing by deal value and CRM updates after signing belong in Workflow Builder, which the agent or the source system can start. If your source system has no Docusign start action, Baton is the webhook relay we built for that job.

3. Layer agreement intelligence on top of the bot, not inside it. Your bot should send and check envelopes. It should not be the thing that decides whether a redlined clause is acceptable. That is what Docusign Agreement Manager and Iris AI are for. Have the bot trigger a Agreement Manager-backed review step in Workflow Builder, and let the specialist AI handle clause analysis.

A mental model that has held up for us: the MCP bot is the hands. Workflow Builder is the process. Iris is the judgment. Mixing those layers is how you end up with a 2,000-token system prompt that nobody understands and that breaks every time Docusign ships a feature.

Where this is going

Docusign and Anthropic announced their Cowork partnership earlier this year. The MCP server is in open beta; Docusign's MCP page lists the current tools, which cover envelopes and templates, Workflow Builder workflows (including starting one) and Agreement Manager reads. If you build your bot around the layering above (hands / process / judgment), each new MCP capability slots into the right layer instead of forcing a rewrite.

If you want the broader strategic picture for connecting agents to Docusign, our MCP integration guide covers the architectural side in more depth. Build the smallest useful bot first, scope it tightly, then grow it.