How do I use addsign-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@addsign-mcp Send template 'NDA' to jane@example.com for signature" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

addsign-mcp

by rmindgh

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

addsign-mcp

MCP server for AddSign — connect Claude (or any MCP client) to your AddSign account so your AI assistant can send documents for e-signature, track signing status, remind pending signers, and download signed PDFs with their audit-trail hashes.

Built and maintained by Gold Bird INC, the maker of AddSign.

Install

Every path needs an AddSign account (free plan included) — get connection instructions tailored to your client, with your API key filled in, at addsign.io/settings/api.

Claude Desktop (one-click, works on the free Claude plan): download the Desktop Extension (.mcpb) and double-click it (or drag it into Claude Desktop). You'll be prompted for your API key — it's stored in your system keychain, never in a file.

claude.ai / Claude Desktop via hosted connector (no key at all): Settings → Connectors → Add custom connector → https://addsign.io/api/mcp, then authorize with your AddSign login (OAuth). Paid Claude plans.

Claude Code:

claude mcp add addsign --env ADDSIGN_API_KEY=sk_your_key -- npx -y addsign-mcp

Any other MCP client (Cursor, VS Code, Windsurf, Gemini CLI, Codex CLI, …):

{
  "mcpServers": {
    "addsign": {
      "command": "npx",
      "args": ["-y", "addsign-mcp"],
      "env": { "ADDSIGN_API_KEY": "sk_your_key" }
    }
  }
}

Related MCP server: SignDocs Brasil MCP Server

Tools

Tool	What it does
`list_templates`	Your templates, their signer roles, and field summaries
`send_for_signature`	Create a document from a template and email it to signers (supports `dry_run` previews and idempotent retries)
`check_status`	Who viewed / signed / declined, with the audit trail
`remind`	Nudge signers who haven't signed (server-throttled)
`download_signed`	Short-lived URL for the signed PDF + its ledger SHA-256
`list_documents`	Your documents, filterable by status (including `declined`)

Security posture

The server holds no secrets beyond your own API key, read from the ADDSIGN_API_KEY environment variable only — never from prompts or tool arguments — and redacted from every error it surfaces. It speaks only AddSign's public v1 API; there is no database access.
No destructive tools. An agent can send, but can never cancel or delete documents, touch account or billing settings, or see API keys. Mis-sends are corrected by the human — every agent-initiated send emails the account owner with one-click View/Cancel.
Server-side guardrails on every agent send: recipient verification (deliverability, saved-contacts matching, typo detection), optional per-key contacts-only restriction, plan metering, and full audit-ledger attribution of every agent action.
Keys are created and revoked instantly at addsign.io/settings/api.

Development

npm install
npm run build        # compile TypeScript → dist/
npm run build:mcpb   # build the Claude Desktop Extension → addsign.mcpb

Requires Node.js ≥ 18. The .mcpb build bundles the server into a single file (no node_modules shipped) and packs it with @anthropic-ai/mcpb.

This repository is the public release mirror of the server that ships as addsign-mcp on npm and in the official MCP Registry (io.github.rmindgh/addsign-mcp). Issues and questions are welcome here; the AddSign product itself is not open source.

License

MIT © Gold Bird INC

Available Tools

6 tools

check_statusCheck document statusA

Read-only

Get the current state of a document: overall status, each signer (viewed / signed / declined, with timestamps and decline reasons), and the recent audit-trail events. This is the polling surface — call it when the human asks "did they sign?".

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	Document id from send_for_signature or list_documents

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description aligns by describing a read operation (get state). Adds behavioral context: it is a polling surface, returns signer timestamps and decline reasons, and provides audit-trail events—details beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each earning their place: first sentence defines return values, second provides usage context. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input (one required parameter) and no output schema, the description fully covers what the tool returns and when to use it. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description only mentions the parameter implicitly by referencing 'document_id' from siblings. No additional semantic detail beyond the schema's existing description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the verb 'get' and resource 'state of a document', naming detailed return fields (overall status, signer actions with timestamps, audit trail). It distinguishes this tool from siblings by calling it 'the polling surface', contrasting with other tools like remind or download_signed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call it: 'call it when the human asks "did they sign?"'. No explicit when-not-to-use, but the context clearly implies it's for checking status after sending, not for initiating actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

download_signedDownload the signed PDFA

Read-only

Get a short-lived (5 min) download URL for the signed PDF, plus the SHA-256 hash the audit ledger recorded at signing. Give the human the URL to download; the hash lets them (or any tool) verify the file is the evidentiary original. Only fetch the URL yourself if your environment permits network access to addsign.io — many sandboxes do not. Only works once the document status is signed.

ParametersJSON Schema

Name	Required	Description	Default
`artifact`	No	Only 'signed_pdf' for now; the completion certificate is coming to the API later
`document_id`	Yes	Document id

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description adds behavioural context: short-lived URL (5 min), SHA-256 hash from audit ledger, prerequisite of signed document, and network permission requirement. This goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with front-loaded purpose, then usage guidance. No redundant information; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains return values (URL and hash) adequately. Addresses environment constraints and prerequisites. Could explicitly mention URL format or instructions, but overall complete for a simple tool with strong annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with descriptions. The description adds minor context (future expansion for artifact), but baseline is 3 due to high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get a short-lived (5 min) download URL for the signed PDF, plus the SHA-256 hash'. It specifies the verb (get), resource (download URL and hash), and distinguishes from siblings like check_status and list_documents by its unique output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use and caution: 'Only works once the document status is signed' and 'Only fetch the URL yourself if your environment permits network access... many sandboxes do not'. It does not name alternative tools but provides clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_documentsList documentsA

Read-only

List the sender's documents, newest first, optionally filtered by status. Each row carries declined_by (name, email, reason) when a signer declined — such envelopes have status 'cancelled', but ALWAYS report them to the human as declined, with the reason. Paginate with limit/offset (limit max 100).

ParametersJSON Schema

Name	Required	Description
`limit`	No
`offset`	No
`status`	No	'declined' is a virtual filter: envelopes voided by a signer's decline (their stored status is 'cancelled')

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds significant behavioral detail beyond readOnlyHint annotation: explains the 'cancelled' vs 'declined' mapping and the required reporting behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three front-loaded sentences with no redundancy. Each sentence adds distinct value: purpose, behavioral nuance, and pagination guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main functionality: listing, filtering, pagination, and crucial status interpretation. Could mention return fields but is sufficient given no output schema and simple param list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning to limit/offset (pagination) and explains the status filter's virtual 'declined' mapping. Schema has 33% coverage; description compensates for the undocumented params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'List', resource 'sender's documents', and ordering 'newest first'. Differentiates from siblings like list_templates and other action-oriented tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context on filtering by status and pagination, and an important instruction on reporting cancelled status as declined. Could be more explicit about when to use this vs siblings, but the context signals help.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_templatesList templatesA

Read-only

List the sender's document templates. Each template carries the signer roles it expects (fill exactly these, in order, when calling send_for_signature) and a summary of its pre-placed fields — those fields are completed by the SIGNERS at signing time; they cannot be prefilled by the sender. Start here to find what can be sent.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds that templates carry signer roles and pre-placed fields completed by signers (not prefilled by sender), which is valuable behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the main action, and every sentence adds value without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and zero parameters, the description sufficiently explains the tool's purpose, the nature of templates, and where to start in the workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the description adds meaning by explaining what the list contains (signer roles and pre-placed fields), guiding the agent on what to expect from the output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List the sender's document templates.' with a specific verb and resource, effectively distinguishing it from sibling tools like send_for_signature and list_documents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Start here to find what can be sent.' implying it's the initial step before using send_for_signature. It provides context but doesn't explicitly state when not to use it or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remindRemind pending signersA

Send a reminder email to signers who have not signed yet (all of them, or one by email). Server-side throttling applies: a signer reminded in the last 4 hours is skipped, not re-emailed — the response lists who was reminded and who was skipped.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	Document id
`signer_email`	No	Remind only this signer; omit to remind all pending signers

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses server-side throttling behavior (4-hour skip) and response contents (who was reminded vs skipped), adding significant context beyond annotations which already indicate non-destructive and not fully open.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action and resource, no fluff. Every sentence adds essential detail (scope, throttling, response structure).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core behavior, throttling, and response listing. Missing edge cases like no pending signers or invalid document, but for a reminder tool, this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by explaining optional signer_email parameter usage (remind all vs one) and connects parameter behavior to throttling.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action (send a reminder email) and resource (signers who have not signed yet). It specifies the scope (all or one by email), distinguishing it from sibling tools like send_for_signature and check_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use (reminding pending signers) and mentions server-side throttling. However, it does not explicitly state when not to use (e.g., document fully signed) or directly reference sibling tool alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_for_signatureSend a document for signatureA

Create a document from a template and email it to signers for signature. IMPORTANT: sending exposes the document contents to every listed email — NEVER guess or infer a signer email address. Use exactly the emails the human gave you; if any is missing or ambiguous, ask the human before calling this tool, and restate the recipient list in your confirmation. ARRAY POSITION assigns template roles: the first signer gets the first role, and so on. The document sends as-is — its fields are filled by the signers at signing, not by you. Returns the document id — poll check_status with it. Pass a stable request_id when you might retry: a replayed request returns the original document instead of double-sending. A mis-sent envelope can be voided by the human from the AddSign dashboard (Cancel).

ParametersJSON Schema

Name	Required	Description
`title`	No	Document title; defaults to the template name
`dry_run`	No	true = validate everything (recipients, template roles, plan limits) and report exactly what WOULD be sent — without creating or emailing anything. Use it to show the human the outcome before the real send.
`message`	No	Personal note included in the signature-request email
`signers`	Yes	One signer per template role — array position IS the role assignment
`request_id`	No	Idempotency key — reuse the same value when retrying after a timeout
`template_id`	Yes	Template id from list_templates
`signing_order_type`	No	parallel (default): everyone signs at once; sequential: one at a time in order

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only provide openWorldHint=false and destructiveHint=false, but the description goes far beyond: warns about email exposure, requires exact email use, explains idempotency with request_id, role assignment via array position, and mentions cancellation via dashboard. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but concise, with no filler. It front-loads the core action, then adds warnings, parameter behavior, and return value in a logical flow. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters and no output schema, the description covers the action, parameter usage, return value (document id for polling), and error handling (dry_run, idempotency). It could mention error conditions more explicitly, but overall it is quite complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description adds crucial context: signers array position assigns template roles, dry_run validates without sending, request_id prevents double-sending, and signing_order_type options are explained. This exceeds the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb+resource: 'Create a document from a template and email it to signers for signature.' It distinguishes from sibling tools like check_status and download_signed by focusing on the sending action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use (sending for signature) and provides critical usage rules: never guess emails, ask if ambiguous, use dry_run for validation, and handle retries with request_id. It could explicitly contrast with siblings, but the context signals list them, and the description implies when not to use (e.g., for status or download).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.4Jul 11, 2026
- First observedcheck_status
- First observeddownload_signed
- First observedlist_documents
- First observedlist_templates
- First observedremind
- First observedsend_for_signature

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored 2026-07-11 17:20 across 6 tools

Disambiguation5/5

Each tool targets a distinct action: checking status, downloading signed documents, listing documents, listing templates, sending reminders, and sending for signature. No overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores, e.g., check_status, download_signed, list_documents. Even 'remind' is a verb alone but fits the pattern of single-action tools.

Tool Count5/5

With 6 tools, the set is well-scoped for a document signing server. It covers listing, sending, and managing documents without being overly sparse or bloated.

Completeness4/5

The tool set covers the core workflow: list templates, send for signature, check status, remind, and download. Minor gaps exist, such as no tool to create templates or void documents (must be done via dashboard), but these are acceptable for the focused scope.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

zsign AOAuth
io.zsign
E-signature API for AI agents: send contracts, sign PDF documents, track and download signed files.
Legal & Compliance Payments & Billing
162
blue·auth Document SigningOAuth
io.github.ricdanyalgil
Send AI-created PDFs for signature, track signers, and return verifiable document evidence.
Legal & Compliance Workplace & Productivity
1
DottedSignOAuth
io.github.DottedSign-Official
Automate eSignature workflows and signing tasks via natural language commands.
App Automation Legal & Compliance
2142
SignvoyOAuth
com.signvoy
Send documents for e-signature, track signing status, and download signed PDFs. No API key required.
Legal & Compliance Workplace & Productivity
1

Related MCP Servers

SignaTrust MCP Serverofficial
Legal & Compliance Blockchain
SignaTrustDev
A
license
A
quality
C
maintenance
Enables AI assistants to manage document signing workflows via natural language, including creating envelopes, uploading documents, analyzing contracts, and verifying blockchain anchors.
Updated 2 months ago (2026-07-17 23:35 UTC)
8
23 npm
1
MIT
SignDocs Brasil MCP Serverofficial
Legal & Compliance Workplace & Productivity
signdocsbrasil
A
license
A
quality
B
maintenance
Enables AI clients to create and manage e-signature sessions, envelopes, documents, and webhooks through the SignDocs Brasil API.
Updated 5 days ago (2026-09-11 02:51 UTC)
24
306 npm
MIT
SumoSign MCP Server
Legal & Compliance File Systems
meteordefect
A
license
A
quality
B
maintenance
Exposes the SumoSign signing API to AI agents, allowing document upload, envelope creation, and tracking, with signing always done by human recipients.
Updated a month ago (2026-08-16 15:29 UTC)
15
68 npm
MIT
EAD Enterprise Suite MCP
Legal & Compliance
g-digital-by-Garrigues
A
license
B
quality
A
maintenance
Enables AI agents to interact with EAD Enterprise Suite for managing signatures, evidence, notifications, and dossiers.
Updated 7 days ago (2026-09-08 17:16 UTC)
52
108 npm
MIT

addsign-mcp

Install

Tools

Security posture

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

SignaTrust MCP Serverofficial

SignDocs Brasil MCP Serverofficial