You can connect DocuSign to Claude using the Model Context Protocol (MCP), and once it’s connected, Claude can look up an envelope’s status, list who still needs to sign, or draft a new one for you to send — without you switching into the DocuSign dashboard to check. This guide covers what DocuSign’s MCP server does, both ways to connect it — directly or through a gateway — and one thing worth knowing before you try: DocuSign’s OAuth isn’t currently open to every client that asks.

What the DocuSign MCP server actually does

DocuSign publishes a remote MCP server at mcp.docusign.com. It exposes envelopes — DocuSign’s term for a document sent out for signature — as tools Claude can call directly, so prompts like these work against your live account:

  • “Which envelopes I sent this week are still waiting on a signature?”
  • “Who has and hasn’t signed the vendor agreement I sent Tuesday?”
  • “Send this contract to these three recipients for signature.”
  • “Show me the status history for envelope #4471.”

Claude reads and, depending on the tools you allow, writes through the same permissions your DocuSign account already has — it isn’t a read-only mirror or a static export, it’s your account acting on your behalf, envelope by envelope.

The catch: DocuSign’s OAuth isn’t open to every client yet

Some servers in gate’s directory — Notion, Linear, Supabase — let any AI client register itself and go straight through a one-click OAuth consent screen. DocuSign’s MCP endpoint is one of a handful where that isn’t the case today: the vendor’s OAuth currently only admits clients DocuSign has allow-listed in advance, rather than opening registration to any client that shows up. In practice, that can mean a connection attempt from a new or less-common client fails at the authorization step, even though the server itself is real and documented.

This is the same gap covered in MCP OAuth scopes explained: a server supporting OAuth in principle isn’t the same claim as every client being able to walk through it today. If you hit an “unauthorized client” error connecting DocuSign, that’s the most likely reason — not a mistake in your setup. See the unauthorized client error explained for the general pattern and workarounds.

Option 1: Connect DocuSign to Claude directly

If the client you’re using is one DocuSign currently admits, the setup is:

  • Open Claude’s connector or MCP settings.
  • Add a remote server pointing at DocuSign’s MCP endpoint.
  • Sign in with your DocuSign account when prompted — standard OAuth, so Claude never sees your DocuSign password, and you can revoke access from DocuSign’s own connected-apps settings at any time.

That’s enough if Claude is the only AI client you use with DocuSign. The tradeoff shows up once you add a second client or a second person on the team: each one needs its own attempt at the same OAuth step, with the same chance of hitting the allow-list wall independently.

Option 2: Connect it once, through a gateway

If you’re already juggling more than one MCP server or more than one AI client, wiring each pair directly gets old fast — that’s the connection sprawl covered in what an MCP gateway is. The idea is to connect DocuSign (and everything else) to one gateway URL, then point every AI client at that single URL instead of reconfiguring each one and re-running the OAuth step per client.

With gate specifically, connecting DocuSign looks like this: add gate’s gateway URL to Claude once, then pick DocuSign from the DocuSign server page in the directory and sign in the same way you would directly. gate’s catalog tracks each server’s current connectivity status — including cases like this one, where a vendor’s OAuth is still allow-listed — so you know what to expect before you try, instead of finding out mid-flow. See the full list of servers on the MCP servers page.

Why this one deserves an extra minute of thought

Most tools in this series risk a bad read or an accidental edit. DocuSign is different in one specific way: sending an envelope is not really reversible. Once a signature request goes out, you can void it, but the recipient already saw it land in their inbox with your name on it — and once every party signs, the document is legally binding. A few things worth checking before or right after you connect:

  • Can it send, or only read status? A tool that can check “who hasn’t signed yet” is low-risk. A tool that can create and send a new envelope is a different category — know which ones are enabled before handing Claude a prompt like “get this contract out to legal.”
  • Whose account is it sending as? An envelope sent through your DocuSign connection carries your name and, often, your company’s branding. Recipients have no way to tell it was drafted by an AI acting on a loosely worded prompt.
  • Which templates and recipients does it default to? A vague instruction plus a tool that can auto-fill recipients from a contact list is exactly the kind of gap covered in the confused deputy problem in MCP — the agent isn’t malicious, it just has more authority than the instruction it’s acting on should have been trusted with.
  • Who else on the team can reach it? If more than one teammate connects DocuSign to their own AI client, a shared, revocable setup beats everyone holding their own send-capable grant — the same question covered in MCP access control for teams.

You can run a quick, no-signup check on any server’s tool list with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.

Troubleshooting the connection

  • “Unauthorized client” or the OAuth screen never appears. Most likely the allow-list issue above — the client you’re using may not be one DocuSign currently admits for this endpoint.
  • Sign-in succeeds but Claude can’t see an envelope you know exists. DocuSign’s tools respect your user’s own permissions in the account; an envelope sent from a different user or a folder you don’t have access to won’t show up any more than it would in the DocuSign web app itself.
  • Tools disappear after a DocuSign update. Remote servers can change their tool list without warning. If you’re connected through a gateway, that kind of change is exactly what drift detection is meant to catch — see how MCP rug pulls work for why a one-time review isn’t enough.
Where gate fits: gate’s directory lists each server’s currently verified connectivity — one-click OAuth, key-based, or allow-listed like DocuSign — so you know what kind of setup to expect before you start. Every server is scanned for prompt injection before it goes live, and every call goes into a plain-language log, which matters more for a tool that can send a legally binding document than for most. See the full gateway at /mcp-gateway.

The bottom line

Connecting DocuSign to Claude with MCP is a normal OAuth flow when the client you’re using is one DocuSign currently allows — direct if it’s your only client, or once through a gateway if you want the same access shared across every AI client on the team, with a log of what got sent. If the connection fails at the authorization step, that’s worth reading as “not allow-listed yet” rather than a broken setup. Either way, know which tools can only check status and which can actually put a document in front of someone to sign — that distinction matters more here than on almost any other server in this series.