How to Give Your AI Agent the Power to Sign Documents

The missing piece in AI agent workflows

I've been building AI agent tooling for a while now, and one thing keeps coming up: agents can do everything except the last mile. An AI sales agent can research a prospect, draft a proposal, personalise pricing — but when it comes time to send that proposal for signature, it hits a wall. You need a human to copy-paste into DocuSign, click through a template builder, and manually trigger the send.

That wall exists because most e-signature platforms were built for humans clicking through GUIs. They don't expose simple, agent-friendly primitives. DocuSign has 400+ API endpoints and requires OAuth flows that no agent can handle autonomously. HelloSign requires template IDs that only exist after a human creates them in a dashboard.

The Model Context Protocol changes this. MCP gives agents a standardised way to discover and invoke external tools. And signbee-mcp is a tool that maps directly to Signbee's single-endpoint API — meaning an agent can send a document for signing with one function call.

What signbee-mcp actually does

When you install signbee-mcp into your MCP client, the agent gains access to three tools:

That's the entire surface area. Three tools. No template management, no envelope configuration, no OAuth dance. The agent writes markdown, sends it, and gets back a signing link. The markdown-to-PDF conversion happens server-side automatically.

Setting up Claude Desktop

Claude Desktop reads MCP server configurations from a JSON file. On macOS, it's at ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows, %APPDATA%\Claude\claude_desktop_config.json.

{
  "mcpServers": {
    "signbee": {
      "command": "npx",
      "args": ["-y", "signbee-mcp"],
      "env": {
        "SIGNBEE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Restart Claude Desktop after saving. You'll see a hammer icon in the input bar indicating MCP tools are available. That's it — Claude can now send documents.

Setting up Cursor

Cursor uses the same MCP configuration format. Open Settings → MCP Servers, or edit .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "signbee": {
      "command": "npx",
      "args": ["-y", "signbee-mcp"],
      "env": {
        "SIGNBEE_API_KEY": "your_api_key_here"
      }
    }
  }
}

The advantage of project-level config: every developer on the team gets document signing capabilities without individual setup. Commit this file (without the real API key — use environment variable references in CI) and signing becomes a shared team tool.

Setting up Windsurf

Windsurf (formerly Codeium) also supports MCP servers. Add the configuration to your Windsurf MCP settings:

{
  "mcpServers": {
    "signbee": {
      "command": "npx",
      "args": ["-y", "signbee-mcp"],
      "env": {
        "SIGNBEE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Real prompts that trigger document signing

Once configured, you interact with document signing through natural language. Here are prompts I actually use in production:

The key insight: the agent decides the document content. You don't need pre-built templates. The LLM generates contextually appropriate markdown based on your prompt, and Signbee converts it to a professional PDF with signature fields. This is fundamentally different from template-based signing where you fill in merge fields on a pre-designed document.

What happens under the hood

When your agent calls send_document, signbee-mcp makes a single API call to Signbee's endpoint:

const response = await fetch("https://signb.ee/api/v1/send", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer YOUR_API_KEY",
  },
  body: JSON.stringify({
    markdown: "# Non-Disclosure Agreement\n\nThis NDA is entered into...",
    recipient_name: "Jane Smith",
    recipient_email: "jane@acme.com",
    sender_name: "Michael Beckett",
  }),
});

const { document_id, signing_url } = await response.json();

That's the entire integration. One endpoint. One POST. The API docs cover every parameter, but the core is just markdown in, signing link out. Compare this to DocuSign's MCP integration — if one existed — which would need to handle OAuth token refresh, envelope creation, recipient routing, template selection, and tab placement across multiple API calls.

Why MCP matters more than SDKs

SDKs are for developers writing code. MCP is for agents acting autonomously. The distinction matters because the consumer of the tool has fundamentally different capabilities:

For a deeper look at how signing fits into multi-agent architectures, see our piece on AI agents and document signing and the comparison of e-signature MCP servers.

Security considerations

Giving an AI agent the ability to send legally binding documents raises obvious questions. Here's how I think about it:

API key scope. Your Signbee API key controls what the agent can do. It can only send documents to recipients — it cannot sign on behalf of anyone. The signer always makes a deliberate, authenticated choice to sign. The agent just delivers the document.

Audit trail. Every document sent via MCP gets the same SHA-256 audit trail as documents sent via the REST API. You can see exactly when the agent triggered the send, when the recipient opened it, and when they signed.

Human-in-the-loop. Most MCP clients (Claude Desktop, Cursor) ask for user confirmation before executing tool calls. So the agent proposes "I'll send this NDA to jane@acme.com" and you approve or reject before it actually fires. You maintain control.

Frequently Asked Questions

Last updated: May 18, 2026 · Michael Beckett is the founder of Signbee and B2bee Ltd.