Skip to main content
Glama
rmindgh

addsign-mcp

by rmindgh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

addsign-mcp

MCP server for AddSign — lets AI agents send documents for signature, track signing status, remind signers, and download signed, hash-verifiable PDFs.

Stateless by design: it speaks only AddSign's public v1 API with your API key. No database access, no shared secrets. Revoking the key at addsign.io/settings/api kills the integration instantly.

Setup

  1. Create an API key at addsign.io → Settings → API Keys (free on every plan; Free includes 8 documents/month).

  2. Set it in the environment — never in prompts or config committed to git:

export ADDSIGN_API_KEY=sk_...

Claude Code

claude mcp add addsign --env ADDSIGN_API_KEY=sk_... -- npx -y addsign-mcp

(Until the npm package is published, point at a checkout instead: claude mcp add addsign --env ADDSIGN_API_KEY=sk_... -- node /path/to/simple-sign/mcp/dist/index.js)

Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "addsign": {
      "command": "node",
      "args": ["/path/to/simple-sign/mcp/dist/index.js"],
      "env": { "ADDSIGN_API_KEY": "sk_..." }
    }
  }
}

Environment

Variable

Required

Default

Purpose

ADDSIGN_API_KEY

yes

—

Your AddSign API key (sk_...)

ADDSIGN_BASE_URL

no

https://addsign.io

Point at a different deployment

Related MCP server: SignDocs Brasil MCP Server

Tools

Tool

Kind

What it does

list_templates

read

Templates + the signer roles each expects + field summary

send_for_signature

write

Create from template + email signers; idempotent via request_id

check_status

read

Document + per-signer state + recent audit events

download_signed

read

5-minute signed URL + the ledger's SHA-256 for verification

remind

write

Nudge pending signers (4h per-signer server-side cooldown)

list_documents

read

Paginated document list, filterable by status

No destructive tools: an agent cannot cancel or delete a legal document through this server.

A typical agent flow

list_templates                      → find "Contract to Lease", roles: [tenant_1, tenant_2]
send_for_signature {template_id,
  signers: [Artem…, Valeria…],
  request_id: <uuid>}               → document_id, status: pending, usage 3/8
check_status {document_id}          → Artem signed, Valeria viewed
remind {document_id, valeria@…}     → reminded (or skipped: reminded_recently)
download_signed {document_id}       → url + sha256 → fetch, verify, file it

Error semantics

Every AddSign error carries a stable error_code; this server appends the right next step for the agent. The two that matter most:

  • rate_limited (429) — back off retry_after seconds, retry.

  • plan_limit_reached (402) — never retry; the monthly cap resets on the 1st or the human upgrades.

Development

cd mcp
npm install
npm run build     # → dist/index.js
ADDSIGN_API_KEY=sk_... node dist/index.js

Available Tools

6 tools
check_statusCheck document statusA
Read-only
Inspect

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
NameRequiredDescriptionDefault
document_idYesDocument 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
Inspect

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
NameRequiredDescriptionDefault
artifactNoOnly 'signed_pdf' for now; the completion certificate is coming to the API later
document_idYesDocument 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
Inspect

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
NameRequiredDescriptionDefault
limitNo
offsetNo
statusNo'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
Inspect

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
NameRequiredDescriptionDefault

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 signersAInspect

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
NameRequiredDescriptionDefault
document_idYesDocument id
signer_emailNoRemind 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 signatureAInspect

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
NameRequiredDescriptionDefault
titleNoDocument title; defaults to the template name
dry_runNotrue = 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.
messageNoPersonal note included in the signature-request email
signersYesOne signer per template role — array position IS the role assignment
request_idNoIdempotency key — reuse the same value when retrying after a timeout
template_idYesTemplate id from list_templates
signing_order_typeNoparallel (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.

  1. 6 tool updatesv0.1.4
    • 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 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

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers