mcp-signwell

Name: mcp-signwell
Author: Bidsketch

Official

by Bidsketch

Overview Schema Related Servers Score Discussions

TypeScript

Remote

SignWell MCP Server

Model Context Protocol server that orchestrates SignWell's e-signature workflows.

Prerequisites

Node.js v18 or newer.
A SignWell API key with document access (SIGNWELL_API_KEY environment variable).
Optional overrides:
- SIGNWELL_API_BASE_URL for non-production endpoints.
- SIGNWELL_API_TIMEOUT_MS to tweak HTTP client timeouts (default 90000 ms; CLI flag --timeout on setup skips env prompts and writes this override).

Related MCP server: MCP Google Suite

Setup

Interactive Wizard (recommended)

Install dependencies if you have not already:
```
npm install
```
Bundle the CLI so MCP clients point at the build output:
```
npm run build
```
Run the wizard and follow the prompts:
```
node build/index.js setup
```
- Stores your SignWell secrets in ~/.config/signwell-mcp/env on Linux, ~/Library/Application Support/SignWell/MCP/env on macOS, or %APPDATA%/SignWell/MCP/env on Windows with 0700/0600 permissions.
- Automatically updates Claude Desktop, Claude Code, Cursor, and OpenCode configuration files (backups are captured before each write) so you do not have to hunt for platform paths.
- Client targets:
  - Claude Code: ~/.claude.json at mcpServers.signwell
  - Claude Desktop: claude_desktop_config.json at mcpServers.signwell
  - Cursor: ~/.cursor/mcp.json at mcpServers.signwell
  - OpenCode: ~/.config/opencode/opencode.json at mcp.signwell (Windows: %USERPROFILE%\.config\opencode\opencode.json)
- Uses each client's documented JSON wrapper and STDIO/local server shape so the server is visible after the client restarts.
- If a previous Claude Code install wrote the stale ~/.claude/mcp.json servers.signwell entry, rerunning setup backs up that legacy file and removes only the stale SignWell entry after writing the correct ~/.claude.json config.
- Use --print (or -p) to preview outputs without writing to disk, and --yes --api-key=... for non-interactive runs (CI, devcontainers, etc.).
- Pass --clients=claude-desktop,cursor to limit which MCP clients the wizard configures; omit for "all". Use --timeout=<ms> only if you need a non-default HTTP timeout.
- After bundling (npm run build) and publishing the package, end users can invoke the same wizard with npx @signwell/mcp setup. Installing globally also enables invoking signwell-mcp setup directly.

Manual exports

Prefer to manage env vars yourself? Export the required values before running the server:

export SIGNWELL_API_KEY="your_api_key"
# export SIGNWELL_API_BASE_URL="https://www.signwell.com/api/v1"   # optional

Installation (npm)

Once the package is published to npm (GitHub: Bidsketch/signwell-mcp):

Run the setup wizard without installing anything globally:
```
npx @signwell/mcp setup
```
Install globally if you prefer a persistent binary:
```
npm install -g @signwell/mcp
signwell-mcp setup
```

After configuration, start the MCP server via signwell-mcp (requires Node.js v18+).

The signwell-mcp.mcpb file is a separate Claude Desktop extension artifact. It uses the root manifest.json and should be rebuilt for releases after running npm run build.

Local Development Workflow

Install dependencies: npm install
Bundle the CLI entrypoint (required for MCP client configs): npm run build
Configure credentials: node build/index.js setup (or npx @signwell/mcp setup once published)
Start the MCP server locally: npm start (runs node build/index.js)
Open another terminal to run tests and linters before committing:
```
npm test
npm run typecheck
npm run lint
```
When using MCP inspector or other clients, point them at npm start (stdio).

Running the Server

Development entrypoint (stdio transport):

SIGNWELL_API_KEY="$SIGNWELL_API_KEY" npm start
# or run directly:
SIGNWELL_API_KEY="$SIGNWELL_API_KEY" node build/index.js

CLI helpers:
- node build/index.js --help prints usage and env expectations.
- node build/index.js --version prints the current build.
- node build/index.js setup launches the setup wizard described above when working from source.
- Once the package is bundled/published, npx @signwell/mcp setup runs the wizard and SIGNWELL_API_KEY=... npx @signwell/mcp starts the server via the packaged binary (global installs can call signwell-mcp ... directly).

MCP Inspector

Use the MCP inspector to exercise tools locally:

npx @modelcontextprotocol/inspector node build/index.js

Tests

Run the quality gates in order:

npm test
npm run typecheck
npm run lint
npm run format

Demo

Sample MCP inspector session (sanitized IDs):

Create Draft

Tool: document_create
Input: {
  "name": "Sales Agreement",
  "recipients": [{ "email": "alice@example.com" }],
  "files": [{ "name": "agreement.pdf", "file_url": "https://files.example.com/agreement.pdf" }]
}
Output:
{
  "ok": true,
  "type": "document_create",
  "message": "Document draft created.",
  "data": {
    "id": "doc_123",
    "status": "draft"
  }
}

Send Draft

Tool: document_send_draft
Input: { "document_id": "doc_123", "confirm_send": true }
Output:
{
  "ok": true,
  "type": "document_send_draft",
  "message": "Draft sent for signing.",
  "data": { "id": "doc_123", "status": "sent" }
}

Check Status

Tool: document_get
Input: { "document_id": "doc_123" }
Output:
{
  "ok": true,
  "type": "document_get",
  "message": "Fetched document status.",
  "data": {
    "id": "doc_123",
    "status": "completed",
    "recipients": [{ "email": "alice@example.com", "status": "signed" }]
  }
}

Completed PDF

Tool: document_completed_pdf
Input: { "document_id": "doc_123" }
Output:
{
  "ok": true,
  "type": "document_completed_pdf",
  "data": {
    "pdf_url": "https://signwell-downloads.example.com/doc_123.pdf"
  }
}

Privacy Policy

This section describes the data practices of the SignWell MCP Server.

Data Collection

The MCP server itself does not collect, transmit, or store any personal data or usage analytics.
Your SignWell API key is stored locally on your machine with restrictive file permissions (0600) in platform-specific secure locations:
- macOS: ~/Library/Application Support/SignWell/MCP/env
- Linux: ~/.config/signwell-mcp/env
- Windows: %APPDATA%/SignWell/MCP/env

Usage & Storage

Files provided via file_store are held temporarily in memory with a 60-minute TTL and are cleared automatically.
All in-memory file data is also cleared on server restart.
No persistent data storage exists beyond the credential file created during setup.

The MCP server does not share data with any third parties.
All API communication goes directly between your machine and SignWell's servers (https://www.signwell.com/api/v1).

Telemetry & Analytics

The server does not collect, transmit, or store usage analytics or telemetry of any kind.

Data Retention

In-memory file storage is cleared on server restart or after the 60-minute TTL expires.
No persistent data is retained beyond the local credential configuration file.

Contact

For privacy inquiries, contact support@signwell.com or open an issue at github.com/Bidsketch/signwell-mcp/issues.

See also the hosted privacy policy at https://www.signwell.com/privacy/.

Resources

MCP resources: document://{id} and template://{id} expose read-only JSON snapshots that reuse the same normalization logic as the tools, so inspectors or other MCP clients can browse previously created assets quickly.

Attaching Files & Draft Safety

document_create and template_create_document always set draft: true, ensuring nothing is emailed until you intentionally call document_send_draft.
Supply files via the files array using either file_url (public URL or the link your MCP client provides when you @-attach a file in UIs like Claude Desktop), file_base64, or resource_uri. When a resource_uri is provided the MCP server automatically calls resources/read to pull the attachment bytes and forwards them to SignWell's /api/v1/documents/ endpoint.

Available Scripts

Script	Purpose
`npm start`	Execute the MCP server entrypoint over stdio (after `npm run build`).
`npm test`	Run the test suite.
`npm run typecheck`	Type-check the project with `tsc --noEmit`.
`npm run lint`	Lint source and tests using Biome.
`npm run format`	Apply repository formatting conventions via Biome.
`npm run build`	Produce an ESM bundle at `build/index.js` using esbuild.

Directory Layout

.
├── src/                # MCP server source (entrypoint + domain modules)
│   └── setup/          # Interactive setup wizard for MCP client configuration
├── test/               # Test suites
├── build/              # Bundled output (ignored in releases)
├── biome.json          # Biome lint/format configuration
└── tsconfig.json       # TypeScript compiler configuration

Available Tools

14 tools

document_completed_pdfC

Fetch the completed PDF. Use mode: 'base64' to get content for displaying in an artifact or chat (embed as data:application/pdf;base64,{pdf_base64}). Default 'url' mode returns a shareable link.

ParametersJSON Schema

Name	Required	Default
`mode`	No	url
`document_id`	Yes
`file_format`	No	pdf
`save_to_path`	No
`include_audit_page`	No

TDQS

C2.8/5.0

Behavior1/5

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

Annotations indicate readOnlyHint=false (may modify state) and destructiveHint=false. The description uses 'Fetch', implying a read-only operation, contradicting the annotation. No additional behavioral traits are disclosed.

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 concise sentences: one states the purpose, the other explains usage. No extraneous content. Suitable for quick comprehension.

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

Completeness2/5

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

Despite having 5 parameters and no output schema, the description only covers mode. It omits critical details like document_id requirement, file_format options, save_to_path, include_audit_page, and return value format.

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

Parameters2/5

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

With 0% schema description coverage, the description only explains the 'mode' parameter. Other parameters (document_id, file_format, save_to_path, include_audit_page) are not mentioned, leaving the agent uninformed about their purpose.

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

Purpose4/5

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

The description clearly states 'Fetch the completed PDF', identifying the verb and resource. It distinguishes this tool from siblings like document_get by specifying that it retrieves the completed PDF, but it does not explicitly differentiate from document_get or other PDF-related tools.

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

Usage Guidelines3/5

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

The description provides usage guidance for modes: base64 for displaying in artifact/chat and url for shareable link. However, it does not offer context on when to avoid using this tool or mention alternatives.

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

document_createA

Create a SignWell document (always created as a draft).

CRITICAL RULES:

Do NOT read, parse, extract, or verify file contents before uploading. The user already knows what is in the file.
Do NOT convert files between formats (e.g. do NOT convert .docx to .pdf). SignWell handles conversion automatically.
The user will place signature fields in the SignWell editor. Just upload the file and return the editor link.

SUPPORTED FILE TYPES: .pdf, .doc, .docx, .pages, .ppt, .pptx, .key, .xls, .xlsx, .numbers, .jpg, .jpeg, .png, .tiff, .tif, .webp, .html, .htm

WORKFLOW FOR USER'S EXISTING FILES:

file_store (call with NO arguments to open native file picker) → returns file_token
document_create (pass file_token in files array) → creates draft, returns editor_url

WORKFLOW FOR CLAUDE-GENERATED FILES:

document_create with content_text directly (RECOMMENDED) → MCP server converts to DOCX automatically Pass plain text or Markdown as content_text. The server generates a DOCX file without base64 overhead.
document_create with file_base64 directly (skip file_store) → creates draft, returns editor_url Do NOT write the file to disk and pass a file_path — sandbox paths are inaccessible. Use file_base64.
Example using content_text: { "name": "Service Agreement", "recipients": [{"id": "1", "email": "client@example.com"}], "files": [{"name": "agreement.docx", "content_text": "# Service Agreement\n\nThis agreement between..."}] }

FILE ACCESS: Chat attachments and sandbox paths (/home/claude, /mnt/user-data) are inaccessible to the MCP server. Do NOT use resource_uri or sandbox file_path values. For existing files, call file_store with no arguments to open the native file picker.

REQUIRED PARAMETERS:

name: Document name
recipients: Array with at least one object containing "id" and "email"
files: Array with at least one file object containing:
- "name": Filename (e.g., "contract.docx")
- One content source (in order of preference):
  - "content_text": Plain text or Markdown to auto-convert to DOCX (RECOMMENDED for Claude-generated content)
  - "file_token": Token from file_store (recommended for user files)
  - "file_url": Public URL to the file
  - "file_base64": Base64-encoded file content
  - "resource_uri": MCP resource URI

EXAMPLE (docx via file_token — most common): { "name": "NDA Agreement", "recipients": [{"id": "1", "email": "signer@example.com"}], "files": [{"name": "nda.docx", "file_token": ""}] }

EXAMPLE (pdf with text tags): { "name": "Contract", "text_tags": true, "recipients": [{"id": "1", "email": "signer@example.com"}], "files": [{"name": "contract.pdf", "file_token": ""}] }

TEXT TAGS (optional): Set text_tags: true only if the document already contains signature placeholders like {{signature:1:y}}. The recipient "id" MUST match the number in text tags (id:"1" matches {{signature:1:y}}).

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`files`	Yes
`message`	No	Email message recipients will see.
`subject`	No	Email subject line recipients will see.
`metadata`	No	Key-value metadata (max 50 pairs, key max 40 chars, value max 500 chars).
`reminders`	No	Send signing reminders on day 3, 6, and 10.
`text_tags`	No
`expires_in`	No	Days before the signature request expires (max 365).
`recipients`	Yes
`redirect_url`	No	URL to redirect after successful signing.
`allow_decline`	No	Allow recipients to decline signing.
`allow_reassign`	No	Allow recipients to reassign to someone else.
`copied_contacts`	No	CC recipients who receive the final signed document by email.
`embedded_signing`	No	Enable embedded signing.
`apply_signing_order`	No	When true, recipients sign one at a time in the order of the recipients array.
`decline_redirect_url`	No	URL to redirect if document is declined.
`custom_requester_name`	No	Custom requester name on communications.
`custom_requester_email`	No	Custom requester email on communications.
`embedded_signing_notifications`	No	Send completion notifications when using embedded signing.

TDQS

A4.9/5.0

Behavior5/5

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

Discloses beyond annotations: documents always created as draft, supported file types, auto-conversion of content_text, sandbox inaccessibility, file_store native picker, and text_tags behavior. No annotation contradiction.

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

Conciseness4/5

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

Well-structured with sections, front-loaded with purpose, but somewhat verbose. Could tighten some repeated warnings, but overall efficient and easy to scan.

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?

Covers essential behavior, parameter options, workflows, and common pitfalls (sandbox accessibility, file_store usage). Adequately complete for an agent to use effectively with no output schema.

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?

Adds significant meaning beyond schema: order of preference for content sources, examples, explanation of text_tags recipient ID mapping, and details on reminders and embedded signing. Compensates for any missing schema 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 clearly states 'Create a SignWell document (always created as a draft)' and provides specific verb+resource. It distinguishes from siblings like document_send_draft and file_store.

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

Usage Guidelines5/5

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

Includes explicit CRITICAL RULES, workflows for user files vs Claude-generated files, and guidance on when to use file_store vs content_text vs file_base64. States when not to use certain methods.

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

document_getB

Read-only

Fetch the latest status for a SignWell document.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description is consistent. However, it adds no extra behavioral context such as authentication needs or response format.

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 a single, clear sentence with no unnecessary words or repetition.

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

Completeness2/5

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

With no output schema, the description fails to explain what the response contains (e.g., fields of the status) or how the status is defined, making it incomplete for a simple tool.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain the 'document_id' parameter or any other parameter semantics, leaving the agent without sufficient information.

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 uses a specific verb ('Fetch') and resource ('status for a SignWell document'), clearly distinguishing it from sibling tools like 'document_create' or 'document_list'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its siblings, nor does it mention any prerequisites or exclusions.

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

document_listB

Read-only

List SignWell documents with optional filtering (status, archived, search).

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`search`	No
`status`	No
`archived`	No
`per_page`	No
`updated_after`	No
`updated_before`	No

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true. The description adds that the tool lists documents with filters, but does not disclose pagination behavior, rate limits, or empty results handling. It does not contradict annotations.

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

Conciseness4/5

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

The description is a single concise sentence with no wasted words. However, it could be front-loaded with more structured details like output format.

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

Completeness2/5

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

Given 7 parameters, no output schema, and 14 siblings, the description is too minimal. It lacks pagination details, date filter explanation, and output expectations, making it incomplete for an agent to use effectively.

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

Parameters2/5

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

With 0% schema description coverage, the description should compensate. It only clarifies three parameters (status, archived, search) out of seven, omitting page, per_page, and date filters. This provides partial meaning but is insufficient.

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

Purpose4/5

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

The description clearly states 'List SignWell documents' with optional filtering, indicating the verb and resource. While it differentiates from single-document tools like document_get, it does not explicitly contrast with sibling tools.

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

Usage Guidelines3/5

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

The description mentions optional filtering, implying use cases for filtered lists, but provides no explicit guidance on when to use this tool versus alternatives like document_get, search, etc.

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

document_send_draftC

Send a previously created draft document (requires confirm_send).

ParametersJSON Schema

Name	Required	Description	Default
`message`	No
`document_id`	Yes
`confirm_send`	No

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the behavioral trait 'requires confirm_send', but fails to disclose side effects, irreversibility, or what happens to the draft after sending.

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

Conciseness3/5

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

The description is very short (one sentence) and to the point, but lacks detail. It earns no waste, but also fails to provide sufficient information for a safe and correct invocation.

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

Completeness2/5

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

No output schema and low schema coverage. The description does not explain return values, error conditions, or state transitions (e.g., draft becomes sent). Incomplete for a mutation tool with 3 parameters.

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

Parameters2/5

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

Schema description coverage is 0%. The description only mentions document_id and confirm_send implicitly, leaving the 'message' parameter completely unexplained. Little value added beyond the schema's property names.

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

Purpose4/5

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

The description clearly states the action ('send') and resource ('previously created draft document'), differentiating it from sibling tools like document_send_reminder which deals with reminders. However, it does not explicitly contrast with alternatives.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., document_send_reminder). The requirement for confirm_send is stated but lacks context on prerequisites or typical scenarios.

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

document_send_reminderB

Send a reminder email for a document (optionally to a specific recipient).

ParametersJSON Schema

Name	Required	Description	Default
`message`	No
`document_id`	Yes
`recipient_email`	No

TDQS

B3/5.0

Behavior3/5

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

Annotations already indicate the tool is not read-only nor destructive. The description adds that it sends an email, which is a non-trivial side effect, but does not disclose details like whether duplicate reminders are allowed or frequency limits.

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 a single sentence with no redundant information. It is front-loaded and efficiently communicates the tool's core function.

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

Completeness2/5

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

Given no output schema and minimal annotations, the description lacks details on return values, potential errors, prerequisites, or behavioral nuances like idempotency. It is insufficient for an agent to fully understand the tool's impact.

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

Parameters2/5

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

Schema coverage is 0%, so the description must explain parameters. It mentions recipient_email as optional but does not explain 'message' or that document_id is required. The description adds minimal value beyond parameter names.

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

Purpose4/5

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

The description clearly states the tool sends a reminder email for a document, with an optional specific recipient. It uses a specific verb-resource combination and distinguishes from sibling tools like document_send_draft by specifying 'reminder'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as whether the document must be signed or active, or when to prefer document_send_draft over this.

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

file_storeA

Store a user's existing file for upcoming SignWell requests. Returns a file_token you can pass to document/template tools.

IMPORTANT: This tool is for the USER'S EXISTING FILES only. Do NOT read, parse, or convert the file — upload it as-is.

HOW TO PROVIDE THE FILE (in order of preference):

No arguments — Opens a native OS file picker dialog. USE THIS BY DEFAULT. Simply call file_store with no arguments and the user will select the file themselves.
file_path — Only if the user explicitly provides a local path on their computer (e.g. ~/Documents/contract.docx).
file_url — A publicly accessible URL to the file.

CHAT ATTACHMENTS: When a user uploads/attaches a file in the chat, DO NOT use resource_uri — those are sandboxed and inaccessible. Instead, call file_store with NO arguments to open the native file picker.

CLAUDE-GENERATED FILES: If YOU created the file content (e.g. generated a PDF), do NOT use file_store. Pass file_base64 directly to document_create instead.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`file_url`	No
`file_path`	No
`resource_uri`	No

TDQS

A4.9/5.0

Behavior5/5

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

Discloses that the tool does not read/parse/convert the file, opens a native OS file picker when called with no arguments, and returns a file_token. 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.

Conciseness4/5

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

Well-structured with sections, bold headers, and bullet points. Slightly verbose but all content is valuable; could tighten a bit without losing clarity.

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?

Covers all aspects: purpose, argument usage, behavioral notes, edge cases (chat attachments, generated files), and integration with other tools. Comprehensive given no output schema.

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?

Despite 0% schema coverage, the description explains each parameter's purpose and usage in detail, including when to use file_url vs file_path vs no arguments, and warns against resource_uri.

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 'Store a user's existing file for upcoming SignWell requests' with a specific verb and resource. Distinguishes from siblings by noting it returns a file_token for document/template tools.

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

Usage Guidelines5/5

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

Provides explicit guidance on argument preference order, warns against using resource_uri for chat attachments, and instructs to pass file_base64 directly to document_create for Claude-generated files.

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

file_validate_text_tagsA

Read-only

Validate text tags in a PDF before creating a template or document.

RECOMMENDED WORKFLOW: file_store → file_validate_text_tags → template_create/document_create

Accepts a PDF via file_token (from file_store), file_base64, file_url, or resource_uri. Set use_picker: true to open a native file picker when no file input is provided. Extracts text from the PDF and checks for valid SignWell text tags like {{signature:1:y}}.

Returns:

Whether text is extractable from the PDF
List of valid tags found
List of malformed tags (if any)
Signer numbers referenced
Recommendations for fixing issues

ParametersJSON Schema

Name	Required	Description
`file_url`	No	Public URL to download the PDF.
`file_token`	No	Token from file_store.
`use_picker`	No	Set to true to prompt for a local file when no other option is provided.
`file_base64`	No	Base64-encoded PDF content.
`resource_uri`	No	MCP resource URI for the file.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description aligns perfectly by stating 'Validate' (no mutation) and listing detailed return values (extractability, valid tags, malformed tags, etc.). It adds context on what happens to the PDF (extract text, check tags) without contradicting 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?

The description is concise yet comprehensive. It is front-loaded with the main purpose, followed by a recommended workflow, input methods, and output details. Every sentence adds value, and the structure enables quick scanning.

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?

Despite no output schema, the description lists all return items (extractability, valid/malformed tags, signer numbers, recommendations), making the tool's behavior fully predictable. Input options are fully covered. The workflow context and sibling tools complete the situational understanding.

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% with parameter descriptions, but the description adds semantic context: it explains that the tool accepts multiple input methods (file_token, file_base64, file_url, resource_uri) and clarifies the role of use_picker as a fallback to native file picker. This goes beyond the schema by grouping parameters by purpose.

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 the action ('Validate text tags in a PDF') and the resource/noun ('text tags in a PDF'), with immediate context ('before creating a template or document'). It distinguishes from sibling tools by specifying validation as a preparatory step, not a creation or retrieval operation.

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 provides a recommended workflow ('file_store → file_validate_text_tags → template_create/document_create'), clearly indicating when to use the tool. However, it does not explicitly state when not to use it or name specific alternatives beyond the workflow sequence.

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

template_createA

Create a SignWell template for reusable signature documents.

RECOMMENDED WORKFLOW:

file_store (provide file_path, file_url, or resource_uri) → returns file_token
file_validate_text_tags (pass file_token) → validates tags are extractable
template_create (pass file_token in files array) → creates the template

REQUIRED PARAMETERS (both are mandatory):

files: Array with at least one file object containing:
- "name": Filename (e.g., "template.docx")
- One content source (in order of preference):
  - "content_text": Plain text/Markdown to auto-convert to DOCX (RECOMMENDED for generated content)
  - "file_token": Token from file_store (recommended for uploaded files)
  - "file_base64": Base64-encoded file content
  - "file_url": Public URL to the file
  - "resource_uri": MCP resource URI
placeholders: Array with at least one placeholder object containing "id" and "name"

STEP-BY-STEP EXAMPLE (using file_token):

Call file_store with {"file_path": "/path/to/doc.pdf"} → get file_token
Call file_validate_text_tags with {"file_token": "..."} → confirm tags are valid
Call this tool with: { "name": "My Template", "files": [{"name": "doc.pdf", "file_token": ""}], "placeholders": [{"id": "1", "name": "Signer"}], "text_tags": true }

ALTERNATIVE (inline base64): { "name": "My Template", "files": [{"name": "doc.pdf", "file_base64": "JVBERi0xLjQK..."}], "placeholders": [{"id": "1", "name": "Signer"}], "text_tags": true }

TEXT TAGS (when text_tags: true): Your PDF must contain these literal text strings as SELECTABLE TEXT (not images):

{{signature:1:y}} - Signature field for placeholder id "1"
{{date:1:y}} - Date field for placeholder id "1"
{{text:1:y:Label}} - Text field with label
{{initial:1:y}} - Initials field

The number in the tag (1, 2, etc.) MUST match a placeholder "id" in your request.

CRITICAL: Text tags must be SELECTABLE/SEARCHABLE text in the PDF, not rendered as images or graphics. When generating PDFs programmatically, use text drawing methods (e.g., drawString) with standard fonts. To verify: open the PDF and try to select/copy the tag text with your mouse. If you can't select it, SignWell can't parse it.

MULTI-SIGNER EXAMPLE: { "name": "Contract", "files": [{"name": "contract.pdf", "file_base64": "JVBERi0xLjQK...actual base64 here..."}], "placeholders": [ {"id": "1", "name": "Client"}, {"id": "2", "name": "Vendor"} ], "text_tags": true }

For this example, the PDF should contain: {{signature:1:y}} for Client and {{signature:2:y}} for Vendor.

COMMON ERRORS:

Empty arguments {} = You forgot to include files and placeholders arrays
"fields": [] in response = PDF doesn't contain valid text tags, or text_tags wasn't set to true

ParametersJSON Schema

Name	Required	Description
`name`	No	Template name (e.g., 'Permission Slip').
`draft`	No	If true, template stays editable. If false, marked Available. Default: false per API.
`files`	No	REQUIRED. Files to upload. Each needs 'name' plus one of: 'file_url', 'file_base64', or 'resource_uri'.
`fields`	No	2D array of fields: one array per file. Required if draft is false.
`labels`	No	Labels for organizing templates.
`message`	No	Email message for signature requests (max 4000 chars).
`subject`	No	Email subject for signature requests.
`language`	No	Language for template (ISO 639-1).
`metadata`	No	Key-value metadata (max 50 pairs, key max 40 chars, value max 500 chars).
`reminders`	No	Send signing reminders on day 3, 6, and 10.
`text_tags`	No	Set TRUE if PDF contains text tags like {{signature:1:y}}. Placeholder 'id' values must match the signer numbers in tags (e.g., id='1' for {{signature:1:y}}).
`expires_in`	No	Days before signature request expires (max 365).
`placeholders`	No	REQUIRED. Signing roles. Each needs 'id' and 'name'. For text tags, the 'id' must match tag IDs (e.g., id='signer1' matches [sig\|req\|signer1]).
`redirect_url`	No	URL to redirect after successful signing.
`allow_decline`	No	Allow recipients to decline signing.
`allow_reassign`	No	Allow recipients to reassign to someone else.
`checkbox_groups`	No	Grouped checkbox fields with validation.
`api_application_id`	No	API Application ID for settings isolation.
`apply_signing_order`	No	Recipients sign in order.
`attachment_requests`	No	Attachments recipients must upload.
`copied_placeholders`	No	Recipients who receive the final document after completion.
`decline_redirect_url`	No	URL to redirect if document is declined.

TDQS

A4.5/5.0

Behavior5/5

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

Annotations indicate a non-destructive write operation. The description adds substantial behavioral context: text tag requirements, multi-signer examples, common errors, and critical notes about selectable text. This goes well beyond the annotation hints.

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

Conciseness3/5

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

The description is very long and includes multiple examples that could be condensed. While the structure (sections like RECOMMENDED WORKFLOW) is good, the verbosity exceeds what is necessary for a concise tool description.

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 complex tool with 22 parameters and no output schema, the description covers workflow, parameter usage, error handling, and edge cases (e.g., text tags vs manual fields). It is highly complete for the agent to use effectively.

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 100% schema description coverage, baseline is 3. The description adds meaning beyond the schema by explaining parameter relationships (e.g., text_tags and placeholder id mapping), providing example calls, and clarifying content source preferences.

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 'Create a SignWell template for reusable signature documents,' a clear verb+resource statement. It distinguishes from sibling tools like template_create_document by focusing on template creation.

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 provides a detailed recommended workflow (file_store → file_validate_text_tags → template_create) and step-by-step examples. However, it does not explicitly state when not to use this tool or list alternatives.

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

template_create_documentA

Create and send a document from a template. Templates are pre-configured and ready to send, so this tool sends the document for signing by default.

IMPORTANT: When a user asks to "send a template" or "send a document from a template", the document will be sent immediately for signing. Set draft: true ONLY if the user explicitly asks to create a draft or review before sending.

REQUIRED:

template_id: The template ID to create the document from
recipients: Array of recipient objects, each with:
- id: Unique identifier for this recipient (e.g., "recipient_1")
- placeholder_name: Name of the template placeholder to assign (must match exactly)
- email: Recipient's email address
- name: (optional) Recipient's display name

Example: { "template_id": "abc123", "recipients": [{ "id": "recipient_1", "placeholder_name": "Client", "email": "client@example.com", "name": "John Doe" }] }

ParametersJSON Schema

Name	Required	Description
`name`	No	Document name override.
`draft`	No
`files`	No	Additional files to append.
`message`	No
`subject`	No
`metadata`	No
`text_tags`	No
`expires_in`	No
`recipients`	Yes
`template_id`	Yes
`redirect_url`	No
`copied_contacts`	No
`embedded_signing`	No
`apply_signing_order`	No	When true, recipients sign one at a time in the order of the recipients array.
`decline_redirect_url`	No
`custom_requester_name`	No
`custom_requester_email`	No
`embedded_signing_notifications`	No

TDQS

A4.2/5.0

Behavior4/5

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

The description discloses that the tool sends the document for signing by default, which is a key behavioral trait. It also explains the draft flag behavior. Annotations show readOnlyHint=false and destructiveHint=false, and the description does not contradict these. It adds value beyond annotations by detailing the default send action.

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

Conciseness4/5

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

The description is well-structured with sections, bold emphasis, bullet list for required fields, and a JSON example. It is front-loaded with the main purpose and contains no fluff, though it could be slightly more compact by removing redundant phrasing.

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

Completeness3/5

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

Given the tool has 18 parameters (2 required), nested objects, and no output schema, the description provides a good overview for the primary use case but lacks details on many optional parameters. An agent might need additional context for full usage, but the example and required field descriptions help.

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 description coverage is low (17%), and the description compensates by explaining the required parameters (template_id, recipients) with a detailed example and structure for recipients. However, it does not cover many optional parameters like name, message, subject, etc., leaving gaps for an agent.

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 'Create and send a document from a template' and distinguishes this from creating non-template documents or templates themselves. The IMPORTANT note clarifies the default sending behavior vs. draft, which helps differentiate it from sibling tools like document_create or document_send_draft.

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

Usage Guidelines5/5

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

Explicitly provides when to use this tool (when user asks to send a template) and when to use draft: true (only if user explicitly asks for a draft or review before sending). This gives clear guidance and prevents misuse.

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

template_deleteC

Destructive

Delete a SignWell template.

ParametersJSON Schema

Name	Required	Description	Default
`template_id`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

The description merely repeats 'Delete', which is essentially a tautology. The destructiveHint annotation already signals the tool's destructive nature, and the description adds no extra behavioral information such as irreversibility, required permissions, or side effects.

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

Conciseness3/5

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

The description is extremely concise (one sentence), but this conciseness comes at the cost of missing critical information. It could easily include a brief note on the parameter without losing efficiency.

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

Completeness2/5

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

Given the tool's simplicity (one parameter, no output schema), the description is incomplete. It omits the purpose of the required parameter and any mention of expected outcomes or errors, making it barely adequate for an AI agent.

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

Parameters1/5

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

The description provides no explanation for the template_id parameter. With 0% schema coverage on parameters, the description must compensate but fails entirely, leaving the agent to infer the parameter's meaning from context.

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 (Delete) and the resource (a SignWell template). This effectively distinguishes it from sibling tools like template_create, template_get, and template_update.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives or any prerequisites. While the purpose is obvious, the lack of context or exclusions limits its helpfulness for an AI agent deciding between tools.

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

template_getA

Read-only

Fetch an individual SignWell template by ID.

ParametersJSON Schema

Name	Required	Description	Default
`template_id`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description adds no extra behavioral context. It does not contradict annotations, but lacks additional disclosure such as permissions or rate limits.

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 a single sentence that is front-loaded and contains no unnecessary words. Every word 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?

For a simple read tool with clear annotations and a single parameter, the description is sufficient. It could mention that the output is the full template object, but given no output schema, the current level is adequate.

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 0%, but with only one required parameter (template_id), the description 'by ID' clarifies its role. Baseline for 0 params is 4, and the description adds meaning beyond the schema.

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 the action (Fetch) and specific resource (an individual SignWell template by ID). It distinguishes itself from sibling tools like template_list (which fetches all templates) and template_create (which creates).

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 implies usage when a specific template ID is known, which is clear context. However, no explicit exclusions or alternatives are mentioned, though the purpose sufficiently guides selection.

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

template_listB

Read-only

List SignWell templates with pagination.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`per_page`	No

TDQS

B3.3/5.0

Behavior3/5

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

The readOnlyHint annotation already indicates a safe read operation. The description adds 'pagination' context but lacks details on rate limits, default ordering, or behavior when reaching the end of results. Does not contradict annotations.

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

Conciseness4/5

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

Extremely concise with no wasted words. However, it is slightly under-specified; a bit more detail on parameters would not have reduced conciseness significantly.

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

Completeness3/5

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

Given the tool is a simple list with no output schema, the description is adequate but minimal. It does not specify default ordering or how to handle pagination across multiple requests, which an agent might need for full usage.

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

Parameters2/5

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

With 0% schema description coverage, the description should explain the parameters. It only hints at pagination without explicitly mapping 'page' and 'per_page' to the pagination mechanism, leaving the agent to infer their roles.

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 the verb 'List' and resource 'SignWell templates', and includes 'with pagination' to indicate the core feature. It effectively differentiates from sibling tools like template_get (single template) and template_create.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like document_list or how to handle pagination across multiple calls. No mention of filtering, ordering, or limitations.

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

template_updateA

Update an existing SignWell template. Only provide fields you want to change.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`draft`	No
`files`	No
`fields`	No
`labels`	No
`message`	No
`subject`	No
`language`	No
`metadata`	No
`reminders`	No
`text_tags`	No
`expires_in`	No
`template_id`	Yes
`placeholders`	No
`redirect_url`	No
`allow_decline`	No
`allow_reassign`	No
`checkbox_groups`	No
`api_application_id`	No
`apply_signing_order`	No
`attachment_requests`	No
`copied_placeholders`	No
`decline_redirect_url`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds the behavioral trait of partial/merge update, which is valuable 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?

A single, front-loaded sentence that effectively conveys the core purpose and key usage constraint. No unnecessary words.

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

Completeness2/5

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

Given the tool's complexity (23 parameters, nested objects, no output schema), the description is too minimal. It lacks information about return value (expected response), prerequisites (need template_id), and error conditions. More context is needed for reliable usage.

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?

The description adds no detail about individual parameters beyond the schema. The schema itself has rich descriptions for most parameters, so high coverage keeps baseline at 3. The partial update hint adds some value but not parameter-specific.

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 the action (update), the resource (existing SignWell template), and the constraint (only provide fields to change). It distinguishes from sibling tools like template_create and template_delete.

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 says when to use (update existing template) and implies partial update ('only provide fields you want to change'). No explicit mention of when not to use or alternatives, but context from sibling tools makes it clear.

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. Dates show when Glama detected each change.

14 tool updatesv0.3.3Jul 6, 2026
- First observeddocument_completed_pdf
- First observeddocument_create
- First observeddocument_get
- First observeddocument_list
- First observeddocument_send_draft
- First observeddocument_send_reminder
- First observedfile_store
- First observedfile_validate_text_tags
- First observedtemplate_create
- First observedtemplate_create_document
- First observedtemplate_delete
- First observedtemplate_get
- First observedtemplate_list
- First observedtemplate_update

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action: document creation vs. template creation, file validation vs. file storage, etc. There is no ambiguity; even similar tools like document_send_draft and document_send_reminder have clearly different purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., document_create, template_list, file_store) using snake_case. No deviations or mixed conventions.

Tool Count5/5

With 14 tools, the count is well within the 3-15 ideal range. Each tool addresses a specific step in the document signing workflow without being excessive or lacking.

Completeness4/5

The tool set covers core CRUD operations for documents and templates, file handling, validation, sending, reminders, and PDF retrieval. A minor gap is the absence of a document_delete tool, but deletion may be intentionally omitted as it's not a common part of the workflow.

Maintenance

ActivitySlowing

ResponsivenessSlow

Resources

Need Help?

Related Servers

Related MCP Connectors

PandaDoc MCP ServerOAuth
com.pandadoc.mcp
PandaDoc MCP server for creating, sending, signing, and tracking PandaDoc documents.
Workplace & Productivity Legal & Compliance Project Management
22
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
dropbox-sign A
io.usefulapi
Hosted MCP server for Dropbox Sign — signature requests, templates, and account for AI agents.
Legal & Compliance Workplace & Productivity
102
Studex MCP ServerOAuth
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1

Related MCP Servers

Tradovate MCP Server
Finance Databases
alexanimal
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables interaction with the Tradovate API for managing trading contracts, positions, orders, and accounts.
Updated a year ago (2025-03-27 20:48 UTC)
1
MIT
MCP Google Suite
Cloud Storage App Automation
adexltd
A
license
A
quality
C
maintenance
A Model Context Protocol server that provides seamless integration with Google Workspace, allowing operations with Google Drive, Docs, and Sheets through secure OAuth2 authentication.
Updated a year ago (2025-03-28 11:14 UTC)
8
3
MIT
Klaviyo MCP Server
Customer Data Platforms Marketing RAG Systems
ivan-rivera-projects
F
license
D
quality
C
maintenance
A comprehensive Model Context Protocol server that enables interaction with the Klaviyo API, providing tools and resources for managing customer profiles, lists, segments, campaigns, flows, and various marketing automation features.
Updated a year ago (2025-05-16 16:58 UTC)
47
3
-
boldsignofficial
Documentation Access App Automation Content Management Systems
boldsign
A
license
A
quality
D
maintenance
Model Context Protocol (MCP) server for BoldSign API
Updated 18 days ago (2026-08-20 05:22 UTC)
14
32
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bidsketch/signwell-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SignWell MCP Server

Prerequisites

Setup

Interactive Wizard (recommended)

Manual exports

Installation (npm)

Local Development Workflow

Running the Server

MCP Inspector

Tests

Demo

Privacy Policy

Data Collection

Usage & Storage

Third-Party Sharing

Telemetry & Analytics

Data Retention

Contact

Resources

Attaching Files & Draft Safety

Available Scripts

Directory Layout

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

boldsignofficial

Latest Blog Posts

MCP directory API