How We Made the Docusign MCP Server Production-Ready

A year ago, a small group of us built a Docusign MCP server as a hackathon project. The goal was simple: show what happens when an AI model can work directly with Docusign. That hackathon project became a production system faster than any of us expected. 

In February 2026, we went to production as a closed beta with Claude. Over the next few months, we learned a lot about MCP, modern LLMs, and our customers. We learned what they wanted to do, which use cases mattered, and where they wanted to work. On September 30, 2026, we reached general availability.

The Docusign MCP Server has official connectors for Claude, ChatGPT, Gemini, Slackbot, Microsoft Copilot, and Perplexity. Thousands of users have already made millions of tool calls through these integrations.

Connecting a model to our tools turned out to be the easy part. The protocol handles that well. Here were the two other questions that kept my team up at night:

1. Will the agent reliably complete the job? Will it call the right tool, follow our descriptions, and respect our schemas?

2. How do we know it still works and stays secure, as everything around it changes?

In this post, I'll share how we addressed these challenges using guided MCP Apps, automated evaluations, and continuous security testing.

Watch the video below for a walkthrough of the engineering approaches we used to make the Docusign MCP Server production-ready.

Make critical MCP workflows predictable

If you let the model figure out every step, you get flexibility, but also unpredictability. The model can skip a step, stop halfway, or confuse two similar-looking concepts. Critical steps need to be predictable.

We saw this firsthand during the closed beta. At Docusign, an envelope and an agreement are different things, and that distinction matters. Models regularly mixed them up. We used two patterns to address this.

Routing for ambiguous requests. We don't let the model guess. A routing step makes the model ask the user what they actually mean. When a user says, "I want to send an agreement for signature," our resolveEnvelopeSendMethod tool returns three explicit options: use an existing template, upload a local file, or provide a URL. The model doesn't pick one at random. It asks the user. That small human-in-the-loop step solved most of our ambiguity problems and ensures nothing executes without the user's consent. 

When a request is ambiguous, the routing step has the agent ask the user how to provide the document instead of guessing.

MCP Apps for steps that must happen in a specific way. Once we know the user's intent, we stop relying on the model to describe every field in prose. An MCP-App renders a guided, interactive flow right inside the chat. 

For sending a contract, that flow has four steps: add documents, add recipients (including name, email, and signing order), add a message (the subject line is prefilled and editable), and then place fields or send. Critical steps, such as specifying who signs, which fields they complete, and how to send the agreement, happen the same way every time.

The MCP App lets users upload multiple files without leaving the chat.

The MCP App walks the user through uploading a contract, adding recipients, and sending it, all without leaving the chat.

The send step completes inside the MCP App and confirms that the agreement was sent.

The model still adds value around the flow. After sending, I can ask, "What's the status of the agreement I just sent?" The agent correctly calls getEnvelope and tells me who has signed and who hasn't.

It also handles broader questions. When I asked it to “review my agreements and identify any renewals coming up in the next 30 days,” the agent identified two customers with renewal dates approaching in the next 15 days and suggested taking action. Beyond retrieving agreement information, the model can identify patterns that help users decide what to do next.

The rule we follow is: be deterministic where it matters and intelligence-driven where it helps.

A healthy server can still hide broken behavior

MCP introduced us to a failure mode I call silent breakage. Your server responds, the trace looks fine, and every call returns HTTP 200. Meanwhile, the agent picked the wrong tool, passed the wrong arguments, or stopped one step short. You don't find out until a customer does.

Several changes can cause this: a prompt tweak, an updated tool description, a schema change, an SDK upgrade, or a new model version. We ship changes like these constantly. Before each release, we spent about 80 hours on manual regression testing, yet we still missed edge cases. That approach doesn't scale.

Test MCP behavior like software

So we automated it. We built an evaluation harness on Promptfoo opens in a new tab, the open-source eval framework, and extended it for our needs. Because we extended it rather than forking it, we can keep picking up upstream improvements.

The harness doesn't stop at checking for an HTTP 200 response. For each use case and prompt, it runs four kinds of assertions:

• Tool sequence: Did the agent call the expected tools in the expected order?

• Tools used: Did it stay within the allowed set of tools for this task? If it uses extra tools, the test fails.

• Step count: Did it finish within the step budget, rather than trying again and again until something worked?

LLM rubric: We get ground truth by calling our API directly, then ask a grader model to compare the agent's answer against it. The grader uses a different model family from the model under test. The test passes only if the score clears a threshold.

Each eval case scores four assertion types: tool sequence, tools used, step count, and an LLM rubric checked against ground truth.

An eval run against the Docusign MCP server, showing pass rate, assertion results, token usage, and cost. Figures are illustrative.

Here's an example of a failure the harness caught. In one test, a user asked the agent to cancel a workflow instance. The agent found the right instances and wrote a confident, reasonable-sounding summary, but it never called cancelWorkflowInstance. The server showed no errors, so only the eval caught it.

The eval flags a missing required tool call, even though the agent's response reads as plausible.

The harness runs in CI on every change. If anything breaks, the change doesn't move past the first environment. We also run it on a schedule against production to catch drift, such as changes caused by model updates outside our control. A regression cycle that used to take about 80 hours now takes under two.

Evals and security cases run on every change in CI, gate promotion past the first environment, and run on a schedule against production.

The harness also reports token usage, cost, and latency for every run. Every run reports token usage, cost, and latency, so we can optimize flows to use fewer tokens. That lowers our costs and our customers' costs, while the evals help confirm we haven't traded away reliability to get there.

Shift MCP security testing left

At Docusign, every release goes through a security architecture review and an offensive security review that includes penetration testing. Surprises at that stage are expensive. They can force architecture changes and delay releases.

MCP also introduces new attack surfaces beyond those of traditional REST APIs. So we run security cases in the same eval pipeline on every change. 

Those cases cover:

• Prompt injection through document and field content

• Tool poisoning

• Overly broad tool exposure

• Manipulation of authentication or user information

When we catch an issue this early, the finding is a failed test rather than a production incident. That helps us avoid the incident response process, customer communications, and internal disruption. This automated testing doesn't replace a formal security review. It complements it, so we arrive at the review with fewer surprises.

Production readiness also requires governance

Shifting security testing left helps us catch issues before they reach customers, but production readiness doesn’t stop at what we test. 

Organizations also need control over how and when AI agents can act on their behalf. That’s why we’ve added an admin control for MCP access. Admins can enable or disable MCP access for their users at any time, and when access is turned off, it’s enforced at the Docusign MCP server itself, so it applies across every connected client, whether that’s Claude, ChatGPT, or another MCP-compatible tool. 

This governance gives our customers confidence in how they use it.

Production MCP needs both constraints and continuous testing

Two practices have been especially important for running our MCP server in production:

• Constrain the parts that must be predictable. Route ambiguous requests to the user and put critical paths behind MCP Apps.

• Continuously evaluate the parts that stay model-driven. Test tool selection, arguments, task completion, and security on every change.

The biggest lesson for us has been to make critical workflows predictable and continuously test the parts that depend on model behavior. 

Get started with the Docusign MCP Server

Ready to try it yourself? Here's how to connect an AI client to the Docusign MCP Server.

• Create a free Docusign developer account

• In Apps and Keys, create an Integration Key (IK) with a secret key and your client's redirect URIs.

• In your AI client, add a custom connector pointing to https://mcp-d.docusign.com/mcp.

• Sign in and try: “Which of my envelopes are waiting on a signer, and who’s holding them up?”