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:

1. 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.
2. 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.
3. 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:

1. Open Claude Desktop or claude.ai.
2. Settings -> Connectors -> Browse Connectors.
3. Find Docusign, click Connect, complete the OAuth handshake in the popup.
4. 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:

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

Sample run

Two things this example gets right that most demos do not

1. 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.
2. 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. Catch the gaps the MCP server cannot fill. The connector is great at envelope-shaped operations and read access. It does not orchestrate multi-step approvals, route based on deal value, or call your CRM back when an agreement is signed. For that, Workflow Builder is the right primitive, and you trigger it from the source system. If your trigger system is HubSpot, Salesforce, Greenhouse, or any of the usual suspects, Baton is the production-grade relay we built precisely because rolling your own webhook plumbing for this is a tarpit.

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, and the MCP server is the first concrete deliverable. The beta surface today is mostly envelope and template operations. Expect the tool list to expand into Workflow Builder triggers, Agreement Manager queries, and App Center extension calls over the next few releases. 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.