SignNow MCP Server
OfficialThe SignNow MCP Server enables AI agents to securely manage eSignature workflows through structured access to SignNow's API functionality.
Core Capabilities:
Template & Document Management - Browse templates and groups (
list_all_templates,list_document_groups), create documents from templates (create_from_template)Document Invites - Send email invites with ordered recipients (
send_invite) or create embedded signing sessions (create_embedded_invite)Embedded Experiences - Generate embedded links for signing, sending/management (
create_embedded_sending), and document editing (create_embedded_editor)One-Shot Workflows - Combine template creation with immediate actions like sending invites (
send_invite_from_template) or embedded experiencesStatus Tracking - Monitor invite status and step details (
get_invite_status) for documents and groupsDocument Retrieval - Download completed documents (
get_document_download_link), access full document structures with field values (get_document)Field Management - Pre-fill or update text fields in documents (
update_document_fields)Multiple Transports - Operate via STDIO for local clients or Streamable HTTP for Docker/remote deployments
Supports containerized deployment of the SignNow MCP server using Docker and Docker Compose for scalable eSignature workflow management
Uses environment variable configuration for secure credential management and API authentication settings
Provides source code hosting and collaboration features for the SignNow MCP server project
Integrates with GitHub Copilot Agent Mode to provide AI-powered eSignature workflow automation and code assistance for SignNow API development
Provides integration examples for using SignNow eSignature tools within LangChain AI agent frameworks
Supports OpenAI models for AI-powered document signing, template management, and eSignature workflow automation
Uses Pydantic for configuration validation and data modeling in SignNow API interactions
Distributed through PyPI package manager for easy installation of the SignNow MCP server
Built with Python 3.11+ for SignNow eSignature API integration and MCP server functionality
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@SignNow MCP Serversend our NDA template to jane@example.com for signature"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The SignNow REST API empowers users to deliver a seamless eSignature experience for signers, preparers, and senders. Pre-fill documents, create embedded branded workflows for multiple signers, request payments, and track signature status in real-time. Ensure signing is simple, secure, and intuitive on any device.
What you can do with the SignNow API:
Send documents and document groups for signature in a role-based order
Create reusable templates from documents
Pre-fill document fields with data
Collect payments as part of the signing flow
Embed the document sending, signing, or editing experience into your website, application, or any system of record
Track signing progress and download the completed documents
SignNow MCP Server
A Model Context Protocol (MCP) server that gives AI agents secure, structured access to SignNow eSignature workflows — templates, embedded signing, invites, status tracking, and document downloads — over STDIO or Streamable HTTP.
mcp-name: io.github.signnow/sn-mcp-server
Table of contents
Related MCP server: boldsign
Features
Templates & groups
Browse all templates and template groups
Create documents or groups from templates (one-shot flows included)
Invites & embedded UX
Email invites and ordered recipients
Embedded signing/sending/editor links for in-app experiences
Status & retrieval
Check invite status and step details
Download final documents (single or merged)
Read normalized document/group structure for programmatic decisions
Transports
STDIO (best for local clients)
Streamable HTTP (best for Docker/remote)
Quick start
Prerequisites
SignNow account. Create a free developer account.
SignNow Credentials: You will need your account email, password, and the application Basic Authorization Token. Getting started.
An active SignNow API application.
Python 3.11+ installed on your system (check with python3 --version)
UVX installed (check with uvx --version). Recommended for the quickest setup.
Environment variables configured
If your client supports Streamable HTTP, you can use the pre-deployed server URL
https://mcp-server.signnow.com/mcpinstead of running it locally.
Quick run (uvx)
If you use uv, you can run the server without installing the package:
uvx --from signnow-mcp-server sn-mcp serve1. Setup Environment Variables
# Create .env file with your SignNow credentials
# You can copy from env.example if you have the source code
# Or create .env file manually with required variables (see Environment Variables section below)2. Install and Run
Option A: Install from PyPI (Recommended)
# Install the package from PyPI
pip install signnow-mcp-server
# Run MCP server in standalone mode
sn-mcp serveOption B: Install from Source (Development)
# 1) Clone & configure
git clone https://github.com/signnow/sn-mcp-server.git
cd sn-mcp-server
cp .env.example .env
# fill in your values in .env
# 2) Install (editable for dev)
pip install -e .
# 3) Run as STDIO MCP server (recommended for local tools & Inspector)
sn-mcp serveSTDIO is ideal for desktop clients and local testing.
Local/Remote (HTTP)
# Start HTTP server on 127.0.0.1:8000
sn-mcp http
# Custom host/port
sn-mcp http --host 0.0.0.0 --port 8000
# Dev reload
sn-mcp http --reloadBy default, the Streamable HTTP MCP endpoint is served under /mcp. Example URL:
http://localhost:8000/mcpDocker
# Build
docker build -t sn-mcp-server .
# Run HTTP mode (recommended for containers)
docker run --env-file .env -p 8000:8000 sn-mcp-server sn-mcp http --host 0.0.0.0 --port 8000STDIO inside containers is unreliable with many clients. Prefer HTTP when using Docker.
Docker Compose
# Only the MCP server
docker-compose up sn-mcp-server
# Both services (if defined)
docker-compose upConfiguration
Copy .env.example → .env and fill in values. All settings are validated via pydantic-settings at startup.
Authentication options
1) API Key / Access Token (simplest)
SIGNNOW_ACCESS_TOKEN=<your_api_key>
# or equivalently:
SIGNNOW_API_KEY=<your_api_key>2) Username / Password
SIGNNOW_USER_EMAIL=<email>
SIGNNOW_PASSWORD=<password>
SIGNNOW_API_BASIC_TOKEN=<base64 basic token>3) OAuth 2.0 (for hosted/advanced scenarios)
SIGNNOW_CLIENT_ID=<client_id>
SIGNNOW_CLIENT_SECRET=<client_secret>
# + OAuth server & RSA settings belowWhen running via some desktop clients, only user/password may be supported.
Per-request access token (HTTP transport)
For multi-tenant / proxy deployments, a wrapping backend can attach the raw SignNow
access token per request via a dedicated HTTP header — no env config, and without
reusing Authorization (which carries the MCP/OAuth bearer):
X-SignNow-Access-Token: <raw SignNow access_token>Value is the raw token — no
Bearerprefix.Resolved per request; nothing is cached or stored (stateless).
Precedence: an env-configured
SIGNNOW_ACCESS_TOKEN(Option 1) still wins. To use the header as a true per-request credential, do not also setSIGNNOW_ACCESS_TOKEN— otherwise every request collapses to the env token. The header outranks a genericAuthorization: Bearer.HTTP transport only (
sn-mcp http). It is not exposed as a tool argument, so the token never enters the model's context or conversation logs. Send over HTTPS.
SignNow & OAuth settings
# SignNow endpoints (defaults shown)
SIGNNOW_APP_BASE=https://app.signnow.com
SIGNNOW_API_BASE=https://api.signnow.com
# OAuth server (if you enable OAuth mode)
OAUTH_ISSUER=<your_issuer_url>
ACCESS_TTL=3600
REFRESH_TTL=2592000
ALLOWED_REDIRECTS=<comma,separated,uris>
# RSA keys for OAuth (critical in production)
OAUTH_RSA_PRIVATE_PEM=<PEM content>
OAUTH_JWK_KID=<key id>Production key management
If OAUTH_RSA_PRIVATE_PEM is missing in production, a new RSA key will be generated on each restart, invalidating all existing tokens. Always provide a persistent private key via secrets management in prod.
Client setup
VS Code — GitHub Copilot (Agent Mode) / Cursor
Create .vscode/mcp.json / .cursor/mcp.json in your workspace:
STDIO (local):
{
"servers": {
"signnow": {
"command": "sn-mcp",
"args": ["serve"],
"env": {
"SIGNNOW_USER_EMAIL": "${env:SIGNNOW_USER_EMAIL}",
"SIGNNOW_PASSWORD": "${env:SIGNNOW_PASSWORD}",
"SIGNNOW_API_BASIC_TOKEN": "${env:SIGNNOW_API_BASIC_TOKEN}"
}
}
}
}STDIO (uvx — no local install):
{
"servers": {
"signnow": {
"command": "uvx",
"args": ["--from", "signnow-mcp-server", "sn-mcp", "serve"],
"env": {
"SIGNNOW_USER_EMAIL": "${env:SIGNNOW_USER_EMAIL}",
"SIGNNOW_PASSWORD": "${env:SIGNNOW_PASSWORD}",
"SIGNNOW_API_BASIC_TOKEN": "${env:SIGNNOW_API_BASIC_TOKEN}"
}
}
}
}HTTP (remote or Docker):
{
"servers": {
"signnow": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}Then open Chat → Agent mode, enable the signnow tools, and use them in prompts.
Note: The same configuration applies in Cursor — add it under MCP settings (STDIO or HTTP). For STDIO, you can also use uvx as shown above.
Claude Desktop
Use Desktop Extensions or the manual MCP config (Developer → Edit config).
Steps:
Open Claude Desktop → Developer → Edit config
Add a new server entry under
mcpServersSave and restart Claude Desktop
Examples:
STDIO (local install):
{
"mcpServers": {
"signnow": {
"command": "sn-mcp",
"args": ["serve"],
"env": {
"SIGNNOW_USER_EMAIL": "${env:SIGNNOW_USER_EMAIL}",
"SIGNNOW_PASSWORD": "${env:SIGNNOW_PASSWORD}",
"SIGNNOW_API_BASIC_TOKEN": "${env:SIGNNOW_API_BASIC_TOKEN}"
}
}
}
}STDIO (uvx — no local install):
{
"mcpServers": {
"signnow": {
"command": "uvx",
"args": ["--from", "signnow-mcp-server", "sn-mcp", "serve"],
"env": {
"SIGNNOW_USER_EMAIL": "${env:SIGNNOW_USER_EMAIL}",
"SIGNNOW_PASSWORD": "${env:SIGNNOW_PASSWORD}",
"SIGNNOW_API_BASIC_TOKEN": "${env:SIGNNOW_API_BASIC_TOKEN}"
}
}
}
}HTTP (remote or Docker):
{
"mcpServers": {
"signnow": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}Then enable the server in Claude’s chat and start using the tools.
Glama (hosted MCP)
Deploy and run this server on Glama with minimal setup:
Steps:
Open the server page on Glama: sn-mcp-server on Glama
Click the red "Deploy Server" button
In environment variables, provide:
SIGNNOW_USER_EMAILSIGNNOW_PASSWORDSIGNNOW_API_BASIC_TOKEN(other variables can be left as defaults)
Create an access token in Glama and copy the endpoint URL. It will look like:
https://glama.ai/endpoints/{someId}/mcp?token={glama-mcp-token}Use this HTTP MCP URL in any client that supports HTTP transport (e.g., VS Code/Cursor JSON config or Claude Desktop HTTP example above).
MCP Inspector (testing)
Great for exploring tools & schemas visually.
# Start Inspector (opens UI on localhost)
npx @modelcontextprotocol/inspector
# Connect (STDIO): run your server locally and attach
sn-mcp serve
# Or connect (HTTP): use http://localhost:8000/mcpYou can list tools, call them with JSON args, and inspect responses.
Tools
Each tool is described concisely; use an MCP client (e.g., Inspector) to view exact JSON schemas.
list_all_templates— List templates & template groups with simplified metadata. Supportslimit/offsetpagination (default: 50 items per page).list_contacts— Search CRM contacts by name, email, or phone. Returns id, email, first/last name, and company. Use beforesend_inviteto resolve a recipient's email address by their name. Supportsper_page(default 15, max 100).list_documents— Browse your documents, document groups and statuses. Supportslimit/offsetpagination (default: 50 items per page).create_from_template— Make a document or a group from a template/group.create_template— Convert a document or document group into a reusable template for signing.send_invite— Email invites (documents or groups), ordered recipients supported. Auto-detects freeform documents (no fields) — omitrolefor freeform recipients. Passself_sign=True(with noorders) to sign the document yourself: the tool resolves your email server-side and returns aSendInviteResponsewhose optionallinkfield holds a ready-to-open signing link (also populated when a freeform recipient email matches the authenticated user). For template/template group it auto-creates document/document group first.create_embedded_invite— Embedded signing session without email delivery for documents/groups/templates. For template/template group it auto-creates document/document group first.create_embedded_sending— Embedded “sending/management” experience for documents/groups/templates. For template/template group it auto-creates document/document group first.create_embedded_editor— Embedded editor link to place/adjust fields for documents/groups/templates. For template/template group it auto-creates document/document group first.send_invite_from_template— One-shot: create from template and invite.create_embedded_sending_from_template— One-shot: template → embedded sending.create_embedded_editor_from_template— One-shot: template → embedded editor.create_embedded_invite_from_template— One-shot: template → embedded signing.get_invite_status— Current invite status/steps for document or group. Covers field invites and freeform invites (field path preferred when both exist). Response includesinvite_mode(fieldorfreeform). For freeform document groups, signer emails come from the groupdocumentslist (signature_requests).get_document_download_link— Direct download link (merged output for groups).get_signing_link— Get signing link for a document or document group.get_document— Normalized document/group structure with field values, plus the folder the entity is stored in (folder_id/folder_name) at v3.0.update_document_fields— Prefill text fields in individual documents.upload_document— Upload a file from a local file path (file_path), public URL (file_url), or MCP resource attachment (resource_uri). Setkind='template'(default'document') to store it as a reusable template instead of a regular document (the returneddocument_idis then a template ID andnext_stepsswitch to the template follow-ups). Forfile_path, the resolved path must stay within the configured safe base directory (by default, the user's home directory); paths outside that base fail validation. Supported: PDF, DOC, DOCX, PNG, JPG, JPEG. Max 40 MB. Returnsdocument_id,filename,source.send_invite_reminder— Send a signing reminder to pending signers on a document or document group.cancel_invite— Cancel all active (pending) signing invites on a document or document group. Auto-detects entity type and invite type (field vs freeform). Returns status:cancelled,completed(already done), orinvite_not_sent.update_invite_recipient— Replace the signing recipient on a pending field invite. Finds the pending invite for the current signer and swaps in a new email. Supports both documents and document groups. Only field invites — freeform/embedded are unsupported.view_document— Generate a read-only embedded view link for a document or document group. In MCP Apps-compatible clients the document renders inline; in other hosts the link is returned as a clickable URL.rename_entity— Rename a document, document group, template, or template group. Auto-detects entity type when not provided.signnow_skills— Query the bundled SignNow skill library. Omitskill_nameto list all available skills with descriptions; provideskill_name(e.g.signnow101) to fetch the full Markdown body. Usesignnow101to learn SignNow entity types, invite types, and tool mappings.List mode example:
{"skills": [{"name": "signnow101", "description": "SignNow 101 concepts reference... (description truncated for brevity)"}]}Fetch mode example:
{"name": "signnow101", "body": "# SignNow 101 — Concepts Reference\n..."}
Tip: Start with
signnow_skills(no arguments) to discover available skills, thenlist_all_templates→create_from_template→create_embedded_*/send_invite, thenget_invite_statusandget_document_download_link.
FAQ / tips
STDIO vs Docker? Prefer STDIO for local dev; inside Docker, use HTTP.
Sandbox vs production? Start with SignNow’s sandbox/dev credentials; production requires proper OAuth and persistent RSA private key.
Where do I see exact tool schemas? Use MCP Inspector or your client’s “tool details” view.
Where are examples? See
examples/in this repo for starter integrations.
Examples
The examples/ directory contains working examples of how to integrate the SignNow MCP Server with popular AI agent frameworks:
LangChain - Integration with LangChain agents using
langchain-mcp-adaptersLlamaIndex - Integration with LlamaIndex agents using
llama-index-tools-mcpSmolAgents - Integration with SmolAgents framework using native MCP support
Each example demonstrates how to:
Start the MCP server as a subprocess
Convert MCP tools to framework-specific tool formats
Create agents that can use SignNow functionality
Handle environment variable configuration
To run an example:
# Make sure you have the required dependencies installed
pip install langchain-openai langchain-mcp-adapters # for LangChain example
pip install llama-index-tools-mcp # for LlamaIndex example
pip install smolagents # for SmolAgents example
# Set up your .env file with SignNow credentials and LLM configuration
# Then run the example
python examples/langchain/langchain_example.py
python examples/llamaindex/llamaindex_example.py
python examples/smolagents/stdio_demo.pyUseful resources
Sample apps
Explore ready-to-use sample apps to quickly test preparing, signing, and sending documents from your software using the SignNow API.
Try the sample apps.
API documentation
Find technical details on SignNow API requests, parameters, code examples, and possible errors. Learn more about the API functionality in detailed guides and use cases.
Read the API documentation.
SignNow API Helper MCP
Connect your AI to access API docs, generate code for complex signing workflows, and troubleshoot integration errors automatically. Access the API Helper MCP
License
MIT — see LICENSE.md.
About SignNow MCP Server — maintained by the SignNow team. Issues and contributions welcome via GitHub pull requests.
Available Tools
25 toolscancel_inviteCancel signing inviteADestructiveIdempotent
Cancel all active (pending) signing invites on a document or document group. The entity's state may have changed in the SignNow editor since you last looked — re-read the current state first to confirm the current invite state, not what you saw earlier in the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional reason for cancellation | |
| entity_id | Yes | ID of the document or document group | |
| entity_type | No | Type of entity: 'document' or 'document_group' (optional). Auto-detected if not provided (tries document_group first). Pass explicitly to save one API call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | Result status: 'cancelled' (invites were cancelled), 'invite_not_sent' (no active invite found), 'completed' (all signers already completed) |
| entity_id | Yes | Document or document group ID |
| entity_type | Yes | Entity type: 'document' or 'document_group' |
| cancelled_invite_ids | No | List of cancelled invite IDs (empty when status is not 'cancelled') |
| cancelled_invite_type | No | Type of cancelled invites: 'field', 'freeform', or 'embedded' (populated only when status is 'cancelled') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive hint and idempotent hint. The description adds that all active invites are cancelled and warns about state changes, providing behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the action, second provides a crucial caution. No redundant information, efficiently conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, scope (document/group), and a practical caution about state staleness. Output schema exists, so return values are covered. Could potentially mention idempotency, but annotations already provide that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description does not add further parameter semantics, maintaining the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels active signing invites on a document or document group. The verb 'cancel' and resource 'signing invites' are specific, and the tool is distinct from sibling tools like send_invite or get_invite_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to re-read the current state before cancelling, implying when to use this tool cautiously. It provides context about potential stale state but does not explicitly list when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_embedded_editorCreate embedded editor linkA
Create embedded editor for editing a document, document group, template, or template group. For templates and template groups, automatically creates a document/group first, then creates the embedded editor.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document or document group (used only when entity_type is template or template_group) | |
| entity_id | Yes | ID of the document, document group, template, or template group | |
| entity_type | No | Type of entity: 'document', 'document_group', 'template', or 'template_group' (optional). Auto-detected if not provided. | |
| redirect_uri | No | Optional redirect URI after completion | |
| redirect_target | No | Optional redirect target: 'self' (default), 'blank' | |
| link_expiration_minutes | No | Link lifetime in minutes (15–43200). Default: 15 min. |
Output Schema
| Name | Required | Description |
|---|---|---|
| editor_url | Yes | URL for the embedded editor |
| editor_entity | Yes | Type of editor entity: 'document' or 'document_group' |
| created_entity_id | No | ID of the entity created from template (None when entity was document/document_group) |
| created_entity_name | No | Name of the entity created from template (None when entity was document/document_group) |
| created_entity_type | No | Type of created entity: 'document' or 'document_group' (None when entity was document/document_group) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds important behavioral context beyond annotations: the auto-creation of documents/groups when using templates or template groups. Annotations indicate readOnlyHint=false and destructiveHint=false, which align with the create operation. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Every sentence is informative and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and special behavior for templates. Given an output schema exists for return values, the description is mostly complete. Could mention prerequisites or error handling but not required for a clear tool understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides 100% coverage for all 6 parameters. The description adds minimal extra meaning beyond the schema, only explaining that the 'name' parameter is used when entity_type is template. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates an embedded editor for editing documents, document groups, templates, or template groups. Also explains the distinct behavior for templates (auto-creates a document first), which differentiates from sibling tools like create_embedded_editor_from_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., create_embedded_editor_from_template, create_embedded_invite). The description does not mention when-not-to-use or provide context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_embedded_editor_from_templateCreate from template and embedded editorA
Create a document or document group from a template or template group, then create an embedded editor link immediately. This tool is ONLY for templates and template groups.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document or document group | |
| entity_id | Yes | ID of the template or template group | |
| entity_type | No | Type of entity: 'template' or 'template_group' (optional, auto-detected if not provided). | |
| redirect_uri | No | Optional redirect URI after completion | |
| link_expiration | No | Link expiration in minutes (15–45) | |
| redirect_target | No | Optional redirect target |
Output Schema
| Name | Required | Description |
|---|---|---|
| editor_url | Yes | URL for the embedded editor |
| editor_entity | Yes | Type of editor entity: 'document' or 'document_group' |
| created_entity_id | Yes | ID of the created document or document group |
| created_entity_name | Yes | Name of the created entity |
| created_entity_type | Yes | Type of created entity: 'document' or 'document_group' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness. Description adds 'immediately' for link creation but lacks details on side effects like template consumption or account impact. Adequate given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with core action. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and scope well; output schema handles return info. Could mention error conditions or prerequisites, but sufficient for an agent with schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are clear. The description adds no additional meaning beyond what's in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a document/group and an embedded editor link from a template/group, with explicit 'ONLY for templates and template groups' distinguishing it from siblings like create_embedded_editor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States tool is only for templates/template groups, giving clear context. Does not explicitly compare to alternatives like create_embedded_editor or create_from_template, but the 'ONLY' implies exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_embedded_inviteCreate embedded signing inviteADestructive
Create embedded invite for signing a document, document group, template, or template group. For templates and template groups, automatically creates a document/group first, then creates the embedded invite. The entity's state may have changed in the SignNow editor since you last looked — re-read the current state first and build this request from the current roles/fields, not from earlier in the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document or document group (used only when entity_type is template or template_group) | |
| orders | Yes | List of orders with recipients (or a JSON string of the same). | |
| entity_id | Yes | ID of the document, document group, template, or template group | |
| entity_type | No | Type of entity: 'document', 'document_group', 'template', or 'template_group' (optional). Auto-detected if not provided. |
Output Schema
| Name | Required | Description |
|---|---|---|
| invite_entity | Yes | Type of invite entity: 'document' or 'document_group' |
| recipient_links | Yes | Array of objects with role, invite id (for document invite) and link for recipients with delivery_type='link' |
| created_entity_id | No | ID of the entity created from template (None when entity was document/document_group) |
| created_entity_name | No | Name of the entity created from template (None when entity was document/document_group) |
| created_entity_type | No | Type of created entity: 'document' or 'document_group' (None when entity was document/document_group) |
| document_group_invite_id | No | ID of the created document group embedded invite; populated only when invite_entity is 'document_group', otherwise None |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations: it discloses that for templates and template groups, it automatically creates a document/group first. The warning about stale state is also valuable. Annotations already indicate destructive and non-idempotent behavior, and the description aligns perfectly without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the core purpose and follows with a critical caution. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, multiple entity types, output schema exists), the description covers the essential behaviors and adds a state-reading warning. It does not explain error conditions or the output format, but the output schema presumably handles that. Slightly incomplete for a full picture, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that the 'name' parameter is only used when entity_type is template or template_group, and that 'entity_type' is auto-detected if not provided. This clarifies parameter usage beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an embedded invite for signing, and specifies the supported entity types (document, document group, template, template group). It distinguishes from siblings by mentioning the auto-creation behavior for templates, which is unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a crucial guideline: re-read the current state before building the request to avoid using stale roles/fields. However, it does not explicitly state when not to use this tool or directly compare with siblings like create_embedded_invite_from_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_embedded_invite_from_templateCreate from template and embedded inviteA
Create a document or document group from a template or template group, then create an embedded signing invite immediately. This tool is ONLY for templates and template groups.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document or document group | |
| orders | No | List of orders with recipients for the embedded invite (can be a list or JSON string) | |
| entity_id | Yes | ID of the template or template group | |
| entity_type | No | Type of entity: 'template' or 'template_group' (optional, auto-detected if not provided). |
Output Schema
| Name | Required | Description |
|---|---|---|
| invite_id | Yes | ID of the created embedded invite |
| invite_entity | Yes | Type of invite entity: 'document' or 'document_group' |
| recipient_links | Yes | Array of objects with role and link for recipients with delivery_type='link' |
| created_entity_id | Yes | ID of the created document or document group |
| created_entity_name | Yes | Name of the created entity |
| created_entity_type | Yes | Type of created entity: 'document' or 'document_group' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly and non-idempotent behavior. The description adds that the tool creates both a document/group and an invite, but does not disclose other behavioral traits such as required permissions, error conditions, or side effects beyond creation. This is adequate given the annotation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, no redundancy, and immediately conveys the core functionality and restriction. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complex multi-step operation (create from template + embedded invite) and the presence of sibling tools for individual steps, the description clearly defines the scope. An output schema exists (not shown but indicated), so return value explanation is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the schema already provides meaning. The description does not add further parameter-specific guidance, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a document or document group from a template or template group, then create an embedded signing invite immediately') and explicitly restricts usage to templates and template groups, distinguishing it from sibling tools that operate on documents or invites separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is ONLY for templates and template groups, providing clear context. However, it does not explicitly mention when to use separate sibling tools (e.g., create_from_template + create_embedded_invite) instead of this combined tool, but the presence of sibling names implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_embedded_sendingCreate embedded sending linkA
Create embedded sending for managing, editing, or sending invites for a document, document group, template, or template group. For templates and template groups, automatically creates a document/group first, then creates the embedded sending. In MCP Apps-compatible clients the sender UI renders inline — no tab switch needed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document or document group (used only when entity_type is template or template_group) | |
| type | No | Type of sending step: 'manage', 'edit', or 'send-invite' | manage |
| entity_id | Yes | ID of the document, document group, template, or template group | |
| entity_type | No | Type of entity: 'document', 'document_group', 'template', or 'template_group' (optional). Auto-detected if not provided. | |
| redirect_uri | No | Optional redirect URI after completion | |
| redirect_target | No | Optional redirect target: 'self' (default), 'blank' | |
| link_expiration_minutes | No | Link lifetime in minutes (15–45). Default: 15 min. |
Output Schema
| Name | Required | Description |
|---|---|---|
| sending_url | Yes | URL for the embedded sending |
| sending_entity | Yes | Type of sending entity: 'document', 'document_group', or 'invite' |
| created_entity_id | No | ID of the entity created from template (None when entity was document/document_group) |
| created_entity_name | No | Name of the entity created from template (None when entity was document/document_group) |
| created_entity_type | No | Type of created entity: 'document' or 'document_group' (None when entity was document/document_group) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive traits. The description adds important behavioral details: for templates/template groups, it automatically creates a document/group first, and in compatible clients the UI renders inline. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose. Every sentence provides value: the first defines the core action, the second adds essential behavioral context. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters, output schema existence, and annotations, the description covers the main purpose and key behaviors. It could mention prerequisites (e.g., entity must exist) or link details, but the existing content is reasonably complete for a tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it only implicitly relates to the 'name' parameter via the auto-creation mention. The enum values for 'type' are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'embedded sending', and specifies the supported entity types: document, document group, template, template group. It also distinguishes behavior for templates by noting auto-creation of a document first. This level of specificity helps differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (for managing, editing, or sending invites) and mentions inline rendering. However, it does not explicitly state when not to use it or name alternative sibling tools, such as create_embedded_sending_from_template, despite the many related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_embedded_sending_from_templateCreate from template and embedded sendingA
Create a document or document group from a template or template group, then create an embedded sending link immediately. This tool is ONLY for templates and template groups.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document or document group | |
| type | No | Type of sending step: 'manage', 'edit', or 'send-invite' | manage |
| entity_id | Yes | ID of the template or template group | |
| entity_type | No | Type of entity: 'template' or 'template_group' (optional, auto-detected if not provided). | |
| redirect_uri | No | Optional redirect URI after completion | |
| link_expiration | No | Link expiration in minutes (15–45) | |
| redirect_target | No | Optional redirect target |
Output Schema
| Name | Required | Description |
|---|---|---|
| sending_url | Yes | URL for the embedded sending |
| sending_entity | Yes | Type of sending entity: 'document', 'document_group', or 'invite' |
| created_entity_id | Yes | ID of the created document or document group |
| created_entity_name | Yes | Name of the created entity |
| created_entity_type | Yes | Type of created entity: 'document' or 'document_group' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the creation and immediate link generation behavior, which aligns with annotations (readOnlyHint=false). It adds context beyond annotations but could mention potential side effects like link expiration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no unnecessary words. Purpose and constraint are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, an output schema, and high schema coverage, the description covers the core goal. Minor missing context about the 'type' parameter's effect, but schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description does not add significant new information beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a document/group from a template/group and immediately creates an embedded sending link. The phrase 'ONLY for templates and template groups' distinguishes it from siblings like create_embedded_sending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is only for templates and template groups, providing clear context. However, it does not explicitly contrast with alternatives like create_embedded_sending or create_from_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_from_templateCreate from templateB
Create a new document or document group from an existing template or template group
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document group or document (required for template groups) | |
| entity_id | Yes | ID of the template or template group | |
| entity_type | No | Type of entity: 'template' or 'template_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Name of the created entity |
| entity_id | Yes | ID of the created document or document group |
| entity_type | Yes | Type of created entity: 'document' or 'document_group' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond what annotations provide. While annotations indicate non-destructive (destructiveHint=false) and open world (openWorldHint=true), the description does not elaborate on aspects like creation behavior, restrictions, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter structure, existing annotations, and output schema, the description covers the basic purpose but lacks usage guidelines and deeper behavioral context. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter described. The description summarizes the entity types (template/template_group) and the resulting document/group but does not add significant new meaning beyond the schema itself. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (document or document group) from a template or template group. It distinguishes itself from sibling tools like create_embedded_editor_from_template which focus on embedded editors rather than direct document creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternative tools like send_invite_from_template or create_embedded_editor_from_template. No conditions or exclusions are mentioned, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_templateCreate template from document or document groupA
Convert an existing document or document group into a reusable template
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ID of the document or document group to convert into a template | |
| entity_type | No | Type of entity: 'document' or 'document_group'. Omit to auto-detect (tries document_group first, then document). Pass explicitly to save one API call. | |
| template_name | Yes | Name for the new template |
Output Schema
| Name | Required | Description |
|---|---|---|
| entity_type | Yes | Entity type that was converted. |
| template_id | No | ID of the created template. None for the document_group path — SignNow processes document group templates asynchronously (202 Accepted). Use list_all_templates after a short delay to find the template group. |
| template_name | Yes | Requested name for the template. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive mutation. The description adds no further behavioral context, such as whether the original entity is preserved or modified, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loading the core purpose with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description is mostly complete. However, it omits details about effects on the original entity, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters well. The tool description adds minimal reinforcement like 'existing document or document group' but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'convert' and the resource 'existing document or document group' into a 'reusable template', which distinguishes it from sibling tools that create from templates or perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly compare with sibling tools or specify when not to use this tool. It implies a prerequisite (existing document/group) but lacks guidance on alternative tools like create_from_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentGet document or group detailsARead-onlyIdempotent
Get full document, template, template group or document group information with field values. Always returns the current server-side state; call it again to pick up edits made in the SignNow editor after an earlier fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ID of the document, template, template group or document group to retrieve | |
| entity_type | No | Type of entity: 'document', 'template', 'template_group' or 'document_group' (optional). If not provided, will be determined automatically |
Output Schema
| Name | Required | Description |
|---|---|---|
| invite | No | Unified invite info |
| documents | Yes | List of documents in this group |
| entity_id | Yes | Document group ID |
| group_name | Yes | Name of the document group |
| entity_type | Yes | Type of entity: 'document' or 'document_group' |
| last_updated | Yes | Unix timestamp of the last update |
| freeform_invite_id | No | Freeform invite ID, if a freeform invite exists on this entity |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context that it always returns the current server-side state and suggests re-fetching after edits, which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core purpose, the second adds behavioral nuance. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, annotations, and full parameter coverage, the description adequately covers the tool's behavior. It explains the refresh behavior and entity types, making it complete for a read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with clear parameter descriptions. The description reinforces that entity_id refers to various entity types and mentions field values, but does not add substantive new details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full information for documents, templates, template groups, or document groups, including field values. It distinguishes itself from sibling tools like list_documents (list vs. get) and get_document_download_link (different purpose).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises calling the tool again after editing to pick up changes, providing clear usage context. However, it lacks explicit guidance on when not to use it or comparisons to alternatives like view_document or get_invite_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_document_download_linkGet document download linkA
Get download link for a document or document group
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ID of the document or document group | |
| entity_type | No | Type of entity: 'document' or 'document_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type. |
Output Schema
| Name | Required | Description |
|---|---|---|
| link | Yes | Download link for the document |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Get'), but annotations set readOnlyHint=false, creating a contradiction. No additional behavioral context (e.g., link expiration, authentication needs) is provided beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it could be more informative about the nature of the download link (e.g., temporary, requires auth), especially with openWorldHint=true.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes both parameters. The description adds no additional meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a download link for a document or document group, using a specific verb and resource. It distinguishes from siblings like 'get_document' and 'get_signing_link'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The parameter description provides some contextual help for entity_type, but no overall usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_invite_statusGet invite statusARead-onlyIdempotent
Get invite status for a document or document group. Supports field invites and freeform invites (field invite is preferred when both exist). For freeform document groups, uses the group documents list so signature_requests include signer emails when the API provides them. Returns invite_mode 'field' or 'freeform'.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ID of the document or document group | |
| entity_type | No | Type of entity: 'document' or 'document_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type. |
Output Schema
| Name | Required | Description |
|---|---|---|
| steps | Yes | List of steps in the invite |
| status | Yes | Overall invite status: 'created', 'pending', 'fulfilled' |
| invite_id | Yes | ID of the invite |
| invite_mode | No | field = role/field invite path; freeform = mapped from free-form or group documents list |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds value by detailing internal logic: preferring field invites when both exist, and adapting behavior for freeform document groups to include signer emails. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each conveying essential information without redundancy. It is front-loaded with the core purpose and efficiently explains nuances and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two entity types, invite modes) and the presence of an output schema, the description adequately covers key behavioral aspects: invite mode preference, freeform group handling, and returned modes. No apparent gaps for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds practical guidance for entity_type, advising to ensure correct type and suggesting trying alternatives if not found, which aids correct invocation beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves invite status for a document or document group, distinguishing it from related tools like 'send_invite' or 'cancel_invite'. It further clarifies support for field and freeform invites, and notes the return of invite_mode, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by focusing on reading invite status, contrasting with sibling tools that create or modify invites. It explains preferences (field over freeform) and behavior for freeform groups, but 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.
get_signing_linkGet signing linkARead-onlyIdempotent
Get signing link for a document or document group
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ID of the document or document group | |
| entity_type | No | Type of entity: 'document' or 'document_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type. |
Output Schema
| Name | Required | Description |
|---|---|---|
| link | Yes | Signing link for the document or document group |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description does not contradict these and adds that it is a read operation. However, it does not disclose additional behavior like what happens if the entity is not found or if the user lacks permissions. Fairly standard for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded. It could include a brief note about the return format or usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, a clear purpose, and an output schema (to explain return values), the description is sufficiently complete. It covers the essential action and provides helpful parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters. The description adds value beyond the schema, especially for entity_type: it warns about knowing the type and suggests trying a different type if not found. This guidance aids the agent beyond the enum options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a signing link for a document or document group. The verb 'get' and the resource 'signing link' are specific. While it does not explicitly differentiate from sibling tools like 'get_document' or 'get_document_download_link', the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description and parameter hints provide minimal guidance. The entity_type parameter includes a note suggesting to try a different type if not found, which is helpful. However, there is no explicit statement about when to use this tool versus alternatives or prerequisites (e.g., entity must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_all_templatesList templates and template groupsARead-onlyIdempotent
Get simplified list of all templates and template groups with basic information
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-100, default 50) | |
| offset | No | Number of items to skip for pagination (default 0) |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | No | Maximum number of items in this page |
| offset | No | Number of items skipped |
| has_more | No | Whether more items exist beyond this page |
| templates | Yes | |
| total_count | Yes | Total number of templates across all pages |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds that the list is 'simplified' with 'basic information', which is useful but not extensive. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded. Efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is adequate but minimal. It does not mention pagination (though schema does) or the scope of data returned (e.g., all templates with pagination).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already fully describes limit and offset. The description does not add extra meaning beyond what is in the schema, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a simplified list of templates and template groups. The verb 'Get' and specific resource 'templates and template groups' distinguish it from sibling tools like list_documents or create_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., list_documents for documents). Given many sibling tools, explicit context or exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_contactsList CRM contactsARead-onlyIdempotent
Search CRM contacts by name, email, or phone. Use this tool before send_invite to resolve a recipient's email address by their name.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Filter contacts by name, email, or phone (partial match). Omit to return the first per_page contacts. | |
| per_page | No | Maximum number of contacts to return (1–100, default 15) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of contacts returned in this response |
| contacts | No | Matching contacts (empty list when no contacts match — not an error) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. Description adds no behavioral context beyond what annotations provide, but does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: first states purpose, second provides usage guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, output schema exists), the description fully covers behavior and integration with sibling tool, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). Description adds meaning by specifying partial match behavior and default value effect, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches CRM contacts by name, email, or phone, and distinguishes it from sibling send_invite by specifying its use to resolve email addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('before send_invite to resolve a recipient's email address by their name'), providing clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_documentsList documents and document groupsARead-onlyIdempotent
Get simplified list of documents and document groups with basic information. Returns both documents and document groups in a unified format. Use this tool to fetch lists of documents by status, e.g. documents waiting for your signature (waiting-for-me) or expired documents (expired_filter=expired).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-100, default 50) | |
| order | No | Order of sorting (optional, can be used only with sortby). Available values: asc, desc. | |
| filter | No | Filter by document group status (optional). Available values: signed, pending, waiting-for-me, waiting-for-others, unsent. | |
| offset | No | Number of items to skip for pagination (default 0) | |
| sortby | No | Sort by created date, updated date, or document name (optional). Available values: updated, created, document-name. | |
| folder_id | No | Filter by folder ID (optional) | |
| expired_filter | No | Filter by invite expiredness (optional, default: all). Available values: all, expired, not-expired. | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | No | Maximum number of items in this page |
| offset | No | Number of items skipped |
| has_more | No | Whether more items exist beyond this page |
| document_groups | Yes | |
| document_group_total_count | Yes | Total number of document groups across all pages |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not contradict annotations; it supplements them with behavioral details (simplified list, unified format, status filtering). Although it doesn't cover all traits (e.g., pagination is implied by parameters), it provides sufficient context for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes a concrete usage example. Every sentence earns its place; no unnecessary words. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and provides concrete usage examples (status and expired_filter). Since the output schema exists, the description does not need to detail return fields. The description is sufficiently complete for an agent to understand the tool's basic use case, though it omits mention of optional parameters like sorting and folder filtering, which are adequately described in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 7 parameters (100% coverage), detailing their types, defaults, and allowed values. The description does not add substantial new information about the parameters beyond reinforcing the filtering examples. Thus, it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves a simplified list of documents and document groups, mentions the unified format, and gives concrete usage examples (status filtering). It is distinct from sibling tools which are about specific actions like creating, sending, updating documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to fetch lists by status, e.g., waiting-for-me, expired) but does not explicitly state when alternative tools like `get_document` or `view_document` might be more appropriate. The context is sufficient to guide usage, but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rename_entityRename entityAIdempotent
Rename a document, document group, template, or template group.
| Name | Required | Description | Default |
|---|---|---|---|
| new_name | Yes | New name to apply | |
| entity_id | Yes | ID of the entity to rename | |
| entity_type | No | Entity type. Optional — all four types are auto-detected (document_group → template_group → template → document). Provide explicitly to skip detection. |
Output Schema
| Name | Required | Description |
|---|---|---|
| new_name | Yes | New name that was applied |
| entity_id | Yes | ID of the renamed entity |
| entity_type | Yes | Type of the renamed entity: document, document_group, template, or template_group |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is non-destructive and idempotent. The description adds the list of supported entity types but no additional behavioral context (e.g., effects on related entities, user permissions required).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct, no unnecessary words. Efficiently communicates the tool's action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename operation with an output schema (assumed), the description covers the essential. However, it could note that renaming does not affect signing links or other references, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema descriptions are complete (100% coverage). The description adds the list of entity types, which is already in the schema's enum. No additional constraints on new_name (e.g., length, format) are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Rename' and the resources: document, document group, template, or template group. This is specific and distinguishes it from sibling tools like send_invite or update_document_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. For instance, there is no mention of when renaming is appropriate or if there are constraints like 'cannot rename a document that is in a signing process'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_inviteSend signing inviteADestructive
Send invite to sign a document, document group, template, or template group. Supports both field invites (documents with roles/fields) and freeform invites (documents without fields). Document type is auto-detected — omit 'role' for freeform documents. For templates and template groups, automatically creates a document/group first, then sends the invite. Set self_sign=True (and omit orders) to sign the document yourself — the tool resolves the current user's email and populates SendInviteResponse.link with a direct signing link. The 'link' field is also populated when a freeform recipient's email matches the authenticated user's primary email. The entity's state may have changed in the SignNow editor since you last looked — re-read the current state first and build this request from the current roles/fields, not from earlier in the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document or document group (used only when entity_type is template or template_group) | |
| orders | No | List of orders with recipients (or a JSON string of the same). Required unless self_sign=True. When self_sign=True, omit orders — the tool fills in the current user as the sole recipient. | |
| entity_id | Yes | ID of the document, document group, template, or template group | |
| self_sign | No | If True, the tool resolves the current user's primary email server-side and sends a freeform invite to the user themselves. The response's 'link' field is populated with a direct signing link. Must be combined with an empty/omitted orders. Requires a field-less document or document group — for entities with fields/roles, use create_embedded_sending instead. | |
| entity_type | No | Type of entity: 'document', 'document_group', 'template', or 'template_group' (optional). Auto-detected if not provided. | |
| preview_was_shown | No | This flag signals that the user has viewed the document preview. Prompt the user to view the document before submitting. If the user says yes, call view_document first, show the result, then call send_invite again with preview_was_shown=True. If the user says no, call send_invite with preview_was_shown=False. |
Output Schema
| Name | Required | Description |
|---|---|---|
| link | No | Direct signing link. Populated only when the sender and recipient resolve to the same email (self_sign=True, or the recipient email equals the authenticated user's primary email). None for normal outbound invites. |
| invite_id | Yes | ID of the created invite |
| invite_entity | Yes | Type of invite entity: 'document' or 'document_group' |
| created_entity_id | No | ID of the entity created from template (None when entity was document/document_group) |
| created_entity_name | No | Name of the entity created from template (None when entity was document/document_group) |
| created_entity_type | No | Type of created entity: 'document' or 'document_group' (None when entity was document/document_group) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, and the description adds behavioral context: self_sign resolves the current user, the entity state may have changed, and the tool may create documents from templates. This adds value beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long and contains some redundancy (e.g., auto-detection mentioned twice). It is front-loaded with the main purpose but could be more concise without losing necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 1 required, and an output schema, the description covers entity types, self_sign, preview_was_shown workflow, and warns about stale state. It provides sufficient context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds functional context: role is required for field invites but omitted for freeform; orders are required unless self_sign; preview_was_shown describes a workflow. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an invite to sign a document, document group, template, or template group. It distinguishes between field and freeform invites and mentions auto-detection. However, it does not explicitly differentiate from sibling tools like create_embedded_invite or send_invite_from_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use self_sign, when to omit role, and warns about stale entity state. It suggests re-reading the entity state first. However, it lacks explicit comparisons with sibling tools to guide choice between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_invite_from_templateCreate from template and send inviteA
Create a document or document group from a template or template group, then send a signing invite immediately. This tool is ONLY for templates and template groups.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the new document or document group | |
| orders | Yes | List of orders with recipients for the invite (can be a list or JSON string) | |
| entity_id | Yes | ID of the template or template group | |
| entity_type | No | Type of entity: 'template' or 'template_group' (optional, auto-detected if not provided). |
Output Schema
| Name | Required | Description |
|---|---|---|
| invite_id | Yes | ID of the created invite |
| invite_entity | Yes | Type of invite entity: 'document' or 'document_group' |
| created_entity_id | Yes | ID of the created document or document group |
| created_entity_name | Yes | Name of the created entity |
| created_entity_type | Yes | Type of created entity: 'document' or 'document_group' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly discloses that the tool sends an invite immediately after creating the document, aligning with the annotations (readOnlyHint=false). It does not contradict annotations, and provides useful behavioral insight beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence covers the entire action, and the second adds a critical restriction. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context says has output schema: true) and 100% schema description coverage, the description adequately covers the main action and scope. It could mention prerequisites or error conditions (e.g., template must exist) for full completeness, but it is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all 4 parameters, so the baseline is 3. The description adds value by reinforcing that the tool works only with templates/template groups, which helps clarify the entity_type parameter. However, it does not add new parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it creates a document or document group from a template/template group and immediately sends a signing invite. It explicitly distinguishes itself by noting that it is ONLY for templates and template groups, which differentiates it from sibling tools like send_invite or create_from_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong guidance by stating the tool is only for templates and template groups, implying when to use it. However, it does not explicitly mention alternatives for non-template documents, which would improve clarity further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_invite_reminderSend signing reminderA
Send a signing reminder to pending signers on a document or document group.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Remind only this specific recipient. If omitted, all pending signers are reminded. | ||
| message | No | Ignored — resend reuses the invite's original email template, so a custom message is not applied. Compatibility only. | |
| subject | No | Ignored — resend reuses the invite's original email template, so a custom subject is not applied. Compatibility only. | |
| entity_id | Yes | Document ID or document group ID | |
| entity_type | No | Entity type: 'document' or 'document_group'. Auto-detected if omitted (document_group tried first). Pass explicitly to avoid an extra auto-detection GET. |
Output Schema
| Name | Required | Description |
|---|---|---|
| failed | No | Recipients for whom the API call failed (transient error — may be retried) |
| skipped | No | Recipients skipped because their invite is not pending (completed, cancelled, etc.) |
| entity_id | Yes | Document or document group ID |
| entity_type | Yes | 'document' or 'document_group' |
| recipients_reminded | No | Recipients who successfully received the reminder email |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) but no destructive or idempotent hints. The description adds minimal behavioral context: it sends a reminder. It does not disclose that reminders reuse the original email template (information is in schema descriptions but not in the description itself), nor does it mention side effects 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Directly communicates the tool's purpose without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool but lacks explanation of return values (though output schema exists) and does not mention default behavior (reminding all pending signers) or auto-detection of entity_type. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description does not add extra parameter meaning; it only states the overall action. Baseline 3 is appropriate since the schema already documents semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'send' and the resource 'signing reminder to pending signers on a document or document group'. It clearly distinguishes from siblings like 'send_invite' (initial invitation) by focusing on reminders for pending signers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'pending signers' which implies not for completed documents, but it does not provide explicit guidance on when to use this tool versus alternatives like 'cancel_invite' or 'send_invite'. No when-not or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
signnow_skillsQuery SignNow skill libraryARead-onlyIdempotent
Query the bundled SignNow skill library. Omit skill_name to list all skills with descriptions. Provide skill_name to read the full skill body. Load signnow101 before performing any SignNow action — it contains required workflow rules including when to preview before sending.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_name | No | Name of the skill to retrieve (e.g. 'signnow101'). Omit to list all available skills with their descriptions. |
Output Schema
| Name | Required | Description |
|---|---|---|
| body | No | Skill content in Markdown, front-matter removed (fetch mode only) |
| name | No | Skill identifier (fetch mode only) |
| skills | No | Available skills with descriptions (list mode only) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds context about the signnow101 prerequisite and the difference between listing and reading full body. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, dual modes, critical prerequisite. No wasted words. Front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param tool with output schema, the description covers usage and a key workflow dependency. Could mention what happens on invalid skill_name, but not necessary given output schema likely handles errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description reinforces it. Adds that providing skill_name reads the 'full skill body', which is not in schema. Also gives an example (signnow101). Adds moderate value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it queries the SignNow skill library, distinguishes listing vs reading modes, and importantly positions it as a prerequisite by directing the agent to load signnow101 before any action. Differentiates from sibling tools which are all actual SignNow actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains two usage modes (omit vs provide skill_name) and gives a critical workflow rule: load signnow101 before any SignNow action. This provides clear when and why to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_document_fieldsUpdate document text fieldsADestructiveIdempotent
Update text fields in multiple documents (only individual documents, not document groups)
| Name | Required | Description | Default |
|---|---|---|---|
| update_requests | Yes | Array of document field update requests |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Array of update results for each document |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms mutation (consistent with annotations) and adds a specific constraint not covered by annotations. Annotations already provide safety profile, so the description adds value without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full annotation coverage, the description adequately covers the tool's purpose and constraints. It is complete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already explains the update_requests structure in detail. The description adds no additional parameter-level semantics beyond stating the action and scope, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update', the resource 'text fields', and the scope 'multiple documents' with explicit exclusion of 'document groups', fully distinguishing from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear direction by stating that only individual documents are supported, not groups, guiding the agent on when to use this tool. No explicit alternatives are named, but the exclusion is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_invite_recipientReplace invite recipientADestructive
Replace the signing recipient on a pending field invite for a document or document group. Finds the pending invite for the current signer and replaces it with a new signer. For documents: deletes the old invite, creates a replacement, and triggers sending. For document groups: updates the pending step(s) with the new signer information. Only field invites are supported — freeform and embedded invites cannot be updated. The entity's state may have changed in the SignNow editor since you last looked — re-read the current state first and build this request from the current roles/recipients, not from earlier in the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Role name to match (for multi-role documents). If omitted, matches any role. | |
| entity_id | Yes | ID of the document or document group | |
| new_email | Yes | Email address of the new signer | |
| entity_type | No | Type of entity: 'document' or 'document_group' (optional). Auto-detected if not provided (tries document_group first). Pass explicitly to save one API call. | |
| current_email | Yes | Email address of the current signer to replace |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | Result status: 'replaced' (invite recipient was replaced and resent), 'no_pending_invite' (no pending/created invite found for current_email), 'unsupported_invite_type' (freeform or embedded invites cannot be updated) |
| entity_id | Yes | Document or document group ID |
| new_email | Yes | Email address of the new signer |
| entity_type | Yes | Entity type: 'document' or 'document_group' |
| new_invite_id | No | ID of the newly created invite (populated only when status is 'replaced') |
| updated_steps | No | List of step IDs that were updated (populated only for document_group with status 'replaced') |
| previous_email | Yes | Email address of the replaced signer |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true. Description adds details: for documents, deletes old invite and creates new; for groups, updates pending steps. Also warns about stale state, going 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative but moderately long. It front-loads the main action and uses clear structure, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers behavior for both document types and includes a warning about state changes. With an output schema present, return values are documented elsewhere. Adequately complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. Description adds context on role matching and auto-detection of entity_type, improving understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it replaces a signing recipient on a pending field invite for a document or document group. It distinguishes from siblings like cancel_invite or send_invite by specifying the replace action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context: only field invites are supported, freeform/embedded cannot be updated. It advises re-reading state before use. However, it does not explicitly name alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_documentUpload documentA
Upload a document to SignNow from a local file path, public URL, or MCP resource attachment. Supported file types: PDF, DOC, DOCX, PNG, JPG, JPEG. Max file size: 40 MB. On success the response includes a 'next_steps' array (prepare invite / send for signing / self-sign) and an 'agent_guidance' string — present those options to the user and wait for them to choose before calling any follow-up tool. NOTE: For URL uploads, the returned filename is locally inferred and may differ from how SignNow names the document.
| Name | Required | Description | Default |
|---|---|---|---|
| file_url | No | Publicly accessible URL to the file to upload. SignNow will fetch the file from this URL. Provide exactly one of resource_uri, file_path, or file_url. | |
| filename | No | Optional custom name for the document as it will appear in SignNow. If omitted, the name is derived from the file path, URL, or resource URI. Required when using resource_uri and the filename cannot be inferred. | |
| file_path | No | Absolute or ~-relative path to a local file to upload. The resolved path must be within the safe upload base directory (SAFE_UPLOAD_BASE, defaulting to your home directory); paths outside that base (e.g. /tmp/foo.pdf) will be rejected. Supported: .pdf, .doc, .docx, .png, .jpg, .jpeg. Provide exactly one of resource_uri, file_path, or file_url. | |
| resource_uri | No | MCP resource URI of an attached file (preferred when your client supports resource attachments). Provide exactly one of resource_uri, file_path, or file_url. |
Output Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | How the file was provided: 'local_file' (read from local path), 'url' (fetched by SignNow from URL), 'resource' (attached via MCP resource protocol) |
| filename | Yes | Name of the uploaded file. For 'local_file' and 'resource' sources this matches the name sent to SignNow. For 'url' source this is locally inferred from the URL and may differ from how SignNow actually names the document. |
| next_steps | Yes | Suggested follow-up actions the agent MUST present to the user after a successful upload, in the given order. Ask the user which one they want before proceeding — do not silently pick one. |
| document_id | Yes | ID of the uploaded document in SignNow |
| agent_guidance | Yes | Instruction for the agent: after upload, present the next_steps options to the user and wait for them to choose before calling any follow-up tool. Load the 'signnow101' skill via signnow_skills(skill_name='signnow101') if more context is needed. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (which only mark readOnlyHint and destructiveHint as false). It discloses supported file types, maximum file size, filename behavior for URL uploads, and the structure of the success response (next_steps, agent_guidance). This fully informs the agent of important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (approximately 5 sentences) with no filler. It is front-loaded with the primary purpose, followed by constraints, then post-upload behavior. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three input methods, size limits, filename handling, and structured return values), the description covers all critical aspects. The existence of an output schema is noted, so the description does not need to detail return fields; it correctly highlights the key post-upload guidance behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every parameter in the input schema has a schema description, but the tool description adds further meaning: it explains that resource_uri is preferred when supported, clarifies the path safety constraint for file_path (SAFE_UPLOAD_BASE), and notes when filename is required. This adds significant value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload a document to SignNow') and specifies the three methods of input (local file path, public URL, or MCP resource attachment). It is a specific verb+resource that differentiates from sibling tools which focus on invites, templates, and other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool (to upload a document) and crucially explains what to do after success: present next_steps options to the user and wait for a decision before calling any follow-up tool. It covers constraints like file types, max size, and a note about URL filename inference, but does not explicitly list when not to use it vs alternatives; however, the context of sibling tools makes this unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view_documentView documentARead-only
Generate a read-only embedded view link for a document or document group. To find an entity by name, first call list_documents or list_templates to search for it, then pass the returned entity_id here. In MCP Apps-compatible clients the document renders inline — no tab switch needed. In other hosts, the returned view_link is presented as a clickable URL.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ID of the document or document group to view | |
| entity_type | No | Type of entity: 'document' or 'document_group'. Skip for auto-detection (tries document_group first). | |
| link_expiration_minutes | No | Link lifetime in minutes (43200–518400). Defaults to 43200 (30 days) when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| entity_id | Yes | Document or document group ID |
| view_link | Yes | Embedded view link — opens the document in a read-only viewer without requiring SignNow login |
| entity_type | Yes | Entity type: 'document' or 'document_group' |
| document_name | Yes | Name of the document or document group |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures match annotations (readOnlyHint). Adds behavioral details: auto-detection of entity_type, default link expiration, inline vs clickable rendering. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value. No redundant information. Front-loaded with purpose, then workflow, then behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and high schema coverage, the description is complete. Covers purpose, usage, parameters, and rendering behavior. Well-differentiated from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds significant context: how to obtain entity_id, auto-detection logic for entity_type, and default expiration value. Goes beyond schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('generate'), resource ('read-only embedded view link'), and scope ('document or document group'). Differentiates from siblings by focusing on embedding and read-only access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides workflow: first call list_documents/list_templates to find entity by name, then pass entity_id. Explains rendering behavior in different clients. Does not explicitly say when not to use, but context is 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.
3 tool updates
v2.7.0- Changed
create_embedded_invite1 field changed- changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "description": "Order information for embedded invite.", - "properties": { - "order": { - "description": "Order number for this step", - "type": "integer" - }, - "recipients": { - "description": "List of recipients for this order", - "items": { - "description": "Recipient information for embedded invite.", - "properties": { - "action": { - "default": "sign", - "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", - "type": "string" - }, - "auth_method": { - "default": "none", - "description": "Authentication method in integrated app: 'password', 'email', 'mfa', 'biometric', 'social', 'other', 'none'", - "type": "string" - }, - "close_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens when clicking 'Close' button" - }, - "decline_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "URL that opens after decline" - }, - "delivery_type": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "link", - "description": "Invite delivery method: 'email' or 'link', use 'link' if you wand to get a link to sign. If you want to send an email, use 'email'" - }, - "email": { - "description": "Recipient's email address", - "type": "string" - }, - "first_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Recipient's first name" - }, - "last_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Recipient's last name" - }, - "message": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite email message (max 5000 chars)" - }, - "redirect_target": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "self", - "description": "Redirect target: 'blank' for new tab, 'self' for same tab" - }, - "redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens after completion" - }, - "role": { - "description": "Recipient's role name in the document", - "type": "string" - }, - "subject": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite email subject (max 1000 chars)" - } - }, - "required": [ - "email", - "role" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "order", - "recipients" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "string" - } -]New value: +[ + { + "items": { + "description": "Order information for embedded invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "description": "Recipient information for embedded invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "enum": [ + "view", + "sign", + "approve" + ], + "type": "string" + }, + "auth_method": { + "default": "none", + "description": "Authentication method in integrated app", + "enum": [ + "password", + "email", + "mfa", + "biometric", + "social", + "other", + "none" + ], + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "delivery_type": { + "anyOf": [ + { + "enum": [ + "email", + "link" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": "link", + "description": "Invite delivery method: use 'link' if you want to get a link to sign, use 'email' to send an email" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "first_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's first name" + }, + "last_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's last name" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email message (max 5000 chars)" + }, + "redirect_target": { + "anyOf": [ + { + "enum": [ + "blank", + "self" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": "self", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email subject (max 1000 chars)" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "string" + } +]
- Changed
create_embedded_invite_from_template1 field changed- changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "description": "Order information for embedded invite.", - "properties": { - "order": { - "description": "Order number for this step", - "type": "integer" - }, - "recipients": { - "description": "List of recipients for this order", - "items": { - "description": "Recipient information for embedded invite.", - "properties": { - "action": { - "default": "sign", - "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", - "type": "string" - }, - "auth_method": { - "default": "none", - "description": "Authentication method in integrated app: 'password', 'email', 'mfa', 'biometric', 'social', 'other', 'none'", - "type": "string" - }, - "close_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens when clicking 'Close' button" - }, - "decline_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "URL that opens after decline" - }, - "delivery_type": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "link", - "description": "Invite delivery method: 'email' or 'link', use 'link' if you wand to get a link to sign. If you want to send an email, use 'email'" - }, - "email": { - "description": "Recipient's email address", - "type": "string" - }, - "first_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Recipient's first name" - }, - "last_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Recipient's last name" - }, - "message": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite email message (max 5000 chars)" - }, - "redirect_target": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "self", - "description": "Redirect target: 'blank' for new tab, 'self' for same tab" - }, - "redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens after completion" - }, - "role": { - "description": "Recipient's role name in the document", - "type": "string" - }, - "subject": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite email subject (max 1000 chars)" - } - }, - "required": [ - "email", - "role" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "order", - "recipients" - ], - "type": "object" - }, - "type": "array" - }, - { - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "items": { + "description": "Order information for embedded invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "description": "Recipient information for embedded invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "enum": [ + "view", + "sign", + "approve" + ], + "type": "string" + }, + "auth_method": { + "default": "none", + "description": "Authentication method in integrated app", + "enum": [ + "password", + "email", + "mfa", + "biometric", + "social", + "other", + "none" + ], + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "delivery_type": { + "anyOf": [ + { + "enum": [ + "email", + "link" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": "link", + "description": "Invite delivery method: use 'link' if you want to get a link to sign, use 'email' to send an email" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "first_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's first name" + }, + "last_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's last name" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email message (max 5000 chars)" + }, + "redirect_target": { + "anyOf": [ + { + "enum": [ + "blank", + "self" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": "self", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email subject (max 1000 chars)" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "string" + }, + { + "type": "null" + } +]
- Changed
send_invite_reminder2 fields changed- changed
Input schema / properties / message / descriptionPrevious value: -"Custom message body for the reminder."New value: +"Ignored — resend reuses the invite's original email template, so a custom message is not applied. Compatibility only." - changed
Input schema / properties / subject / descriptionPrevious value: -"Custom email subject for the reminder."New value: +"Ignored — resend reuses the invite's original email template, so a custom subject is not applied. Compatibility only."
25 tool updates
v2.4.0- Added
cancel_invite - Added
create_embedded_editor - Added
create_embedded_editor_from_template - Added
create_embedded_invite - Added
create_embedded_invite_from_template - Added
create_embedded_sending - Added
create_embedded_sending_from_template - Added
create_from_template - Added
create_template - Added
get_document - Added
get_document_download_link - Added
get_invite_status - Added
get_signing_link - Added
list_all_templates - Added
list_contacts - Added
list_documents - Added
rename_entity - Added
send_invite - Added
send_invite_from_template - Added
send_invite_reminder - Added
signnow_skills - Added
update_document_fields - Added
update_invite_recipient - Added
upload_document - Added
view_document
25 tool updates
v2.2.3- Removed
cancel_invite - Removed
create_embedded_editor - Removed
create_embedded_editor_from_template - Removed
create_embedded_invite - Removed
create_embedded_invite_from_template - Removed
create_embedded_sending - Removed
create_embedded_sending_from_template - Removed
create_from_template - Removed
create_template - Removed
get_document - Removed
get_document_download_link - Removed
get_invite_status - Removed
get_signing_link - Removed
list_all_templates - Removed
list_contacts - Removed
list_documents - Removed
rename_entity - Removed
send_invite - Removed
send_invite_from_template - Removed
send_invite_reminder - Removed
signnow_skills - Removed
update_document_fields - Removed
update_invite_recipient - Removed
upload_document - Removed
view_document
26 tool updates
v2.2.1- Added
cancel_invite - Changed
create_embedded_editor11 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / entity_id / descriptionPrevious value: -"ID of the document or document group"New value: +"ID of the document, document group, template, or template group" - changed
Input schema / properties / entity_type / anyOfPrevious value: -[ - { - "enum": [ - "document", - "document_group" - ], - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "enum": [ + "document", + "document_group", + "template", + "template_group" + ], + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'document' or 'document_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type."New value: +"Type of entity: 'document', 'document_group', 'template', or 'template_group' (optional). Auto-detected if not provided." - removed
Input schema / properties / link_expirationRemoved value: -{ - "anyOf": [ - { - "maximum": 43200, - "minimum": 15, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Optional link expiration in minutes (15-43200)" -} - added
Input schema / properties / link_expiration_minutesAdded value: +{ + "anyOf": [ + { + "maximum": 43200, + "minimum": 15, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link lifetime in minutes (15–43200). Default: 15 min." +} - added
Input schema / properties / nameAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional name for the new document or document group (used only when entity_type is template or template_group)" +} - changed
Output schema / descriptionPrevious value: -"Response model for creating embedded editor."New value: +"Response model for creating embedded editor.\n\nWhen the editor is created for a template-originated entity, the created_entity_*\nfields are populated. For direct document/document_group calls they are None." - added
Output schema / properties / created_entity_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "ID of the entity created from template (None when entity was document/document_group)" +} - added
Output schema / properties / created_entity_nameAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Name of the entity created from template (None when entity was document/document_group)" +} - added
Output schema / properties / created_entity_typeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Type of created entity: 'document' or 'document_group' (None when entity was document/document_group)" +}
- Changed
create_embedded_editor_from_template8 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'template' or 'template_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type."New value: +"Type of entity: 'template' or 'template_group' (optional, auto-detected if not provided)." - changed
Input schema / properties / link_expiration / anyOfPrevious value: -[ - { - "maximum": 43200, - "minimum": 15, - "type": "integer" - }, - { - "type": "null" - } -]New value: +[ + { + "maximum": 45, + "minimum": 15, + "type": "integer" + }, + { + "type": "null" + } +] - changed
Input schema / properties / link_expiration / descriptionPrevious value: -"Optional link expiration in minutes (15-43200)"New value: +"Link expiration in minutes (15–45)" - changed
Input schema / properties / name / descriptionPrevious value: -"Name for the new document or document group"New value: +"Optional name for the new document or document group" - changed
Input schema / properties / redirect_target / descriptionPrevious value: -"Optional redirect target: 'self' (default), 'blank'"New value: +"Optional redirect target" - removed
Output schema / properties / editor_idRemoved value: -{ - "description": "ID of the created embedded editor", - "type": "string" -} - changed
Output schema / requiredPrevious value: -[ - "created_entity_id", - "created_entity_type", - "created_entity_name", - "editor_id", - "editor_entity", - "editor_url" -]New value: +[ + "created_entity_id", + "created_entity_type", + "created_entity_name", + "editor_entity", + "editor_url" +]
- Changed
create_embedded_invite21 fields changed- removed
Input schema / $defsRemoved value: -{ - "EmbeddedInviteOrder": { - "description": "Order information for embedded invite.", - "properties": { - "order": { - "description": "Order number for this step", - "type": "integer" - }, - "recipients": { - "description": "List of recipients for this order", - "items": { - "$ref": "#/$defs/EmbeddedInviteRecipient" - }, - "type": "array" - } - }, - "required": [ - "order", - "recipients" - ], - "type": "object" - }, - "EmbeddedInviteRecipient": { - "description": "Recipient information for embedded invite.", - "properties": { - "action": { - "default": "sign", - "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", - "type": "string" - }, - "auth_method": { - "default": "none", - "description": "Authentication method in integrated app: 'password', 'email', 'mfa', 'biometric', 'social', 'other', 'none'", - "type": "string" - }, - "close_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens when clicking 'Close' button" - }, - "decline_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "URL that opens after decline" - }, - "delivery_type": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "link", - "description": "Invite delivery method: 'email' or 'link', use 'link' if you wand to get a link to sign. If you want to send an email, use 'email'" - }, - "email": { - "description": "Recipient's email address", - "type": "string" - }, - "first_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Recipient's first name" - }, - "last_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Recipient's last name" - }, - "message": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite email message (max 5000 chars)" - }, - "redirect_target": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "self", - "description": "Redirect target: 'blank' for new tab, 'self' for same tab" - }, - "redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens after completion" - }, - "role": { - "description": "Recipient's role name in the document", - "type": "string" - }, - "subject": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite email subject (max 1000 chars)" - } - }, - "required": [ - "email", - "role" - ], - "type": "object" - } -} - added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / entity_id / descriptionPrevious value: -"ID of the document or document group"New value: +"ID of the document, document group, template, or template group" - changed
Input schema / properties / entity_type / anyOfPrevious value: -[ - { - "enum": [ - "document", - "document_group" - ], - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "enum": [ + "document", + "document_group", + "template", + "template_group" + ], + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'document' or 'document_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type."New value: +"Type of entity: 'document', 'document_group', 'template', or 'template_group' (optional). Auto-detected if not provided." - added
Input schema / properties / nameAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional name for the new document or document group (used only when entity_type is template or template_group)" +} - removed
Input schema / properties / orders / anyOfRemoved value: -[ - { - "items": { - "$ref": "#/$defs/EmbeddedInviteOrder" - }, - "type": "array" - }, - { - "type": "string" - }, - { - "type": "null" - } -] - removed
Input schema / properties / orders / defaultRemoved value: -null - changed
Input schema / properties / orders / descriptionPrevious value: -"List of orders with recipients (can be a list or JSON string)"New value: +"List of orders with recipients." - changed
Input schema / properties / orders / examplesPrevious value: -[ - [ - { - "order": 1, - "recipients": [ - { - "action": "sign", - "auth_method": "none", - "email": "user@example.com", - "role": "Signer 1" - } - ] - } - ], - "[{\"order\": 1, \"recipients\": [{\"email\": \"user@example.com\", \"role\": \"Signer 1\", \"action\": \"sign\", \"auth_method\": \"none\"}]}]" -]New value: +[ + [ + { + "order": 1, + "recipients": [ + { + "action": "sign", + "auth_method": "none", + "email": "user@example.com", + "role": "Signer 1" + } + ] + } + ] +] - added
Input schema / properties / orders / itemsAdded value: +{ + "description": "Order information for embedded invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "description": "Recipient information for embedded invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "type": "string" + }, + "auth_method": { + "default": "none", + "description": "Authentication method in integrated app: 'password', 'email', 'mfa', 'biometric', 'social', 'other', 'none'", + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "delivery_type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "link", + "description": "Invite delivery method: 'email' or 'link', use 'link' if you wand to get a link to sign. If you want to send an email, use 'email'" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "first_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's first name" + }, + "last_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's last name" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email message (max 5000 chars)" + }, + "redirect_target": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "self", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email subject (max 1000 chars)" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" +} - added
Input schema / properties / orders / typeAdded value: +"array" - changed
Input schema / requiredPrevious value: -[ - "entity_id" -]New value: +[ + "entity_id", + "orders" +] - changed
Output schema / descriptionPrevious value: -"Response model for creating embedded invite."New value: +"Response model for creating embedded invite.\n\nWhen the invite is created for a template-originated entity, the created_entity_*\nfields are populated. For direct document/document_group calls they are None." - added
Output schema / properties / created_entity_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "ID of the entity created from template (None when entity was document/document_group)" +} - added
Output schema / properties / created_entity_nameAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Name of the entity created from template (None when entity was document/document_group)" +} - added
Output schema / properties / created_entity_typeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Type of created entity: 'document' or 'document_group' (None when entity was document/document_group)" +} - added
Output schema / properties / document_group_invite_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "ID of the created document group embedded invite; populated only when invite_entity is 'document_group', otherwise None" +} - removed
Output schema / properties / invite_idRemoved value: -{ - "description": "ID of the created embedded invite", - "type": "string" -} - changed
Output schema / properties / recipient_links / descriptionPrevious value: -"Array of objects with role and link for recipients with delivery_type='link'"New value: +"Array of objects with role, invite id (for document invite) and link for recipients with delivery_type='link'" - changed
Output schema / requiredPrevious value: -[ - "invite_id", - "invite_entity", - "recipient_links" -]New value: +[ + "invite_entity", + "recipient_links" +]
- Changed
create_embedded_invite_from_template5 fields changed- removed
Input schema / $defsRemoved value: -{ - "EmbeddedInviteOrder": { - "description": "Order information for embedded invite.", - "properties": { - "order": { - "description": "Order number for this step", - "type": "integer" - }, - "recipients": { - "description": "List of recipients for this order", - "items": { - "$ref": "#/$defs/EmbeddedInviteRecipient" - }, - "type": "array" - } - }, - "required": [ - "order", - "recipients" - ], - "type": "object" - }, - "EmbeddedInviteRecipient": { - "description": "Recipient information for embedded invite.", - "properties": { - "action": { - "default": "sign", - "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", - "type": "string" - }, - "auth_method": { - "default": "none", - "description": "Authentication method in integrated app: 'password', 'email', 'mfa', 'biometric', 'social', 'other', 'none'", - "type": "string" - }, - "close_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens when clicking 'Close' button" - }, - "decline_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "URL that opens after decline" - }, - "delivery_type": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "link", - "description": "Invite delivery method: 'email' or 'link', use 'link' if you wand to get a link to sign. If you want to send an email, use 'email'" - }, - "email": { - "description": "Recipient's email address", - "type": "string" - }, - "first_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Recipient's first name" - }, - "last_name": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Recipient's last name" - }, - "message": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite email message (max 5000 chars)" - }, - "redirect_target": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "self", - "description": "Redirect target: 'blank' for new tab, 'self' for same tab" - }, - "redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens after completion" - }, - "role": { - "description": "Recipient's role name in the document", - "type": "string" - }, - "subject": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite email subject (max 1000 chars)" - } - }, - "required": [ - "email", - "role" - ], - "type": "object" - } -} - added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'template' or 'template_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type."New value: +"Type of entity: 'template' or 'template_group' (optional, auto-detected if not provided)." - changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "$ref": "#/$defs/EmbeddedInviteOrder" - }, - "type": "array" - }, - { - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "items": { + "description": "Order information for embedded invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "description": "Recipient information for embedded invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "type": "string" + }, + "auth_method": { + "default": "none", + "description": "Authentication method in integrated app: 'password', 'email', 'mfa', 'biometric', 'social', 'other', 'none'", + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "delivery_type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "link", + "description": "Invite delivery method: 'email' or 'link', use 'link' if you wand to get a link to sign. If you want to send an email, use 'email'" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "first_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's first name" + }, + "last_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's last name" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email message (max 5000 chars)" + }, + "redirect_target": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "self", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email subject (max 1000 chars)" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "string" + }, + { + "type": "null" + } +] - removed
Input schema / properties / orders / examplesRemoved value: -[ - [ - { - "order": 1, - "recipients": [ - { - "action": "sign", - "auth_method": "none", - "email": "user@example.com", - "role": "Signer 1" - } - ] - } - ], - "[{\"order\": 1, \"recipients\": [{\"email\": \"user@example.com\", \"role\": \"Signer 1\", \"action\": \"sign\", \"auth_method\": \"none\"}]}]" -]
- Changed
create_embedded_sending11 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / entity_id / descriptionPrevious value: -"ID of the document or document group"New value: +"ID of the document, document group, template, or template group" - changed
Input schema / properties / entity_type / anyOfPrevious value: -[ - { - "enum": [ - "document", - "document_group" - ], - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "enum": [ + "document", + "document_group", + "template", + "template_group" + ], + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'document' or 'document_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type."New value: +"Type of entity: 'document', 'document_group', 'template', or 'template_group' (optional). Auto-detected if not provided." - removed
Input schema / properties / link_expirationRemoved value: -{ - "anyOf": [ - { - "maximum": 45, - "minimum": 14, - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Optional link expiration in days (14-45)" -} - added
Input schema / properties / link_expiration_minutesAdded value: +{ + "anyOf": [ + { + "maximum": 45, + "minimum": 15, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link lifetime in minutes (15–45). Default: 15 min." +} - added
Input schema / properties / nameAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional name for the new document or document group (used only when entity_type is template or template_group)" +} - changed
Output schema / descriptionPrevious value: -"Response model for creating embedded sending."New value: +"Response model for creating embedded sending.\n\nWhen the sending is created for a template-originated entity, the created_entity_*\nfields are populated. For direct document/document_group calls they are None." - added
Output schema / properties / created_entity_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "ID of the entity created from template (None when entity was document/document_group)" +} - added
Output schema / properties / created_entity_nameAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Name of the entity created from template (None when entity was document/document_group)" +} - added
Output schema / properties / created_entity_typeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Type of created entity: 'document' or 'document_group' (None when entity was document/document_group)" +}
- Changed
create_embedded_sending_from_template8 fields changed- added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'template' or 'template_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type."New value: +"Type of entity: 'template' or 'template_group' (optional, auto-detected if not provided)." - changed
Input schema / properties / link_expiration / anyOfPrevious value: -[ - { - "maximum": 45, - "minimum": 14, - "type": "integer" - }, - { - "type": "null" - } -]New value: +[ + { + "maximum": 45, + "minimum": 15, + "type": "integer" + }, + { + "type": "null" + } +] - changed
Input schema / properties / link_expiration / descriptionPrevious value: -"Optional link expiration in days (14-45)"New value: +"Link expiration in minutes (15–45)" - changed
Input schema / properties / redirect_target / descriptionPrevious value: -"Optional redirect target: 'self' (default), 'blank'"New value: +"Optional redirect target" - changed
Input schema / properties / type / defaultPrevious value: -nullNew value: +"manage" - removed
Output schema / properties / sending_idRemoved value: -{ - "description": "ID of the created embedded sending", - "type": "string" -} - changed
Output schema / requiredPrevious value: -[ - "created_entity_id", - "created_entity_type", - "created_entity_name", - "sending_id", - "sending_entity", - "sending_url" -]New value: +[ + "created_entity_id", + "created_entity_type", + "created_entity_name", + "sending_entity", + "sending_url" +]
- Changed
create_from_template2 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Output schema / properties / entity_type / enumAdded value: +[ + "document", + "document_group" +]
- Added
create_template - Changed
get_document11 fields changed- added
Input schema / additionalPropertiesAdded value: +false - removed
Output schema / $defsRemoved value: -{ - "DocumentField": { - "description": "Document field information.", - "properties": { - "id": { - "description": "Field ID", - "type": "string" - }, - "name": { - "description": "Field name", - "type": "string" - }, - "role_id": { - "description": "Role ID associated with this field", - "type": "string" - }, - "type": { - "description": "Field type", - "type": "string" - }, - "value": { - "description": "Field value", - "type": "string" - } - }, - "required": [ - "id", - "type", - "role_id", - "value", - "name" - ], - "type": "object" - }, - "DocumentGroupDocument": { - "description": "Document information for MCP tools.", - "properties": { - "fields": { - "default": [], - "description": "Fields defined in this document", - "items": { - "$ref": "#/$defs/DocumentField" - }, - "type": "array" - }, - "id": { - "description": "Document ID", - "type": "string" - }, - "name": { - "description": "Document name", - "type": "string" - }, - "roles": { - "description": "Roles defined for this document", - "items": { - "type": "string" - }, - "type": "array" - } - }, - "required": [ - "id", - "name", - "roles" - ], - "type": "object" - } -} - removed
Output schema / properties / documents / items / $refRemoved value: -"#/$defs/DocumentGroupDocument" - added
Output schema / properties / documents / items / descriptionAdded value: +"Document information for MCP tools." - added
Output schema / properties / documents / items / propertiesAdded value: +{ + "fields": { + "default": [], + "description": "Fields defined in this document", + "items": { + "description": "Document field information.", + "properties": { + "id": { + "description": "Field ID", + "type": "string" + }, + "name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Field name (may be absent for unnamed fields)" + }, + "role_id": { + "description": "Role ID associated with this field", + "type": "string" + }, + "type": { + "description": "Field type", + "type": "string" + }, + "value": { + "description": "Field value", + "type": "string" + } + }, + "required": [ + "id", + "type", + "role_id", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "id": { + "description": "Document ID", + "type": "string" + }, + "name": { + "description": "Document name", + "type": "string" + }, + "roles": { + "description": "Roles defined for this document", + "items": { + "type": "string" + }, + "type": "array" + } +} - added
Output schema / properties / documents / items / requiredAdded value: +[ + "id", + "name", + "roles" +] - added
Output schema / properties / documents / items / typeAdded value: +"object" - added
Output schema / properties / freeform_invite_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Freeform invite ID, if a freeform invite exists on this entity" +} - added
Output schema / properties / inviteAdded value: +{ + "anyOf": [ + { + "properties": { + "expired": { + "default": false, + "description": "Is invite expired", + "type": "boolean" + }, + "expires_at": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Unified invite expiration timestamp" + }, + "invite_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite ID if present" + }, + "participants": { + "items": { + "properties": { + "action": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Action (for document-group invites)" + }, + "created": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Unix created timestamp" + }, + "email": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Participant email" + }, + "expired": { + "default": false, + "description": "Is this participant expired", + "type": "boolean" + }, + "expires_at": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Unix expiration timestamp" + }, + "order": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Signing order if present" + }, + "role": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Role (for document field_invites)" + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Raw participant status from API" + }, + "updated": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Unix updated timestamp" + } + }, + "type": "object" + }, + "type": "array" + }, + "status": { + "default": "unknown", + "description": "Unified invite status. Values: pending (awaiting actions), created (created but not sent), completed (all actions done), declined (someone declined), expired (invite deadline passed), unknown (status could not be determined).", + "type": "string" + }, + "status_raw": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Raw group-level invite status as returned by SignNow. Possible values depend on SignNow API (examples seen here: created, new, sent, pending, waiting, fulfilled, signed, completed, done, declined, rejected, canceled, cancelled, expired). created means the document was created but not sent." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Unified invite info" +} - removed
Output schema / properties / invite_idRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Invite ID for this group" -} - removed
Output schema / properties / invite_statusRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Status of the invite (e.g., 'pending')" -}
- Changed
get_document_download_link1 field changed- added
Input schema / additionalPropertiesAdded value: +false
- Changed
get_invite_status8 fields changed- added
Input schema / additionalPropertiesAdded value: +false - removed
Output schema / $defsRemoved value: -{ - "DocumentGroupStatusAction": { - "description": "Action status within a document group invite step.", - "properties": { - "action": { - "description": "Action type: 'view', 'sign', 'approve'", - "type": "string" - }, - "document_id": { - "description": "ID of the document", - "type": "string" - }, - "email": { - "description": "Recipient's email address", - "type": "string" - }, - "role": { - "description": "Role name for this action", - "type": "string" - }, - "status": { - "description": "Action status: 'created', 'pending', 'fulfilled'", - "type": "string" - } - }, - "required": [ - "action", - "email", - "document_id", - "status", - "role" - ], - "type": "object" - }, - "DocumentGroupStatusStep": { - "description": "Step status within a document group invite.", - "properties": { - "actions": { - "description": "List of actions in this step", - "items": { - "$ref": "#/$defs/DocumentGroupStatusAction" - }, - "type": "array" - }, - "order": { - "description": "Step order number", - "type": "integer" - }, - "status": { - "description": "Step status: 'created', 'pending', 'fulfilled'", - "type": "string" - } - }, - "required": [ - "status", - "order", - "actions" - ], - "type": "object" - } -} - added
Output schema / properties / invite_modeAdded value: +{ + "default": "field", + "description": "field = role/field invite path; freeform = mapped from free-form or group documents list", + "enum": [ + "field", + "freeform" + ], + "type": "string" +} - removed
Output schema / properties / steps / items / $refRemoved value: -"#/$defs/DocumentGroupStatusStep" - added
Output schema / properties / steps / items / descriptionAdded value: +"Step status within a document group invite." - added
Output schema / properties / steps / items / propertiesAdded value: +{ + "actions": { + "description": "List of actions in this step", + "items": { + "description": "Action status within a document group invite step.", + "properties": { + "action": { + "description": "Action type: 'view', 'sign', 'approve'", + "type": "string" + }, + "document_id": { + "description": "ID of the document", + "type": "string" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "role": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Role name for field invites; None for freeform invites" + }, + "status": { + "description": "Action status: 'created', 'pending', 'fulfilled'", + "type": "string" + } + }, + "required": [ + "action", + "email", + "document_id", + "status" + ], + "type": "object" + }, + "type": "array" + }, + "order": { + "description": "Step order number", + "type": "integer" + }, + "status": { + "description": "Step status: 'created', 'pending', 'fulfilled'", + "type": "string" + } +} - added
Output schema / properties / steps / items / requiredAdded value: +[ + "status", + "order", + "actions" +] - added
Output schema / properties / steps / items / typeAdded value: +"object"
- Added
get_signing_link - Changed
list_all_templates14 fields changed- added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / limitAdded value: +{ + "default": 50, + "description": "Maximum number of items to return (1-100, default 50)", + "maximum": 100, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Number of items to skip for pagination (default 0)", + "minimum": 0, + "type": "integer" +} - removed
Output schema / $defsRemoved value: -{ - "TemplateSummary": { - "description": "Simplified template information for listing.", - "properties": { - "entity_type": { - "description": "Type of entity: 'template' or 'template_group'", - "type": "string" - }, - "folder_id": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Folder ID if stored in folder" - }, - "id": { - "description": "Template group ID", - "type": "string" - }, - "is_prepared": { - "description": "Whether the group is ready for sending", - "type": "boolean" - }, - "last_updated": { - "description": "Unix timestamp of last update", - "type": "integer" - }, - "name": { - "description": "Template group name", - "type": "string" - }, - "roles": { - "description": "All unique roles from all templates in the group", - "items": { - "type": "string" - }, - "type": "array" - } - }, - "required": [ - "id", - "name", - "entity_type", - "last_updated", - "is_prepared", - "roles" - ], - "type": "object" - } -} - changed
Output schema / descriptionPrevious value: -"List of simplified template summaries."New value: +"List of simplified template summaries with pagination." - added
Output schema / properties / has_moreAdded value: +{ + "default": false, + "description": "Whether more items exist beyond this page", + "type": "boolean" +} - added
Output schema / properties / limitAdded value: +{ + "default": 50, + "description": "Maximum number of items in this page", + "type": "integer" +} - added
Output schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Number of items skipped", + "type": "integer" +} - removed
Output schema / properties / templates / items / $refRemoved value: -"#/$defs/TemplateSummary" - added
Output schema / properties / templates / items / descriptionAdded value: +"Simplified template information for listing." - added
Output schema / properties / templates / items / propertiesAdded value: +{ + "entity_type": { + "description": "Type of entity: 'template' or 'template_group'", + "type": "string" + }, + "folder_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Folder ID if stored in folder" + }, + "id": { + "description": "Template group ID", + "type": "string" + }, + "is_prepared": { + "description": "Whether the group is ready for sending", + "type": "boolean" + }, + "last_updated": { + "description": "Unix timestamp of last update", + "type": "integer" + }, + "name": { + "description": "Template group name", + "type": "string" + }, + "roles": { + "description": "All unique roles from all templates in the group", + "items": { + "type": "string" + }, + "type": "array" + } +} - added
Output schema / properties / templates / items / requiredAdded value: +[ + "id", + "name", + "entity_type", + "last_updated", + "is_prepared", + "roles" +] - added
Output schema / properties / templates / items / typeAdded value: +"object" - changed
Output schema / properties / total_count / descriptionPrevious value: -"Total number of templates"New value: +"Total number of templates across all pages"
- Added
list_contacts - Removed
list_document_groups - Added
list_documents - Added
rename_entity - Changed
send_invite16 fields changed- removed
Input schema / $defsRemoved value: -{ - "InviteOrder": { - "description": "Order information for invite.", - "properties": { - "order": { - "description": "Order number for this step", - "type": "integer" - }, - "recipients": { - "description": "List of recipients for this order", - "items": { - "$ref": "#/$defs/InviteRecipient" - }, - "type": "array" - } - }, - "required": [ - "order", - "recipients" - ], - "type": "object" - }, - "InviteRecipient": { - "description": "Recipient information for invite.", - "properties": { - "action": { - "default": "sign", - "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", - "type": "string" - }, - "close_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens when clicking 'Close' button" - }, - "decline_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "URL that opens after decline" - }, - "email": { - "description": "Recipient's email address", - "type": "string" - }, - "message": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Custom email message for the recipient" - }, - "redirect_target": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "blank", - "description": "Redirect target: 'blank' for new tab, 'self' for same tab" - }, - "redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens after completion" - }, - "role": { - "description": "Recipient's role name in the document", - "type": "string" - }, - "subject": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Custom email subject for the recipient" - } - }, - "required": [ - "email", - "role" - ], - "type": "object" - } -} - added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / entity_id / descriptionPrevious value: -"ID of the document or document group"New value: +"ID of the document, document group, template, or template group" - changed
Input schema / properties / entity_type / anyOfPrevious value: -[ - { - "enum": [ - "document", - "document_group" - ], - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "enum": [ + "document", + "document_group", + "template", + "template_group" + ], + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'document' or 'document_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type."New value: +"Type of entity: 'document', 'document_group', 'template', or 'template_group' (optional). Auto-detected if not provided." - added
Input schema / properties / nameAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional name for the new document or document group (used only when entity_type is template or template_group)" +} - changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "$ref": "#/$defs/InviteOrder" - }, - "type": "array" - }, - { - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "items": { + "description": "Order information for invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "description": "Recipient information for invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "type": "string" + }, + "authentication": { + "anyOf": [ + { + "description": "Optional signer identity verification settings.\n\nUse ONLY when the user explicitly requests authentication for a signer.\nDo NOT proactively suggest or apply this. Omitting it sends the invite\nwith no authentication (the default SignNow behaviour).", + "properties": { + "method": { + "anyOf": [ + { + "enum": [ + "sms", + "phone_call" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Delivery method for the one-time code. Used only when type='phone'. Defaults to 'sms' on the SignNow backend when not specified. Omit for password auth — this field has no effect in that context." + }, + "password": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Secret phrase the signer must enter. Required when type='password'." + }, + "phone": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Signer's phone number (E.164 recommended). Required when type='phone'." + }, + "sms_message": { + "anyOf": [ + { + "maxLength": 140, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom SMS message body (max 140 chars). Use '{password}' placeholder where the code should be inserted. Used only when type='phone' and method='sms'." + }, + "type": { + "description": "Authentication method: 'password' — signer must enter a pre-set secret phrase; 'phone' — signer receives a one-time code via SMS or phone call.", + "enum": [ + "password", + "phone" + ], + "type": "string" + } + }, + "required": [ + "type" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional signer identity verification. ONLY set this when the user explicitly asks for authentication. Leave as None (the default) to send invites without any verification — this is the standard behaviour and must not be changed unless asked." + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "expiration_days": { + "anyOf": [ + { + "maximum": 180, + "minimum": 3, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Number of days until the invite expires (3–180). When omitted (None), this value is explicitly passed as None to the API model, overriding its Field(30) default, so SignNow uses the account-configured expiration instead." + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom email message for the recipient" + }, + "redirect_target": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "blank", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "reminder": { + "anyOf": [ + { + "description": "Reminder schedule for signing invites.\n\nAll fields are optional — set only the ones you need.\nremind_after and remind_before must be less than expiration_days.", + "properties": { + "remind_after": { + "anyOf": [ + { + "maximum": 179, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Send a reminder X days after the invite is sent (1–179). Must be less than expiration_days." + }, + "remind_before": { + "anyOf": [ + { + "maximum": 179, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Send a reminder X days before the invite expires (1–179). Must be less than expiration_days." + }, + "remind_repeat": { + "anyOf": [ + { + "maximum": 7, + "minimum": 1, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Send a reminder every X days after the invite is sent (1–7)." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Automatic reminder email schedule. Reminders are sent by SignNow after the invite is created." + }, + "role": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's role name in the document. Required for field invites (documents with roles/fields). Omit for freeform invites (documents without fields) — the tool auto-detects document type and sends a freeform invite automatically." + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom email subject for the recipient" + } + }, + "required": [ + "email" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } +] - changed
Input schema / properties / orders / descriptionPrevious value: -"List of orders with recipients (can be a list or JSON string)"New value: +"List of orders with recipients. Required unless self_sign=True. When self_sign=True, omit orders — the tool fills in the current user as the sole recipient." - changed
Input schema / properties / orders / examplesPrevious value: -[ - [ - { - "order": 1, - "recipients": [ - { - "action": "sign", - "email": "user@example.com", - "role": "Signer 1" - } - ] - } - ], - "[{\"order\": 1, \"recipients\": [{\"email\": \"user@example.com\", \"role\": \"Signer 1\", \"action\": \"sign\"}]}]" -]New value: +[ + [ + { + "order": 1, + "recipients": [ + { + "action": "sign", + "email": "user@example.com", + "role": "Signer 1" + } + ] + } + ], + [ + { + "order": 1, + "recipients": [ + { + "action": "sign", + "email": "signer@example.com" + } + ] + } + ] +] - added
Input schema / properties / preview_was_shownAdded value: +{ + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "default": null, + "description": "This flag signals that the user has viewed the document preview. Prompt the user to view the document before submitting. If the user says yes, call view_document first, show the result, then call send_invite again with preview_was_shown=True. If the user says no, call send_invite with preview_was_shown=False." +} - added
Input schema / properties / self_signAdded value: +{ + "default": false, + "description": "If True, the tool resolves the current user's primary email server-side and sends a freeform invite to the user themselves. The response's 'link' field is populated with a direct signing link. Must be combined with an empty/omitted orders. Requires a field-less document or document group — for entities with fields/roles, use create_embedded_sending instead.", + "type": "boolean" +} - changed
Output schema / descriptionPrevious value: -"Response model for sending invite."New value: +"Response model for sending invite.\n\nWhen the invite is sent for a template-originated entity, the created_entity_*\nfields are populated. For direct document/document_group calls they are None." - added
Output schema / properties / created_entity_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "ID of the entity created from template (None when entity was document/document_group)" +} - added
Output schema / properties / created_entity_nameAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Name of the entity created from template (None when entity was document/document_group)" +} - added
Output schema / properties / created_entity_typeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Type of created entity: 'document' or 'document_group' (None when entity was document/document_group)" +} - added
Output schema / properties / linkAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Direct signing link. Populated only when the sender and recipient resolve to the same email (self_sign=True, or the recipient email equals the authenticated user's primary email). None for normal outbound invites." +}
- Changed
send_invite_from_template5 fields changed- removed
Input schema / $defsRemoved value: -{ - "InviteOrder": { - "description": "Order information for invite.", - "properties": { - "order": { - "description": "Order number for this step", - "type": "integer" - }, - "recipients": { - "description": "List of recipients for this order", - "items": { - "$ref": "#/$defs/InviteRecipient" - }, - "type": "array" - } - }, - "required": [ - "order", - "recipients" - ], - "type": "object" - }, - "InviteRecipient": { - "description": "Recipient information for invite.", - "properties": { - "action": { - "default": "sign", - "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", - "type": "string" - }, - "close_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens when clicking 'Close' button" - }, - "decline_redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "URL that opens after decline" - }, - "email": { - "description": "Recipient's email address", - "type": "string" - }, - "message": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Custom email message for the recipient" - }, - "redirect_target": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": "blank", - "description": "Redirect target: 'blank' for new tab, 'self' for same tab" - }, - "redirect_uri": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Link that opens after completion" - }, - "role": { - "description": "Recipient's role name in the document", - "type": "string" - }, - "subject": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Custom email subject for the recipient" - } - }, - "required": [ - "email", - "role" - ], - "type": "object" - } -} - added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'template' or 'template_group' (optional). If you're passing it, make sure you know what type you have. If it's not found, try using a different type."New value: +"Type of entity: 'template' or 'template_group' (optional, auto-detected if not provided)." - changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "$ref": "#/$defs/InviteOrder" - }, - "type": "array" - }, - { - "type": "string" - } -]New value: +[ + { + "items": { + "description": "v1.0.1 invite order with v1 recipients (no v2-only fields).", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "description": "v1.0.1 invite recipient — no reminder/expiration_days/authentication fields.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom email message for the recipient" + }, + "redirect_target": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "blank", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom email subject for the recipient" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "string" + } +] - removed
Input schema / properties / orders / examplesRemoved value: -[ - [ - { - "order": 1, - "recipients": [ - { - "action": "sign", - "email": "user@example.com", - "role": "Signer 1" - } - ] - } - ], - "[{\"order\": 1, \"recipients\": [{\"email\": \"user@example.com\", \"role\": \"Signer 1\", \"action\": \"sign\"}]}]" -]
- Added
send_invite_reminder - Added
signnow_skills - Changed
update_document_fields13 fields changed- removed
Input schema / $defsRemoved value: -{ - "FieldToUpdate": { - "description": "Single field to update in a document.", - "properties": { - "name": { - "description": "Name of the field to update", - "type": "string" - }, - "value": { - "description": "New value for the field", - "type": "string" - } - }, - "required": [ - "name", - "value" - ], - "type": "object" - }, - "UpdateDocumentFields": { - "description": "Request model for updating document fields.", - "properties": { - "document_id": { - "description": "ID of the document to update", - "type": "string" - }, - "fields": { - "description": "Array of fields to update with their new values", - "items": { - "$ref": "#/$defs/FieldToUpdate" - }, - "type": "array" - } - }, - "required": [ - "document_id", - "fields" - ], - "type": "object" - } -} - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / update_requests / items / $refRemoved value: -"#/$defs/UpdateDocumentFields" - added
Input schema / properties / update_requests / items / descriptionAdded value: +"Request model for updating document fields." - added
Input schema / properties / update_requests / items / propertiesAdded value: +{ + "document_id": { + "description": "ID of the document to update", + "type": "string" + }, + "fields": { + "description": "Array of fields to update with their new values", + "items": { + "description": "Single field to update in a document.", + "properties": { + "name": { + "description": "Name of the field to update", + "type": "string" + }, + "value": { + "description": "New value for the field", + "type": "string" + } + }, + "required": [ + "name", + "value" + ], + "type": "object" + }, + "type": "array" + } +} - added
Input schema / properties / update_requests / items / requiredAdded value: +[ + "document_id", + "fields" +] - added
Input schema / properties / update_requests / items / typeAdded value: +"object" - removed
Output schema / $defsRemoved value: -{ - "UpdateDocumentFieldsResult": { - "description": "Result of updating document fields.", - "properties": { - "document_id": { - "description": "ID of the document that was updated", - "type": "string" - }, - "reason": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Reason for failure if updated is false" - }, - "updated": { - "description": "Whether the document fields were successfully updated", - "type": "boolean" - } - }, - "required": [ - "document_id", - "updated" - ], - "type": "object" - } -} - removed
Output schema / properties / results / items / $refRemoved value: -"#/$defs/UpdateDocumentFieldsResult" - added
Output schema / properties / results / items / descriptionAdded value: +"Result of updating document fields." - added
Output schema / properties / results / items / propertiesAdded value: +{ + "document_id": { + "description": "ID of the document that was updated", + "type": "string" + }, + "reason": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Reason for failure if updated is false" + }, + "updated": { + "description": "Whether the document fields were successfully updated", + "type": "boolean" + } +} - added
Output schema / properties / results / items / requiredAdded value: +[ + "document_id", + "updated" +] - added
Output schema / properties / results / items / typeAdded value: +"object"
- Added
update_invite_recipient - Added
upload_document - Added
view_document
15 tool updates
v1.0.0- Changed
create_embedded_editor8 fields changed- removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Input schema / properties / link_expiration / titleRemoved value: -"Link Expiration" - removed
Input schema / properties / redirect_target / titleRemoved value: -"Redirect Target" - removed
Input schema / properties / redirect_uri / titleRemoved value: -"Redirect Uri" - removed
Output schema / properties / editor_entity / titleRemoved value: -"Editor Entity" - removed
Output schema / properties / editor_url / titleRemoved value: -"Editor Url" - removed
Output schema / titleRemoved value: -"CreateEmbeddedEditorResponse"
- Changed
create_embedded_editor_from_template13 fields changed- removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Input schema / properties / link_expiration / titleRemoved value: -"Link Expiration" - removed
Input schema / properties / name / titleRemoved value: -"Name" - removed
Input schema / properties / redirect_target / titleRemoved value: -"Redirect Target" - removed
Input schema / properties / redirect_uri / titleRemoved value: -"Redirect Uri" - removed
Output schema / properties / created_entity_id / titleRemoved value: -"Created Entity Id" - removed
Output schema / properties / created_entity_name / titleRemoved value: -"Created Entity Name" - removed
Output schema / properties / created_entity_type / titleRemoved value: -"Created Entity Type" - removed
Output schema / properties / editor_entity / titleRemoved value: -"Editor Entity" - removed
Output schema / properties / editor_id / titleRemoved value: -"Editor Id" - removed
Output schema / properties / editor_url / titleRemoved value: -"Editor Url" - removed
Output schema / titleRemoved value: -"CreateEmbeddedEditorFromTemplateResponse"
- Changed
create_embedded_invite11 fields changed- added
Input schema / $defsAdded value: +{ + "EmbeddedInviteOrder": { + "description": "Order information for embedded invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "$ref": "#/$defs/EmbeddedInviteRecipient" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "EmbeddedInviteRecipient": { + "description": "Recipient information for embedded invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "type": "string" + }, + "auth_method": { + "default": "none", + "description": "Authentication method in integrated app: 'password', 'email', 'mfa', 'biometric', 'social', 'other', 'none'", + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "delivery_type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "link", + "description": "Invite delivery method: 'email' or 'link', use 'link' if you wand to get a link to sign. If you want to send an email, use 'email'" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "first_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's first name" + }, + "last_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's last name" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email message (max 5000 chars)" + }, + "redirect_target": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "self", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email subject (max 1000 chars)" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + } +} - removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "$ref": "#/$defs/EmbeddedInviteOrder" - }, - "type": "array" - }, - { - "type": "null" - } -]New value: +[ + { + "items": { + "$ref": "#/$defs/EmbeddedInviteOrder" + }, + "type": "array" + }, + { + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / orders / descriptionPrevious value: -"List of orders with recipients"New value: +"List of orders with recipients (can be a list or JSON string)" - added
Input schema / properties / orders / examplesAdded value: +[ + [ + { + "order": 1, + "recipients": [ + { + "action": "sign", + "auth_method": "none", + "email": "user@example.com", + "role": "Signer 1" + } + ] + } + ], + "[{\"order\": 1, \"recipients\": [{\"email\": \"user@example.com\", \"role\": \"Signer 1\", \"action\": \"sign\", \"auth_method\": \"none\"}]}]" +] - removed
Input schema / properties / orders / titleRemoved value: -"Orders" - removed
Output schema / properties / invite_entity / titleRemoved value: -"Invite Entity" - removed
Output schema / properties / invite_id / titleRemoved value: -"Invite Id" - removed
Output schema / properties / recipient_links / titleRemoved value: -"Recipient Links" - removed
Output schema / titleRemoved value: -"CreateEmbeddedInviteResponse"
- Changed
create_embedded_invite_from_template15 fields changed- added
Input schema / $defsAdded value: +{ + "EmbeddedInviteOrder": { + "description": "Order information for embedded invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "$ref": "#/$defs/EmbeddedInviteRecipient" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "EmbeddedInviteRecipient": { + "description": "Recipient information for embedded invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "type": "string" + }, + "auth_method": { + "default": "none", + "description": "Authentication method in integrated app: 'password', 'email', 'mfa', 'biometric', 'social', 'other', 'none'", + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "delivery_type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "link", + "description": "Invite delivery method: 'email' or 'link', use 'link' if you wand to get a link to sign. If you want to send an email, use 'email'" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "first_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's first name" + }, + "last_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Recipient's last name" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email message (max 5000 chars)" + }, + "redirect_target": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "self", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Invite email subject (max 1000 chars)" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + } +} - removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Input schema / properties / name / titleRemoved value: -"Name" - changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "$ref": "#/$defs/EmbeddedInviteOrder" - }, - "type": "array" - }, - { - "type": "null" - } -]New value: +[ + { + "items": { + "$ref": "#/$defs/EmbeddedInviteOrder" + }, + "type": "array" + }, + { + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / orders / descriptionPrevious value: -"List of orders with recipients for the embedded invite"New value: +"List of orders with recipients for the embedded invite (can be a list or JSON string)" - added
Input schema / properties / orders / examplesAdded value: +[ + [ + { + "order": 1, + "recipients": [ + { + "action": "sign", + "auth_method": "none", + "email": "user@example.com", + "role": "Signer 1" + } + ] + } + ], + "[{\"order\": 1, \"recipients\": [{\"email\": \"user@example.com\", \"role\": \"Signer 1\", \"action\": \"sign\", \"auth_method\": \"none\"}]}]" +] - removed
Input schema / properties / orders / titleRemoved value: -"Orders" - removed
Output schema / properties / created_entity_id / titleRemoved value: -"Created Entity Id" - removed
Output schema / properties / created_entity_name / titleRemoved value: -"Created Entity Name" - removed
Output schema / properties / created_entity_type / titleRemoved value: -"Created Entity Type" - removed
Output schema / properties / invite_entity / titleRemoved value: -"Invite Entity" - removed
Output schema / properties / invite_id / titleRemoved value: -"Invite Id" - removed
Output schema / properties / recipient_links / titleRemoved value: -"Recipient Links" - removed
Output schema / titleRemoved value: -"CreateEmbeddedInviteFromTemplateResponse"
- Changed
create_embedded_sending9 fields changed- removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Input schema / properties / link_expiration / titleRemoved value: -"Link Expiration" - removed
Input schema / properties / redirect_target / titleRemoved value: -"Redirect Target" - removed
Input schema / properties / redirect_uri / titleRemoved value: -"Redirect Uri" - removed
Input schema / properties / type / titleRemoved value: -"Type" - removed
Output schema / properties / sending_entity / titleRemoved value: -"Sending Entity" - removed
Output schema / properties / sending_url / titleRemoved value: -"Sending Url" - removed
Output schema / titleRemoved value: -"CreateEmbeddedSendingResponse"
- Changed
create_embedded_sending_from_template14 fields changed- removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Input schema / properties / link_expiration / titleRemoved value: -"Link Expiration" - removed
Input schema / properties / name / titleRemoved value: -"Name" - removed
Input schema / properties / redirect_target / titleRemoved value: -"Redirect Target" - removed
Input schema / properties / redirect_uri / titleRemoved value: -"Redirect Uri" - removed
Input schema / properties / type / titleRemoved value: -"Type" - removed
Output schema / properties / created_entity_id / titleRemoved value: -"Created Entity Id" - removed
Output schema / properties / created_entity_name / titleRemoved value: -"Created Entity Name" - removed
Output schema / properties / created_entity_type / titleRemoved value: -"Created Entity Type" - removed
Output schema / properties / sending_entity / titleRemoved value: -"Sending Entity" - removed
Output schema / properties / sending_id / titleRemoved value: -"Sending Id" - removed
Output schema / properties / sending_url / titleRemoved value: -"Sending Url" - removed
Output schema / titleRemoved value: -"CreateEmbeddedSendingFromTemplateResponse"
- Changed
create_from_template7 fields changed- removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Input schema / properties / name / titleRemoved value: -"Name" - removed
Output schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Output schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Output schema / properties / name / titleRemoved value: -"Name" - removed
Output schema / titleRemoved value: -"CreateFromTemplateResponse"
- Changed
get_document24 fields changed- changed
Input schema / properties / entity_id / descriptionPrevious value: -"ID of the document or document group to retrieve"New value: +"ID of the document, template, template group or document group to retrieve" - removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - changed
Input schema / properties / entity_type / anyOfPrevious value: -[ - { - "enum": [ - "document", - "document_group" - ], - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "enum": [ + "document", + "document_group", + "template", + "template_group" + ], + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / entity_type / descriptionPrevious value: -"Type of entity: 'document' or 'document_group' (optional). If not provided, will be determined automatically"New value: +"Type of entity: 'document', 'template', 'template_group' or 'document_group' (optional). If not provided, will be determined automatically" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Output schema / $defs / DocumentField / properties / id / titleRemoved value: -"Id" - removed
Output schema / $defs / DocumentField / properties / name / titleRemoved value: -"Name" - removed
Output schema / $defs / DocumentField / properties / role_id / titleRemoved value: -"Role Id" - removed
Output schema / $defs / DocumentField / properties / type / titleRemoved value: -"Type" - removed
Output schema / $defs / DocumentField / properties / value / titleRemoved value: -"Value" - removed
Output schema / $defs / DocumentField / titleRemoved value: -"DocumentField" - removed
Output schema / $defs / DocumentGroupDocument / properties / fields / titleRemoved value: -"Fields" - removed
Output schema / $defs / DocumentGroupDocument / properties / id / titleRemoved value: -"Id" - removed
Output schema / $defs / DocumentGroupDocument / properties / name / titleRemoved value: -"Name" - removed
Output schema / $defs / DocumentGroupDocument / properties / roles / titleRemoved value: -"Roles" - removed
Output schema / $defs / DocumentGroupDocument / titleRemoved value: -"DocumentGroupDocument" - removed
Output schema / properties / documents / titleRemoved value: -"Documents" - removed
Output schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Output schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Output schema / properties / group_name / titleRemoved value: -"Group Name" - removed
Output schema / properties / invite_id / titleRemoved value: -"Invite Id" - removed
Output schema / properties / invite_status / titleRemoved value: -"Invite Status" - removed
Output schema / properties / last_updated / titleRemoved value: -"Last Updated" - removed
Output schema / titleRemoved value: -"DocumentGroup"
- Changed
get_document_download_link4 fields changed- removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Output schema / properties / link / titleRemoved value: -"Link" - removed
Output schema / titleRemoved value: -"DocumentDownloadLinkResponse"
- Changed
get_invite_status18 fields changed- removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Output schema / $defs / DocumentGroupStatusAction / properties / action / titleRemoved value: -"Action" - removed
Output schema / $defs / DocumentGroupStatusAction / properties / document_id / titleRemoved value: -"Document Id" - removed
Output schema / $defs / DocumentGroupStatusAction / properties / email / titleRemoved value: -"Email" - added
Output schema / $defs / DocumentGroupStatusAction / properties / roleAdded value: +{ + "description": "Role name for this action", + "type": "string" +} - removed
Output schema / $defs / DocumentGroupStatusAction / properties / role_nameRemoved value: -{ - "description": "Role name for this action", - "title": "Role Name", - "type": "string" -} - removed
Output schema / $defs / DocumentGroupStatusAction / properties / status / titleRemoved value: -"Status" - changed
Output schema / $defs / DocumentGroupStatusAction / requiredPrevious value: -[ - "action", - "email", - "document_id", - "status", - "role_name" -]New value: +[ + "action", + "email", + "document_id", + "status", + "role" +] - removed
Output schema / $defs / DocumentGroupStatusAction / titleRemoved value: -"DocumentGroupStatusAction" - removed
Output schema / $defs / DocumentGroupStatusStep / properties / actions / titleRemoved value: -"Actions" - removed
Output schema / $defs / DocumentGroupStatusStep / properties / order / titleRemoved value: -"Order" - removed
Output schema / $defs / DocumentGroupStatusStep / properties / status / titleRemoved value: -"Status" - removed
Output schema / $defs / DocumentGroupStatusStep / titleRemoved value: -"DocumentGroupStatusStep" - removed
Output schema / properties / invite_id / titleRemoved value: -"Invite Id" - removed
Output schema / properties / status / titleRemoved value: -"Status" - removed
Output schema / properties / steps / titleRemoved value: -"Steps" - removed
Output schema / titleRemoved value: -"InviteStatus"
- Changed
list_all_templates11 fields changed- removed
Output schema / $defs / TemplateSummary / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Output schema / $defs / TemplateSummary / properties / folder_id / titleRemoved value: -"Folder Id" - removed
Output schema / $defs / TemplateSummary / properties / id / titleRemoved value: -"Id" - removed
Output schema / $defs / TemplateSummary / properties / is_prepared / titleRemoved value: -"Is Prepared" - removed
Output schema / $defs / TemplateSummary / properties / last_updated / titleRemoved value: -"Last Updated" - removed
Output schema / $defs / TemplateSummary / properties / name / titleRemoved value: -"Name" - removed
Output schema / $defs / TemplateSummary / properties / roles / titleRemoved value: -"Roles" - removed
Output schema / $defs / TemplateSummary / titleRemoved value: -"TemplateSummary" - removed
Output schema / properties / templates / titleRemoved value: -"Templates" - removed
Output schema / properties / total_count / titleRemoved value: -"Total Count" - removed
Output schema / titleRemoved value: -"TemplateSummaryList"
- Changed
list_document_groups16 fields changed- removed
Input schema / properties / limit / titleRemoved value: -"Limit" - removed
Input schema / properties / offset / titleRemoved value: -"Offset" - removed
Output schema / $defs / SimplifiedDocumentGroup / properties / documents / titleRemoved value: -"Documents" - removed
Output schema / $defs / SimplifiedDocumentGroup / properties / group_id / titleRemoved value: -"Group Id" - removed
Output schema / $defs / SimplifiedDocumentGroup / properties / group_name / titleRemoved value: -"Group Name" - removed
Output schema / $defs / SimplifiedDocumentGroup / properties / invite_id / titleRemoved value: -"Invite Id" - removed
Output schema / $defs / SimplifiedDocumentGroup / properties / invite_status / titleRemoved value: -"Invite Status" - removed
Output schema / $defs / SimplifiedDocumentGroup / properties / last_updated / titleRemoved value: -"Last Updated" - removed
Output schema / $defs / SimplifiedDocumentGroup / titleRemoved value: -"SimplifiedDocumentGroup" - removed
Output schema / $defs / SimplifiedDocumentGroupDocument / properties / id / titleRemoved value: -"Id" - removed
Output schema / $defs / SimplifiedDocumentGroupDocument / properties / name / titleRemoved value: -"Name" - removed
Output schema / $defs / SimplifiedDocumentGroupDocument / properties / roles / titleRemoved value: -"Roles" - removed
Output schema / $defs / SimplifiedDocumentGroupDocument / titleRemoved value: -"SimplifiedDocumentGroupDocument" - removed
Output schema / properties / document_group_total_count / titleRemoved value: -"Document Group Total Count" - removed
Output schema / properties / document_groups / titleRemoved value: -"Document Groups" - removed
Output schema / titleRemoved value: -"SimplifiedDocumentGroupsResponse"
- Changed
send_invite10 fields changed- added
Input schema / $defsAdded value: +{ + "InviteOrder": { + "description": "Order information for invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "$ref": "#/$defs/InviteRecipient" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "InviteRecipient": { + "description": "Recipient information for invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom email message for the recipient" + }, + "redirect_target": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "blank", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom email subject for the recipient" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + } +} - removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "$ref": "#/$defs/InviteOrder" - }, - "type": "array" - }, - { - "type": "null" - } -]New value: +[ + { + "items": { + "$ref": "#/$defs/InviteOrder" + }, + "type": "array" + }, + { + "type": "string" + }, + { + "type": "null" + } +] - changed
Input schema / properties / orders / descriptionPrevious value: -"List of orders with recipients"New value: +"List of orders with recipients (can be a list or JSON string)" - added
Input schema / properties / orders / examplesAdded value: +[ + [ + { + "order": 1, + "recipients": [ + { + "action": "sign", + "email": "user@example.com", + "role": "Signer 1" + } + ] + } + ], + "[{\"order\": 1, \"recipients\": [{\"email\": \"user@example.com\", \"role\": \"Signer 1\", \"action\": \"sign\"}]}]" +] - removed
Input schema / properties / orders / titleRemoved value: -"Orders" - removed
Output schema / properties / invite_entity / titleRemoved value: -"Invite Entity" - removed
Output schema / properties / invite_id / titleRemoved value: -"Invite Id" - removed
Output schema / titleRemoved value: -"SendInviteResponse"
- Changed
send_invite_from_template16 fields changed- added
Input schema / $defsAdded value: +{ + "InviteOrder": { + "description": "Order information for invite.", + "properties": { + "order": { + "description": "Order number for this step", + "type": "integer" + }, + "recipients": { + "description": "List of recipients for this order", + "items": { + "$ref": "#/$defs/InviteRecipient" + }, + "type": "array" + } + }, + "required": [ + "order", + "recipients" + ], + "type": "object" + }, + "InviteRecipient": { + "description": "Recipient information for invite.", + "properties": { + "action": { + "default": "sign", + "description": "Allowed action with a document. Possible values: 'view', 'sign', 'approve'", + "type": "string" + }, + "close_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens when clicking 'Close' button" + }, + "decline_redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "URL that opens after decline" + }, + "email": { + "description": "Recipient's email address", + "type": "string" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom email message for the recipient" + }, + "redirect_target": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": "blank", + "description": "Redirect target: 'blank' for new tab, 'self' for same tab" + }, + "redirect_uri": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Link that opens after completion" + }, + "role": { + "description": "Recipient's role name in the document", + "type": "string" + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Custom email subject for the recipient" + } + }, + "required": [ + "email", + "role" + ], + "type": "object" + } +} - removed
Input schema / properties / entity_id / titleRemoved value: -"Entity Id" - removed
Input schema / properties / entity_type / titleRemoved value: -"Entity Type" - removed
Input schema / properties / name / titleRemoved value: -"Name" - changed
Input schema / properties / orders / anyOfPrevious value: -[ - { - "items": { - "$ref": "#/$defs/InviteOrder" - }, - "type": "array" - }, - { - "type": "null" - } -]New value: +[ + { + "items": { + "$ref": "#/$defs/InviteOrder" + }, + "type": "array" + }, + { + "type": "string" + } +] - removed
Input schema / properties / orders / defaultRemoved value: -null - changed
Input schema / properties / orders / descriptionPrevious value: -"List of orders with recipients for the invite"New value: +"List of orders with recipients for the invite (can be a list or JSON string)" - added
Input schema / properties / orders / examplesAdded value: +[ + [ + { + "order": 1, + "recipients": [ + { + "action": "sign", + "email": "user@example.com", + "role": "Signer 1" + } + ] + } + ], + "[{\"order\": 1, \"recipients\": [{\"email\": \"user@example.com\", \"role\": \"Signer 1\", \"action\": \"sign\"}]}]" +] - removed
Input schema / properties / orders / titleRemoved value: -"Orders" - changed
Input schema / requiredPrevious value: -[ - "entity_id" -]New value: +[ + "entity_id", + "orders" +] - removed
Output schema / properties / created_entity_id / titleRemoved value: -"Created Entity Id" - removed
Output schema / properties / created_entity_name / titleRemoved value: -"Created Entity Name" - removed
Output schema / properties / created_entity_type / titleRemoved value: -"Created Entity Type" - removed
Output schema / properties / invite_entity / titleRemoved value: -"Invite Entity" - removed
Output schema / properties / invite_id / titleRemoved value: -"Invite Id" - removed
Output schema / titleRemoved value: -"SendInviteFromTemplateResponse"
- Changed
update_document_fields9 fields changed- added
Input schema / $defsAdded value: +{ + "FieldToUpdate": { + "description": "Single field to update in a document.", + "properties": { + "name": { + "description": "Name of the field to update", + "type": "string" + }, + "value": { + "description": "New value for the field", + "type": "string" + } + }, + "required": [ + "name", + "value" + ], + "type": "object" + }, + "UpdateDocumentFields": { + "description": "Request model for updating document fields.", + "properties": { + "document_id": { + "description": "ID of the document to update", + "type": "string" + }, + "fields": { + "description": "Array of fields to update with their new values", + "items": { + "$ref": "#/$defs/FieldToUpdate" + }, + "type": "array" + } + }, + "required": [ + "document_id", + "fields" + ], + "type": "object" + } +} - added
Input schema / properties / update_requests / examplesAdded value: +[ + [ + { + "document_id": "abc123", + "fields": [ + { + "name": "FieldName1", + "value": "New Value 1" + }, + { + "name": "FieldName2", + "value": "New Value 2" + } + ] + }, + { + "document_id": "def456", + "fields": [ + { + "name": "FieldName3", + "value": "New Value 3" + } + ] + } + ] +] - removed
Input schema / properties / update_requests / titleRemoved value: -"Update Requests" - removed
Output schema / $defs / UpdateDocumentFieldsResult / properties / document_id / titleRemoved value: -"Document Id" - removed
Output schema / $defs / UpdateDocumentFieldsResult / properties / reason / titleRemoved value: -"Reason" - removed
Output schema / $defs / UpdateDocumentFieldsResult / properties / updated / titleRemoved value: -"Updated" - removed
Output schema / $defs / UpdateDocumentFieldsResult / titleRemoved value: -"UpdateDocumentFieldsResult" - removed
Output schema / properties / results / titleRemoved value: -"Results" - removed
Output schema / titleRemoved value: -"UpdateDocumentFieldsResponse"
15 tool updates
- First observed
create_embedded_editor - First observed
create_embedded_editor_from_template - First observed
create_embedded_invite - First observed
create_embedded_invite_from_template - First observed
create_embedded_sending - First observed
create_embedded_sending_from_template - First observed
create_from_template - First observed
get_document - First observed
get_document_download_link - First observed
get_invite_status - First observed
list_all_templates - First observed
list_document_groups - First observed
send_invite - First observed
send_invite_from_template - First observed
update_document_fields
TDQS
Most tools have distinct purposes, but the abundance of embedded invite/editor/sending variants (each with a _from_template counterpart) can cause confusion despite detailed descriptions. An agent might struggle to pick the right one without careful reading.
All tools follow a consistent verb_noun snake_case pattern. Verbs like cancel, create, get, list, rename, send, update, upload, view are used uniformly, and suffixes like _from_template are applied systematically.
25 tools is on the higher side but justified by the broad scope of document signing workflows (upload, invite, template, contact management, skills). It's not excessive for a comprehensive API.
Covers most lifecycle operations, but notably missing a delete/remove tool for documents, templates, or groups. Also, update_document_fields only handles text fields, leaving other field types unaddressed.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP server for Dropbox Sign — signature requests, templates, and account for AI agents.
PandaDoc MCP server for creating, sending, signing, and tracking PandaDoc documents.
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
Send documents for legally binding e-signature and manage the reusable templates behind them.
Related MCP Servers
- AlicenseBqualityCmaintenanceFacilitates contract and template management for eSignatures, enabling users to create, send, update, and manage contracts and templates with customizable options through a user-friendly interface.1340MIT
- AlicenseAqualityDmaintenanceModel Context Protocol (MCP) server for BoldSign API14947MIT
- AlicenseNot gradedqualityDmaintenanceThis read-only MCP Server allows you to connect to Gmail data from Claude Desktop through CData JDBC Drivers. For full CRUD support, check out the first managed MCP platform: CData Connect AI (https://www.cdata.com/ai/).MIT
- AlicenseNot gradedqualityDmaintenanceThis read-only MCP Server allows you to connect to DocuSign data from Claude Desktop through CData JDBC Drivers. Free (beta) read/write servers available at https://www.cdata.com/solutions/mcp3MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/signnow/sn-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server