What can you do with this server?

The BoldSign MCP server enables integration with the BoldSign API to manage e-signature processes including: * Document Management: * List, retrieve, and revoke documents * Send reminders for pending signatures * View team documents with filtering and pagination * Template Operations: * List and retrieve templates * Send documents for signing using templates * Contact Management: * List and retrieve contact details * User and Team Administration: * List and retrieve user and team information * Customizable Workflows: * Configure authentication methods, delivery modes, and signing orders * Apply filtering and pagination across all resource types

Which integrations are available for this server?

Supports Node.js version 18.0.0 or higher as a required runtime environment for the BoldSign MCP server.

How do I use boldsign?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@boldsign list my recent documents" 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.

de en es ja ko ru zh

boldsign

Official

by boldsign

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

BoldSign MCP Server

Author: Syncfusion

Homepage: https://boldsign.com

WARNING

This repository is deprecated. For improved authentication options, additional features, and a fully managed experience, use the hosted BoldSign MCP Server instead.

An MCP server designed to facilitate interaction between Large Language Models (LLMs) and the BoldSign API. The Model Context Protocol (MCP) extends LLM capabilities, enabling them to act as agents when connecting with external systems.

This project contains various tools that interact with the BoldSign API to manage templates and documents for your e-signature.

Prerequisites

Before you begin, ensure you have the following installed and set up:

A BoldSign Account: You will need an account to obtain API credentials. You can sign up for a free trial here or use an existing sandbox or paid account.
BoldSign API Credentials: Obtain your necessary application credentials, specifically an API key. Instructions on how to generate and manage your API key can be found in the BoldSign API documentation.
Node.js: Version 18.0.0 or higher is required.
An MCP Client: To interact with the server, you need an MCP client application. Examples include Cursor, VS Code, Windsurf, Claude Desktop, Cline, or any other compatible MCP client.

Related MCP server: MCP REST API Server

Installation

This section provides instructions on how to configure popular MCP clients to connect to the BoldSign MCP server. You will need to add the relevant configuration snippet to your client's settings or configuration file.

Environment Variables

You will need to configure the following environment variables for the BoldSign MCP server to function correctly:

BOLDSIGN_API_KEY - Your API key obtained from your BoldSign account. Please refer to the Prerequisites section for instructions on how to get your API key.
BOLDSIGN_API_REGION - Specifies the region of your BoldSign account. This defaults to US if not specified.
- US for the United States region.
- EU for the Europe region.
- CA for the Canada region.

Install in Cursor

The recommended approach is to add the following configuration to your global Cursor MCP configuration file, typically found at ~/.cursor/mcp.json.

Alternatively, you can install it for a specific project by creating a .cursor/mcp.json file in your project's root folder and adding the same configuration there.

{
  "mcpServers": {
    "boldsign": {
      "command": "npx",
      "args": ["-y", "@boldsign/mcp"],
      "env": {
        "BOLDSIGN_API_KEY": "YOUR_BOLDSIGN_API_KEY",
        "BOLDSIGN_API_REGION": "US"
      }
    }
  }
}

Refer to the Cursor MCP documentation for more information on setting up MCP servers in Cursor.

Install in Windsurf

Add the following configuration snippet to your Windsurf MCP configuration file:

{
  "mcpServers": {
    "boldsign": {
      "command": "npx",
      "args": ["-y", "@boldsign/mcp"],
      "env": {
        "BOLDSIGN_API_KEY": "YOUR_BOLDSIGN_API_KEY",
        "BOLDSIGN_API_REGION": "US"
      }
    }
  }
}

Refer to the Windsurf MCP documentation for more information on Windsurf MCP setup.

Install in VS Code

Add the following configuration to the VS Code settings file where you manage MCP server configurations:

{
  "servers": {
    "boldsign": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@boldsign/mcp"],
      "env": {
        "BOLDSIGN_API_KEY": "YOUR_BOLDSIGN_API_KEY",
        "BOLDSIGN_API_REGION": "US"
      }
    }
  }
}

Refer to the VS Code MCP documentation for more information on VS Code MCP setup.

Install in Claude Desktop

Add the following configuration to your Claude Desktop configuration file, which is typically named claude_desktop_config.json:

{
  "mcpServers": {
    "boldsign": {
      "command": "npx",
      "args": ["-y", "@boldsign/mcp"],
      "env": {
        "BOLDSIGN_API_KEY": "YOUR_BOLDSIGN_API_KEY",
        "BOLDSIGN_API_REGION": "US"
      }
    }
  }
}

Refer to the Model Context Protocol quickstart guide for more information on Claude Desktop MCP setup.

Install in Cline

Add the following configuration snippet to your Cline MCP configuration file.

{
  "mcpServers": {
    "boldsign": {
      "command": "npx",
      "args": ["-y", "@boldsign/mcp"],
      "env": {
        "BOLDSIGN_API_KEY": "YOUR_BOLDSIGN_API_KEY",
        "BOLDSIGN_API_REGION": "US"
      }
    }
  }
}

Refer to the Cline MCP configuration guide for more information on Cline MCP setup.

Available Tools

This MCP server provides access to the following tools via the BoldSign API:

Documents

List documents: Retrieves a paginated list of your documents.
List team documents: Retrieves a paginated list of team documents.
Get document: Retrieves detailed information, including status, for a specific document using its ID.
Revoke document: Allows you to cancel or call off a document that is in progress.
Send reminders: Sends reminders to signers who have not yet completed their signature on a document.

Templates

List templates: Retrieves a paginated list of templates available in your BoldSign account.
Get template: Retrieves detailed information for a specific template using its ID.
Send document from template: Creates and sends out a document for signing based on a pre-configured template.

Contacts

List Contacts: Retrieves a paginated list of contacts from your BoldSign account.
Get Contact: Retrieves detailed information for a specific contact using their ID.

Users

List Users: Retrieves a paginated list of users in your BoldSign organization.
Get User: Retrieves detailed information for a specific user using their ID.

Teams

List Teams: Retrieves a paginated list of teams in your BoldSign organization.
Get Team: Retrieves detailed information for a specific team using their ID.

Repository

https://github.com/boldsign/boldsign-mcp

Bug Tracker

https://github.com/boldsign/boldsign-mcp/issues

License

This project is licensed under the MIT License. See the LICENSE file for details.

Available Tools

14 tools

get_contactB

This tool utilizes the BoldSign API to retrieve detailed information for a specific contact within your organization. To use this tool, you need to provide the unique identifier (ID) of the contact you wish to retrieve. Contacts are primarily used to store signer details, identified by their unique email address, for use when creating and sending documents for signature within the BoldSign application.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Required. The unique identifier (ID) of the contact to retrieve. This can be obtained from the list contacts tool.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the read operation ('retrieve') and mentions contacts are used for signer details, but lacks information about authentication requirements, rate limits, error handling, or what 'detailed information' includes. For a read tool with zero annotation coverage, this leaves significant behavioral gaps.

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

Conciseness4/5

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

The description is reasonably concise with two sentences that efficiently cover purpose and usage. The first sentence states the core function, and the second provides context about contacts. However, the second sentence could be more focused on tool-specific guidance rather than general contact usage.

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

Completeness3/5

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

For a single-parameter read tool with no annotations and no output schema, the description provides adequate basic information but lacks completeness. It doesn't describe the return format, error conditions, or authentication needs. The mention of contact usage in document workflows adds some context, but more behavioral details would be needed for full completeness.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the single required 'id' parameter. The description adds marginal value by noting the ID is 'unique' and 'can be obtained from the list contacts tool', but doesn't provide format examples or additional constraints beyond what the schema specifies. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'retrieve detailed information for a specific contact within your organization' using the BoldSign API. It specifies the verb (retrieve) and resource (contact), but doesn't explicitly differentiate from sibling tools like 'list_contacts' beyond mentioning that contacts are used for signer details in document workflows.

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

Usage Guidelines3/5

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

The description implies usage by stating 'To use this tool, you need to provide the unique identifier (ID) of the contact you wish to retrieve' and mentions contacts are used for signer details in document creation. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'list_contacts' or 'get_user', nor does it specify prerequisites or exclusions.

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

get_document_propertiesB

Retrieve comprehensive details of a document in your BoldSign organization. This API allows authorized users, including senders, signers, team admins, and account admins, to access document properties by specifying the unique document ID. The response includes information such as status, metadata, sender and signer details, form fields, and document history. If an unauthorized user attempts to access the document, an unauthorized response will be returned.

ParametersJSON Schema

Name	Required	Description	Default
`documentId`	Yes	Required. The unique identifier (ID) of the document to retrieve. This can be obtained from the list documents tool.

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as authorization requirements ('authorized users...'), access control ('unauthorized response will be returned'), and response content ('information such as status, metadata...'). However, it lacks details on rate limits, pagination, or error handling beyond authorization, leaving some gaps for a read operation.

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

Conciseness4/5

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

The description is appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: the first states the action, the second covers authorization and input, the third details response content, and the fourth mentions error handling. There's no wasted text, though it could be slightly more streamlined.

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

Completeness3/5

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

Given the tool's moderate complexity (single parameter, read operation) and lack of annotations and output schema, the description is somewhat complete but has gaps. It covers purpose, authorization, and response overview, but doesn't detail the full output structure or potential side effects, which could be helpful for an AI agent to understand what to expect.

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

Parameters3/5

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

The input schema has 100% description coverage, with 'documentId' clearly documented. The description adds minimal value beyond the schema, only reiterating that the ID is 'unique' and can be 'obtained from the list documents tool.' This provides slight context but doesn't significantly enhance parameter understanding, so it meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Retrieve comprehensive details of a document in your BoldSign organization.' It specifies the verb ('retrieve') and resource ('document'), but doesn't explicitly differentiate it from sibling tools like 'list_documents' or 'get_template_properties' beyond mentioning it returns 'document properties' by ID. This makes it clear but not fully sibling-distinctive.

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

Usage Guidelines3/5

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

The description implies usage by stating it's for 'authorized users' and requires a 'unique document ID,' but doesn't explicitly say when to use this tool versus alternatives like 'list_documents' for browsing or 'get_template_properties' for templates. It mentions the ID can be 'obtained from the list documents tool,' which provides some context but no direct when/when-not guidance.

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

get_teamA

Retrieve detailed information about an existing team in your BoldSign organization. This API provides access to team-specific properties, such as team name, users, created date, and modified date, by specifying the unique team ID.

ParametersJSON Schema

Name	Required	Description	Default
`teamId`	Yes	Required. The unique identifier (ID) of the team to retrieve. This can be obtained from the list teams tool.

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses this is a read operation ('Retrieve') and mentions what information is returned ('team-specific properties, such as team name, users, created date, and modified date'). However, it doesn't address potential behavioral aspects like error conditions, authentication requirements, rate limits, or what happens if the team ID is invalid.

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

Conciseness5/5

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

The description is efficiently structured in two sentences: the first states the purpose and scope, the second provides implementation details. Every word earns its place with no redundant information or unnecessary elaboration.

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

Completeness4/5

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

For a simple read operation with 100% schema coverage but no output schema, the description is reasonably complete. It explains what the tool does, what information it returns, and how to use it. The main gap is the lack of output format details, which would be helpful since there's no output schema provided.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents the single parameter. The description adds minimal value beyond the schema by mentioning 'unique team ID' and that it's 'required,' but doesn't provide additional semantic context about parameter usage or constraints.

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

Purpose5/5

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

The description clearly states the specific action ('Retrieve detailed information'), resource ('about an existing team in your BoldSign organization'), and scope ('by specifying the unique team ID'). It distinguishes from sibling tools like list_teams by focusing on single-team retrieval rather than listing multiple teams.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('by specifying the unique team ID') and implies an alternative (list_teams for getting team IDs). However, it doesn't explicitly state when NOT to use it or compare it directly to other get_* tools like get_user or get_contact.

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

get_template_propertiesA

Retrieves the detailed properties and settings of a specific BoldSign template using its unique template ID.

ParametersJSON Schema

Name	Required	Description	Default
`templateId`	Yes	Required. The unique identifier (ID) of the template to retrieve. This can be obtained from the list templates tool.

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('Retrieves'), which is clear, but lacks details on permissions, rate limits, error handling, or output format. It adds minimal context beyond the basic action, leaving gaps in behavioral understanding.

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

Conciseness5/5

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key usage note. It is front-loaded with the main action and resource, with no wasted words, making it easy to parse quickly.

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

Completeness3/5

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter sourcing, but lacks details on behavioral aspects like authentication needs or return values, which are important for a tool with no structured output schema.

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

Parameters3/5

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

Schema description coverage is 100%, with the single parameter 'templateId' fully documented in the schema. The description adds marginal value by reinforcing that the ID is 'unique' and can be 'obtained from the list templates tool,' but does not provide additional semantics beyond what the schema already covers.

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

Purpose5/5

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

The description clearly states the action ('Retrieves'), the resource ('detailed properties and settings of a specific BoldSign template'), and the key identifier ('using its unique template ID'). It distinguishes this tool from siblings like 'list_templates' by focusing on individual template details rather than listing multiple templates.

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

Usage Guidelines4/5

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

The description implies usage context by specifying 'a specific BoldSign template using its unique template ID,' suggesting this tool is for detailed lookup after obtaining an ID from 'list_templates.' However, it does not explicitly state when not to use it or name alternatives, leaving some ambiguity compared to other get_* tools.

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

get_userB

Retrieves detailed information for a specific BoldSign user based on their unique user ID.

ParametersJSON Schema

Name	Required	Description	Default
`userId`	Yes	Required. The unique identifier (ID) of the user to retrieve. This can be obtained from the list users tool.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states this is a retrieval operation, which implies it's likely read-only and non-destructive, but it does not explicitly confirm this, nor does it mention any behavioral traits like authentication requirements, rate limits, or error handling. This leaves gaps in understanding 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.

Conciseness5/5

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key usage note without any unnecessary words. It is front-loaded with the main action and resource, making it highly concise and effective.

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

Completeness3/5

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

Given the tool's simplicity (one required parameter, no output schema, no annotations), the description is adequate but not fully complete. It covers the basic purpose and parameter context, but lacks details on behavioral aspects like what 'detailed information' includes or any operational constraints, which could be helpful for an agent.

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

Parameters3/5

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

The schema description coverage is 100%, so the input schema fully documents the 'userId' parameter. The description adds minimal value by reiterating it's for a 'specific BoldSign user' and referencing the 'list users tool', but does not provide additional semantics beyond what the schema already covers, resulting in a baseline score of 3.

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

Purpose4/5

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

The description clearly states the verb ('Retrieves') and resource ('detailed information for a specific BoldSign user'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'list_users' beyond the singular vs. plural distinction, which is why it scores 4 instead of 5.

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

Usage Guidelines3/5

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

The description implies usage by specifying 'based on their unique user ID' and references obtaining the ID from 'list users tool', providing some context. However, it lacks explicit guidance on when to use this tool versus alternatives like 'list_users' or other user-related tools, leaving room for interpretation.

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

list_contactsA

This tool allows you to retrieve a paginated list of contacts from your BoldSign organization. You can specify the page number to navigate through the results, the number of contacts to display per page, an optional search term to filter contacts, and the type of contacts to retrieve (your personal contacts or all organizational contacts). Contacts are primarily used to store signer details, identified by their unique email address, for use when creating and sending documents for signature within the BoldSign application.

ParametersJSON Schema

Name	Required	Description	Default
`pageSize`	Yes
`page`	Yes
`searchKey`	No	Optional. A string used to filter the contact list. The API will return contacts whose details contain this search term.
`contactType`	Yes	Optional. Filters the list of contacts based on their type. 'MyContacts' retrieves contacts specifically associated with your account, while 'AllContacts' (default) retrieves all accessible contacts within your organization.	AllContacts

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses pagination behavior and contact usage context, but lacks details on authentication requirements, rate limits, error conditions, or response format. It adequately describes the core operation but misses important behavioral traits for a read operation.

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

Conciseness4/5

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

Two well-structured sentences: first covers core functionality and parameters, second provides business context. Slightly verbose with 'allows you to' phrasing, but each sentence adds value. Could be more front-loaded by leading with the primary purpose.

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

Completeness3/5

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

For a 4-parameter read tool with no annotations and no output schema, the description provides adequate purpose and parameter context but lacks critical behavioral details like response structure, error handling, and authentication. It's minimally viable but has clear gaps in completeness.

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

Parameters4/5

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

Schema description coverage is 50% (only searchKey and contactType have descriptions). The description compensates by explaining all four parameters: page navigation, per-page display, search filtering, and contact type distinction. It adds meaningful context beyond the schema, though doesn't specify exact search behavior or default values.

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

Purpose5/5

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

The description clearly states the specific action ('retrieve a paginated list of contacts'), resource ('from your BoldSign organization'), and scope ('contacts are primarily used to store signer details... for use when creating and sending documents for signature'). It distinguishes from siblings like 'get_contact' (singular) and 'list_documents' (different resource).

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

Usage Guidelines3/5

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

The description implies usage for retrieving contacts for document signing workflows, but lacks explicit guidance on when to use this versus alternatives like 'get_contact' (for single contact) or 'list_users' (different resource). No when-not-to-use scenarios or prerequisites are mentioned.

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

list_documentsA

Retrieve a paginated list of documents available in your My Documents section. This API fetches document details such as status, sender, recipient, labels, transmission type, creation date, and modification date, with options for filtering and paginated navigation.

ParametersJSON Schema

Name	Required	Description	Default
`pageSize`	Yes
`page`	Yes
`searchKey`	No	Optional. A search term used to filter the document list. The API will return documents matching details like document title, document ID, sender name, or recipient name.
`sentBy`	No	Optional. Filter documents by sender email addresses. One or more sender email IDs can be specified.
`recipients`	No	Optional. Filter documents by signer email addresses. One or more signer email IDs can be specified.
`startDate`	No	Optional. Start transmit date range of the document. The date should be in a valid date-time format.
`endDate`	No	Optional. End transmit date range of the document. The date should be in a valid date-time format.
`labels`	Yes	Optional. Labels associated with documents. Used to filter the list by specific document tags.
`transmitType`	Yes	Optional. Type of transmission to filter documents if the user is both sender, recipient or both.	Both
`status`	Yes	Optional. Filter documents based on their current status.
`nextCursor`	No	Optional. Cursor value for pagination beyond 10,000 records. Set to the cursor of the last retrieved document.
`brandIds`	No	Optional. Filters documents based on associated brand IDs. Only documents linked to the specified brands will be retrieved.
`dateFilterType`	No	Optional. Type of date filter applied to documents. Available options: 'SentBetween' and 'Expiring'.

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It adequately describes the core behavior (retrieving paginated lists with filtering) and mentions what data is returned (status, sender, recipient, etc.). However, it doesn't disclose important behavioral traits like rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'retrieve' implies reading).

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

Conciseness5/5

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

The description is perfectly structured in two sentences: the first establishes the core purpose, and the second elaborates on capabilities. Every word earns its place - there's no redundancy, and the information is front-loaded with the essential 'retrieve paginated list' concept immediately.

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

Completeness3/5

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

For a complex tool with 13 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the what (retrieving documents) and some how (filtering, pagination), but doesn't address authentication, error handling, rate limits, or the structure of returned data. Given the complexity, more behavioral context would be beneficial.

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

Parameters3/5

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

Schema description coverage is high at 85%, establishing a baseline score of 3. The description adds some value by mentioning 'options for filtering and paginated navigation' which aligns with the schema's many filter parameters and pagination controls. However, it doesn't provide additional semantic context beyond what's already well-documented in the schema descriptions.

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

Purpose5/5

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

The description clearly states the specific action ('Retrieve a paginated list'), resource ('documents available in your My Documents section'), and scope ('with options for filtering and paginated navigation'). It distinguishes itself from siblings like 'get_document_properties' (which fetches details of a single document) and 'list_team_documents' (which focuses on team-specific documents).

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

Usage Guidelines3/5

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

The description implies usage context by specifying 'My Documents section' and mentioning filtering/pagination options, but doesn't explicitly state when to use this tool versus alternatives like 'list_team_documents' or 'get_document_properties'. No explicit exclusions or prerequisites are provided, leaving usage guidance at an implied level.

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

list_team_documentsA

Retrieve a paginated list of documents available in the Team Documents section of your BoldSign organization. Team admins can view documents sent and received by team members, while account admins have access to all team documents across the organization. This API allows filtering based on status, user ID, team ID, document details, transmission type, and date range. If the user is not an account admin or team admin, an unauthorized response will be returned.

ParametersJSON Schema

Name	Required	Description	Default
`pageSize`	Yes
`page`	Yes
`searchKey`	No	Optional. A search term used to filter the document list. The API will return documents matching details like document title, document ID, sender name, or recipient name.
`userId`	No	Optional. Filter documents based on the list of team member IDs. One or more user IDs can be specified.
`teamId`	No	Optional. Filter documents based on specific teams. One or more team IDs can be specified.
`startDate`	No	Optional. Start transmit date range of the document. The date should be in a valid date-time format.
`endDate`	No	Optional. End transmit date range of the document. The date should be in a valid date-time format.
`labels`	No	Optional. Labels associated with documents. Used to filter the list by specific document tags.
`transmitType`	Yes	Optional. Type of transmission. Can be 'Sent', 'Received', or 'Both'.	Both
`status`	No	Optional. Filter documents based on their current status. Available statuses include 'WaitingForMe', 'WaitingForOthers', 'NeedAttention', 'Completed', 'Declined', 'Revoked', 'Expired', 'Scheduled', and 'Draft'. Use 'None' to disable status filtering.
`nextCursor`	No	Optional. Cursor value for pagination beyond 10,000 records. Set to the cursor of the last retrieved document.
`brandIds`	No	Optional. Filters documents based on associated brand IDs. Only documents linked to the specified brands will be retrieved.
`dateFilterType`	No	Optional. Type of date filter applied to documents. Available options: 'SentBetween' and 'Expiring'.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes access control (admin roles required), pagination behavior, filtering capabilities, and error conditions (unauthorized response). However, it lacks details on rate limits, response format, or what happens with large result sets beyond pagination.

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

Conciseness4/5

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

The description is appropriately sized and front-loaded with the core purpose. Every sentence adds value: first states what it does, second explains access levels, third details filtering, fourth specifies authorization requirements. It could be slightly more concise by combining some filtering details, but overall structure is efficient.

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

Completeness4/5

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

Given the complexity (13 parameters, no output schema, no annotations), the description does well by covering purpose, access control, filtering, and error conditions. However, it lacks details about the return format (what fields documents have) and doesn't explain pagination mechanics beyond mentioning it's 'paginated,' which is a gap for a list tool with no output schema.

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

Parameters3/5

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

Schema description coverage is high at 85%, so the baseline is 3. The description adds value by summarizing the filtering capabilities ('filtering based on status, user ID, team ID, document details, transmission type, and date range'), but doesn't provide additional syntax or format details beyond what's already documented in the schema descriptions.

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

Purpose5/5

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

The description clearly states the verb ('Retrieve'), resource ('paginated list of documents'), and scope ('Team Documents section of your BoldSign organization'). It distinguishes from siblings like 'list_documents' by specifying the team context and administrative access requirements, making the purpose specific and differentiated.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool: for team documents with admin access (team admins view team member documents, account admins view all). It also provides exclusion criteria: 'If the user is not an account admin or team admin, an unauthorized response will be returned,' clearly indicating prerequisites and when not to use it.

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

list_teamsA

Retrieve a paginated list of teams within your BoldSign organization. This API fetches team details such as team name, users, created date, and modified date for all listed teams, with options for filtering using a search term and navigating through pages of results.

ParametersJSON Schema

Name	Required	Description
`pageSize`	Yes
`page`	Yes
`searchKey`	No	Optional. A search term to filter the list of teams. The API will return teams whose details, such as name, match the provided search term.

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: pagination behavior, filtering capability via search term, and what data is returned (team name, users, dates). However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens when no teams match the search term.

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

Conciseness5/5

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

Two well-structured sentences that efficiently convey purpose, scope, capabilities, and parameters. The first sentence establishes core functionality, the second adds details about returned data and parameter usage. Every element earns its place with zero wasted words.

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

Completeness3/5

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

For a read-only list tool with 3 parameters and no output schema, the description covers the essential 'what' and 'how' but has gaps. It explains pagination and filtering but doesn't describe the return format structure, error handling, or authentication context. Given the lack of annotations and output schema, more behavioral detail would be helpful.

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

Parameters4/5

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

Schema description coverage is only 33% (only 'searchKey' has a description). The description compensates by explaining the purpose of pagination ('navigating through pages of results') and filtering ('options for filtering using a search term'), which adds meaningful context beyond the bare schema. It doesn't detail parameter constraints like pageSize limits, but provides good semantic value.

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

Purpose5/5

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

The description clearly states the specific action ('Retrieve a paginated list'), resource ('teams within your BoldSign organization'), and scope ('all listed teams'). It distinguishes from sibling tools like 'get_team' (singular) and 'list_contacts' (different resource) by explicitly focusing on teams with pagination and filtering capabilities.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool: to get a comprehensive, paginated list of teams with optional filtering. It doesn't explicitly state when not to use it or name alternatives, but the context implies this is for bulk retrieval rather than single-team lookup (which would use 'get_team').

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

list_templatesC

Retrieves a paginated list of BoldSign templates with options to filter by page number, page size, search key, template type, creator, labels, creation date range, and brand IDs.

ParametersJSON Schema

Name	Required	Description	Default
`pageSize`	Yes
`page`	Yes
`searchKey`	No	Optional. A search key to filter templates by properties such as name and email address. Provides a way to refine results based on specific criteria.
`templateType`	Yes	Optional. Filters templates based on their type (all, mytemplates, sharedtemplate). Defaults to 'all'.	all
`createdBy`	No	Optional. Filters templates based on the email address(es) of their creators.
`templateLabels`	No	Optional. Filters templates based on associated labels (tags).
`startDate`	No	Optional. Filters templates created on or after this date (in YYYY-MM-DD format).
`endDate`	No	Optional. Filters templates created on or before this date (in YYYY-MM-DD format).
`brandIds`	No	Optional. Filters templates associated with the specified brand IDs.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination and filtering options, but doesn't describe response format, error conditions, rate limits, authentication needs, or whether it's read-only (implied by 'retrieves' but not explicit). For a tool with 9 parameters and no annotation coverage, this leaves significant behavioral gaps.

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

Conciseness4/5

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

The description is a single, well-structured sentence that efficiently communicates core functionality and parameter scope. It's appropriately sized for a list operation with multiple filters. No wasted words, though it could be slightly more front-loaded by emphasizing the primary action before listing all parameters.

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

Completeness3/5

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

For a read operation with no output schema and no annotations, the description adequately covers what the tool does but lacks important context. It doesn't describe the return format (what a 'template' object contains), pagination mechanics beyond mentioning it exists, or error handling. With 9 parameters and no structured output documentation, more completeness would be beneficial.

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

Parameters3/5

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

Schema description coverage is 78%, so the schema already documents most parameters well. The description lists all 9 parameters by name, adding minimal semantic value beyond what's in the schema. It doesn't explain parameter interactions, default behaviors beyond what's in schema, or provide usage examples. Baseline 3 is appropriate given high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('Retrieves') and resource ('BoldSign templates'), and specifies it's paginated. It doesn't explicitly differentiate from sibling tools like 'get_template_properties', but the verb 'list' versus 'get' implies a collection versus single item. The purpose is 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.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_template_properties' or 'list_documents'. It lists filtering options but doesn't indicate scenarios where this tool is preferred over others. There's no mention of prerequisites, access requirements, or typical use cases.

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

list_usersC

Retrieves a paginated list of BoldSign users, with optional filtering by a search term.

ParametersJSON Schema

Name	Required	Description
`pageSize`	Yes
`page`	Yes
`search`	No	Optional. A string used to filter the user list. The API will return contacts whose details contain this search term.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only mentions pagination and optional filtering. It lacks details on permissions, rate limits, error handling, or what fields are returned. For a read operation with 3 parameters, this leaves significant behavioral gaps.

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

Conciseness4/5

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

The description is a single, efficient sentence that front-loads key information (retrieval, pagination, filtering). It avoids redundancy but could be slightly more structured (e.g., separating core purpose from optional features).

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

Completeness2/5

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

For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't cover return values, error cases, or behavioral nuances like pagination mechanics. Given the complexity, it should provide more context to be complete.

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

Parameters3/5

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

Schema description coverage is low (33%), with only the 'search' parameter documented. The description adds that filtering is by 'search term', but doesn't explain 'pageSize' or 'page' beyond what the schema provides (e.g., ranges). It partially compensates but not fully for the coverage gap.

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

Purpose4/5

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

The description clearly states the action ('Retrieves') and resource ('BoldSign users'), and specifies it's a paginated list with optional filtering. However, it doesn't explicitly differentiate from sibling tools like 'get_user' (singular) or 'list_contacts', leaving some ambiguity about scope.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'get_user' (for single user) or 'list_contacts'. The description mentions optional filtering but doesn't clarify use cases or prerequisites, offering minimal contextual direction.

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

revoke_documentA

The document signing process can be called off or revoked by the sender of the document. Once you revoke a document, signers can no longer view or sign it. Revoke action can only be performed on the in-progress status documents.

ParametersJSON Schema

Name	Required	Description
`documentId`	Yes	Required. The unique identifier (ID) of the document to revoke. This can be obtained from the list documents tool.
`message`	Yes	The exact reason for performing a revoke action.
`onBehalfOf`	No	Optional. Email address of the sender when creating a document on their behalf. This email can be retrieved from the `behalfOf` property in the get document or list documents tool.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the irreversible consequence ('signers can no longer view or sign it'), the actor requirement ('by the sender'), and the state constraint ('in-progress status documents'). This covers key behavioral aspects for a destructive operation.

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

Conciseness5/5

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

The description is efficiently structured in three sentences that each add distinct value: purpose statement, consequence disclosure, and usage constraint. There's no wasted language, and the most critical information (what the tool does) is presented first.

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

Completeness4/5

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

For a destructive operation with no annotations and no output schema, the description provides good coverage of the essential context: what it does, who can do it, when it applies, and the irreversible effect. It could potentially mention authentication requirements or error conditions, but overall it's quite complete for its complexity level.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, which is acceptable given the comprehensive schema coverage. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the action ('revoke'), resource ('document'), and scope ('signing process'). It specifies that only the sender can perform this action, distinguishing it from other document-related tools like list_documents or send_reminder_for_document_sign which have different purposes.

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

Usage Guidelines4/5

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

The description provides clear context about when to use this tool: 'Revoke action can only be performed on the in-progress status documents.' It doesn't explicitly mention when NOT to use it or name specific alternatives, but the status restriction provides meaningful guidance for appropriate usage.

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

send_document_from_templateC

Initiates the process of sending a document based on a pre-defined template. This tool allows you to specify recipients, form field values, and various sending options to create and send a document for signing.

ParametersJSON Schema

Name	Required	Description	Default
`templateId`	Yes	Required. The unique identifier (ID) of the template to be used for sending the document. This can be obtained from the list templates tool.
`body`	Yes	Optional. The main content and settings for sending the document.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool 'creates and sends a document for signing,' implying a write operation with side effects, but lacks details on permissions required, rate limits, idempotency, or what happens after sending (e.g., document status changes). This is inadequate for a mutation tool with complex parameters.

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

Conciseness4/5

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

The description is concise and front-loaded, stating the core purpose in the first sentence. Both sentences earn their place by clarifying the tool's function and key parameters. No redundant or verbose language is present.

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

Completeness2/5

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

Given the tool's complexity (2 parameters with nested objects, no annotations, no output schema), the description is insufficient. It doesn't explain the return value, error conditions, or behavioral nuances like authentication requirements or side effects. For a mutation tool with rich input schema, more context is needed to guide effective use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value beyond the schema, mentioning 'recipients, form field values, and various sending options' which loosely maps to parameters like 'roles' and 'body' but doesn't provide additional syntax or format details. Baseline 3 is appropriate given high schema coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Initiates the process of sending a document based on a pre-defined template' with specific actions like specifying recipients, form field values, and sending options. It distinguishes from siblings like 'list_templates' or 'get_template_properties' by focusing on sending rather than retrieval, though it doesn't explicitly name alternatives.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives is provided. The description mentions using a template but doesn't clarify when to choose this over non-template sending methods (if they exist) or other document-related tools. Usage context is implied but not articulated.

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

send_reminder_for_document_signA

Send reminder emails to signers for pending document signatures. This API allows users to remind signers about outstanding signature requests by specifying the document ID and recipient email addresses. Multiple signers can receive reminders at once, and custom messages can be included. If sending reminders on behalf of another sender, specify the relevant sender email addresses.

ParametersJSON Schema

Name	Required	Description
`documentId`	Yes	Required. The unique identifier (ID) of the document to send a reminder email to signers for pending signatures.
`receiverEmails`	No	Optional. One or more signer email addresses to send reminders for pending signatures. If multiple signers are required to sign the document, specify their email addresses. If there is not emails provided, it will send reminder to all pending signers. The signers of a document can be obtained from the document-properties tool, using the documentId.
`message`	No	Optional. Message to be sent in the reminder email. If not provided, the system will use a default reminder message.
`onBehalfOf`	No	Optional. Email address of the sender when creating a document on their behalf. This email can be retrieved from the `behalfOf` property in the get document or list documents tool.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key behaviors: sending emails to multiple signers, allowing custom messages, and supporting on-behalf-of sending. However, it lacks details on rate limits, error handling, or response format, which are important for an agent to use the tool effectively.

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

Conciseness4/5

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

The description is appropriately sized and front-loaded, with the first sentence stating the core purpose. Subsequent sentences efficiently explain key features without redundancy. However, it could be slightly more structured by separating usage notes from parameter explanations.

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

Completeness3/5

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

Given the tool's complexity (4 parameters, no output schema, and no annotations), the description is moderately complete. It covers the main functionality and parameter usage but lacks information on output format, error conditions, or prerequisites (e.g., document must be in a pending state), leaving gaps for the agent.

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

Parameters4/5

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

The description adds meaningful context beyond the schema, which has 100% coverage. It explains that reminders can be sent to multiple signers at once, custom messages are optional, and on-behalf-of sending is supported. This clarifies the practical use of parameters like receiverEmails and onBehalfOf, though it doesn't detail parameter interactions or edge cases.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Send reminder emails to signers for pending document signatures.' It specifies the verb ('send reminder emails'), resource ('signers'), and scope ('pending document signatures'), distinguishing it from sibling tools like send_document_from_template or revoke_document that handle different document-related actions.

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

Usage Guidelines3/5

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

The description implies usage context by mentioning 'pending document signatures' and 'outstanding signature requests,' suggesting it should be used when reminders are needed. However, it does not explicitly state when to use this tool versus alternatives (e.g., send_document_from_template for initial sending) or provide exclusions, leaving some ambiguity for the agent.

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.

9 tool updatesv1.0.0Jan 2, 2026

Changedlist_contacts11 fields changed

changedInput schema / properties / contactType / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "enum": [
-          "MyContacts",
-          "AllContacts"
-        ],
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "MyContacts",
+      "AllContacts"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / page / description

Removed value: -"Required. The page number of the contact list to retrieve. Used for pagination to navigate through the list of available contacts."

addedInput schema / properties / page / maximum
```
Added value: +9007199254740991
```

removedInput schema / properties / pageSize / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "maximum": 100,
-        "minimum": 1,
-        "type": "integer"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / pageSize / default
```
Removed value: -10
```

removedInput schema / properties / pageSize / description

Removed value: -"Optional. Specifies the maximum number of contact records to be retrieved per page. If not provided, a default page size will be used by the BoldSign API. The value must be between 1 and 100. The default value is 10."

addedInput schema / properties / pageSize / maximum
```
Added value: +100
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```
addedInput schema / properties / pageSize / type
```
Added value: +"integer"
```

changedInput schema / properties / searchKey / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / required

Added value: +[
+  "pageSize",
+  "page",
+  "contactType"
+]

Changedlist_documents39 fields changed

removedInput schema / properties / brandIds / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Unique identifier (ID) of the brand.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / brandIds / items

Added value: +{
+  "description": "Unique identifier (ID) of the brand.",
+  "type": "string"
+}

addedInput schema / properties / brandIds / type
```
Added value: +"array"
```

removedInput schema / properties / dateFilterType / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "enum": [
-          "SentBetween",
-          "Expiring"
-        ],
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / dateFilterType / enum
```
Added value: +[
+  "SentBetween",
+  "Expiring"
+]
```
addedInput schema / properties / dateFilterType / type
```
Added value: +"string"
```

changedInput schema / properties / endDate / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/startDate/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date-time",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / labels / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Label of the document.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / labels / default
```
Added value: +[]
```

addedInput schema / properties / labels / items

Added value: +{
+  "description": "Label of the document.",
+  "type": "string"
+}

addedInput schema / properties / labels / type
```
Added value: +"array"
```

removedInput schema / properties / nextCursor / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "number"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / nextCursor / type
```
Added value: +"number"
```

removedInput schema / properties / page / description

Removed value: -"Required. The page number to retrieve, starting from 1. Used for pagination to navigate through the list of available documents."

addedInput schema / properties / page / maximum
```
Added value: +9007199254740991
```

removedInput schema / properties / pageSize / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "maximum": 100,
-        "minimum": 1,
-        "type": "integer"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / pageSize / default
```
Removed value: -10
```

removedInput schema / properties / pageSize / description

Removed value: -"Optional. The maximum number of documents to display per page. Defaults to 10 but can be set between 1 and 100."

addedInput schema / properties / pageSize / maximum
```
Added value: +100
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```
addedInput schema / properties / pageSize / type
```
Added value: +"integer"
```

removedInput schema / properties / recipients / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Email address of the signer.",
-          "format": "email",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / recipients / items

Added value: +{
+  "description": "Email address of the signer.",
+  "format": "email",
+  "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+  "type": "string"
+}

addedInput schema / properties / recipients / type
```
Added value: +"array"
```

changedInput schema / properties / searchKey / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / sentBy / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Email address of the sender.",
-          "format": "email",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / sentBy / items

Added value: +{
+  "description": "Email address of the sender.",
+  "format": "email",
+  "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+  "type": "string"
+}

addedInput schema / properties / sentBy / type
```
Added value: +"array"
```

changedInput schema / properties / startDate / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "format": "date-time",
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date-time",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / status / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "default": "None",
-          "enum": [
-            "None",
-            "WaitingForMe",
-            "WaitingForOthers",
-            "NeedAttention",
-            "Completed",
-            "Declined",
-            "Revoked",
-            "Expired",
-            "Scheduled",
-            "Draft"
-          ],
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / status / default
```
Added value: +[]
```

changedInput schema / properties / status / description

Previous value: -"Optional. Filter documents based on their current status. Available statuses include 'WaitingForMe', 'WaitingForOthers', 'NeedAttention', 'Completed', 'Declined', 'Revoked', 'Expired', 'Scheduled', and 'Draft'. Use 'None' to disable status filtering."New value: +"Optional. Filter documents based on their current status."

addedInput schema / properties / status / items

Added value: +{
+  "default": "None",
+  "enum": [
+    "None",
+    "WaitingForMe",
+    "WaitingForOthers",
+    "NeedAttention",
+    "Completed",
+    "Declined",
+    "Revoked",
+    "Expired",
+    "Scheduled",
+    "Draft"
+  ],
+  "type": "string"
+}

addedInput schema / properties / status / type
```
Added value: +"array"
```

removedInput schema / properties / transmitType / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "enum": [
-          "Sent",
-          "Received",
-          "Both"
-        ],
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / transmitType / description

Previous value: -"Optional. Type of transmission. Can be 'Sent', 'Received', or 'Both'."New value: +"Optional. Type of transmission to filter documents if the user is both sender, recipient or both."

addedInput schema / properties / transmitType / enum

Added value: +[
+  "Sent",
+  "Received",
+  "Both"
+]

addedInput schema / properties / transmitType / type
```
Added value: +"string"
```

addedInput schema / required

Added value: +[
+  "pageSize",
+  "page",
+  "labels",
+  "transmitType",
+  "status"
+]

Changedlist_team_documents20 fields changed

changedInput schema / properties / brandIds / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Unique identifier (ID) of the brand.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "Unique identifier (ID) of the brand.",
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / dateFilterType / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "enum": [
-          "SentBetween",
-          "Expiring"
-        ],
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "SentBetween",
+      "Expiring"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / endDate / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/startDate/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date-time",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / labels / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Label of the document.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "Label of the document.",
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / nextCursor / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "number"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / page / description

Removed value: -"Required. The page number to retrieve, starting from 1. Used for pagination to navigate through the list of available team documents."

addedInput schema / properties / page / maximum
```
Added value: +9007199254740991
```

removedInput schema / properties / pageSize / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "maximum": 100,
-        "minimum": 1,
-        "type": "integer"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / pageSize / default
```
Removed value: -10
```

removedInput schema / properties / pageSize / description

Removed value: -"Optional. The maximum number of team documents to display per page. Defaults to 10 but can be set between 1 and 100."

addedInput schema / properties / pageSize / maximum
```
Added value: +100
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```
addedInput schema / properties / pageSize / type
```
Added value: +"integer"
```

changedInput schema / properties / searchKey / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / startDate / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "format": "date-time",
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date-time",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / status / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "default": "None",
-          "enum": [
-            "None",
-            "WaitingForMe",
-            "WaitingForOthers",
-            "NeedAttention",
-            "Completed",
-            "Declined",
-            "Revoked",
-            "Expired",
-            "Scheduled",
-            "Draft"
-          ],
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "default": "None",
+      "enum": [
+        "None",
+        "WaitingForMe",
+        "WaitingForOthers",
+        "NeedAttention",
+        "Completed",
+        "Declined",
+        "Revoked",
+        "Expired",
+        "Scheduled",
+        "Draft"
+      ],
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / teamId / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "The unique identifier (ID) of the team.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "The unique identifier (ID) of the team.",
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / transmitType / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "enum": [
-          "Sent",
-          "Received",
-          "Both"
-        ],
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "Sent",
+      "Received",
+      "Both"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / userId / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "The unique identifier (ID) of a user in the team.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "The unique identifier (ID) of a user in the team.",
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / required

Added value: +[
+  "pageSize",
+  "page",
+  "transmitType"
+]

Changedlist_teams10 fields changed

removedInput schema / properties / page / description

Removed value: -"Required. The page number to retrieve from the list of teams, starting from 1. Used for pagination to navigate through the list of available teams."

addedInput schema / properties / page / maximum
```
Added value: +9007199254740991
```

removedInput schema / properties / pageSize / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "maximum": 100,
-        "minimum": 1,
-        "type": "integer"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / pageSize / default
```
Removed value: -10
```

removedInput schema / properties / pageSize / description

Removed value: -"Optional. Specifies the maximum number of teams to retrieve per page. The value must be an integer between 1 and 100. By default, the BoldSign API retrieves 10 teams per page."

addedInput schema / properties / pageSize / maximum
```
Added value: +100
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```
addedInput schema / properties / pageSize / type
```
Added value: +"integer"
```

changedInput schema / properties / searchKey / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / required

Added value: +[
+  "pageSize",
+  "page"
+]

Changedlist_templates16 fields changed

changedInput schema / properties / brandIds / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "The unique identifier (ID) of the brand to be used for depicting a brand.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "The unique identifier (ID) of the brand to be used for depicting a brand.",
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / createdBy / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Email address of the template creator.",
-          "format": "email",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "Email address of the template creator.",
+      "format": "email",
+      "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / endDate / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/startDate/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date-time",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / page / description

Removed value: -"Required. The page number to retrieve the templates list. Used for pagination to navigate through the list of available templates."

addedInput schema / properties / page / maximum
```
Added value: +9007199254740991
```

removedInput schema / properties / pageSize / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "maximum": 100,
-        "minimum": 1,
-        "type": "integer"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / pageSize / default
```
Removed value: -10
```

removedInput schema / properties / pageSize / description

Removed value: -"Optional. Specifies the number of templates to retrieve per page. The value must be an integer between 1 and 100. If not provided, the BoldSign API defaults to a page size of 10."

addedInput schema / properties / pageSize / maximum
```
Added value: +100
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```
addedInput schema / properties / pageSize / type
```
Added value: +"integer"
```

changedInput schema / properties / searchKey / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / startDate / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "format": "date-time",
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date-time",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / templateLabels / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Label of the template.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "Label of the template.",
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / templateType / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "enum": [
-          "all",
-          "mytemplates",
-          "sharedtemplate"
-        ],
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "all",
+      "mytemplates",
+      "sharedtemplate"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / required

Added value: +[
+  "pageSize",
+  "page",
+  "templateType"
+]

Changedlist_users10 fields changed

removedInput schema / properties / page / description

Removed value: -"Required. The page number of the user list to retrieve. Used for pagination to navigate through the list of available users."

addedInput schema / properties / page / maximum
```
Added value: +9007199254740991
```

removedInput schema / properties / pageSize / anyOf

Removed value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "maximum": 100,
-        "minimum": 1,
-        "type": "integer"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / pageSize / default
```
Removed value: -10
```

removedInput schema / properties / pageSize / description

Removed value: -"Optional. Specifies the maximum number of user records to be retrieved per page. If not provided, a default page size will be used by the BoldSign API. The value must be between 1 and 100. The default value is 10."

addedInput schema / properties / pageSize / maximum
```
Added value: +100
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```
addedInput schema / properties / pageSize / type
```
Added value: +"integer"
```

changedInput schema / properties / search / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / required

Added value: +[
+  "pageSize",
+  "page"
+]

Changedrevoke_document4 fields changed

addedInput schema / properties / onBehalfOf / anyOf

Added value: +[
+  {
+    "format": "email",
+    "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / onBehalfOf / format
```
Removed value: -"email"
```
removedInput schema / properties / onBehalfOf / type
```
Removed value: -"string"
```

changedInput schema / required

Previous value: -[
-  "documentId",
-  "message",
-  "onBehalfOf"
-]New value: +[
+  "documentId",
+  "message"
+]

Changedsend_document_from_template18 fields changed

changedInput schema / properties / body / properties / allowScheduledSend / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/signerDetails/anyOf/0/anyOf/1/properties/signerOrder/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / brandId / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/existingFormFields/anyOf/0/anyOf/1/items/properties/id/anyOf/0/anyOf/1"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / cc / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "additionalProperties": false,
-          "description": "Email address of the CC recipients.",
-          "properties": {
-            "emailAddress": {
-              "description": "Email address of the CC recipient.",
-              "format": "email",
-              "type": "string"
-            }
-          },
-          "required": [
-            "emailAddress"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "additionalProperties": false,
+      "description": "Email address of the CC recipients.",
+      "properties": {
+        "emailAddress": {
+          "description": "Email address of the CC recipient.",
+          "format": "email",
+          "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+          "type": "string"
+        }
+      },
+      "required": [
+        "emailAddress"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / disableEmails / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "default": false,
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / disableExpiryAlert / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "default": false,
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / disableSMS / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "default": false,
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / enablePrintAndSign / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "default": false,
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / enableReassign / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "default": false,
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / enableSigningOrder / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "default": false,
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / expiryDays / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/signerDetails/anyOf/0/anyOf/1/properties/signerOrder/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / fileUrls / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "The URL of the file must be publicly accessible. The supported file formats are .pdf, .png, .jpg, and .docx. The preferred file format is .pdf. You can upload up to 25 files. Each document may have a maximum of 1000 pages and must be no larger than 25 MB in size.",
-          "format": "uri",
-          "minLength": 1,
-          "type": "string"
-        },
-        "maxItems": 25,
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "The URL of the file must be publicly accessible. The supported file formats are .pdf, .png, .jpg, and .docx. The preferred file format is .pdf. You can upload up to 25 files. Each document may have a maximum of 1000 pages and must be no larger than 25 MB in size.",
+      "format": "uri",
+      "minLength": 1,
+      "type": "string"
+    },
+    "maxItems": 25,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / hideDocumentId / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "default": false,
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / message / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/title/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / reminderSettings / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "additionalProperties": false,
-        "properties": {
-          "enableAutoReminder": {
-            "anyOf": [
-              {
-                "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-              },
-              {
-                "type": "null"
-              }
-            ],
-            "description": "A flag indicating whether automatic reminders should be enabled for this document."
-          },
-          "reminderCount": {
-            "anyOf": [
-              {
-                "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/signerDetails/anyOf/0/anyOf/1/properties/signerOrder/anyOf/0"
-              },
-              {
-                "type": "null"
-              }
-            ],
-            "description": "The maximum number of reminders to be sent to the signers."
-          },
-          "reminderDays": {
-            "anyOf": [
-              {
-                "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/signerDetails/anyOf/0/anyOf/1/properties/signerOrder/anyOf/0"
-              },
-              {
-                "type": "null"
-              }
-            ],
-            "description": "The number of days after which a reminder should be sent to the signers."
-          }
-        },
-        "type": "object"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "enableAutoReminder": {
+        "anyOf": [
+          {
+            "default": false,
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "A flag indicating whether automatic reminders should be enabled for this document."
+      },
+      "reminderCount": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "The maximum number of reminders to be sent to the signers."
+      },
+      "reminderDays": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "The number of days after which a reminder should be sent to the signers."
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / roles / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "additionalProperties": false,
-          "properties": {
-            "allowFieldConfiguration": {
-              "anyOf": [
-                {
-                  "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "This option enables the signer to add fields at their end while signing the document. If this option is set to false, the signer cannot add fields, and they must complete the assigned ones. By default, it is set to false."
-            },
-            "authenticationCode": {
-              "anyOf": [
-                {
-                  "$ref": "#/properties/body/properties/title/anyOf/0"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "The authentication access code that the signer must enter to access the document. This should be shared with the signer privately by the sender."
-            },
-            "authenticationType": {
-              "anyOf": [
-                {
-                  "anyOf": [
-                    {
-                      "not": {}
-                    },
-                    {
-                      "enum": [
-                        "None",
-                        "EmailOTP",
-                        "AccessCode",
-                        "SMSOTP"
-                      ],
-                      "type": "string"
-                    }
-                  ]
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "default": "None",
-              "description": "This is used to allow authentication for a specific signer. We have three types of authentication. They are AccessCode and EmailOTP. The default value is None."
-            },
-            "deliveryMode": {
-              "anyOf": [
-                {
-                  "anyOf": [
-                    {
-                      "not": {}
-                    },
-                    {
-                      "enum": [
-                        "Email",
-                        "SMS"
-                      ],
-                      "type": "string"
-                    }
-                  ]
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "The method by which the document should be delivered to the signer (e.g., 'Email', 'SMS'). When SMS is enabled, you should also provide the phone number."
-            },
-            "enableEmailOTP": {
-              "anyOf": [
-                {
-                  "anyOf": [
-                    {
-                      "not": {}
-                    },
-                    {
-                      "default": false,
-                      "type": "boolean"
-                    }
-                  ]
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "A flag indicating whether One-Time Password (OTP) via email should be enabled for this signer's authentication."
-            },
-            "enableQes": {
-              "anyOf": [
-                {
-                  "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "A flag indicating whether Qualified Electronic Signature (QES) should be enabled for this signer."
-            },
-            "existingFormFields": {
-              "anyOf": [
-                {
-                  "anyOf": [
-                    {
-                      "not": {}
-                    },
-                    {
-                      "items": {
-                        "additionalProperties": false,
-                        "properties": {
-                          "id": {
-                            "anyOf": [
-                              {
-                                "anyOf": [
-                                  {
-                                    "not": {}
-                                  },
-                                  {
-                                    "type": "string"
-                                  }
-                                ]
-                              },
-                              {
-                                "type": "null"
-                              }
-                            ],
-                            "description": "The unique identifier (ID) of the existing form field to be updated."
-                          },
-                          "index": {
-                            "description": "The index of an existing form field to be updated.",
-                            "type": "integer"
-                          },
-                          "isReadOnly": {
-                            "anyOf": [
-                              {
-                                "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/enableEmailOTP/anyOf/0"
-                              },
-                              {
-                                "type": "null"
-                              }
-                            ],
-                            "description": "Decides whether this form field is read only or not."
-                          },
-                          "name": {
-                            "anyOf": [
-                              {
-                                "$ref": "#/properties/body/properties/title/anyOf/0"
-                              },
-                              {
-                                "type": "null"
-                              }
-                            ],
-                            "description": "Optional name of the existing form field."
-                          },
-                          "value": {
-                            "anyOf": [
-                              {
-                                "$ref": "#/properties/body/properties/title/anyOf/0"
-                              },
-                              {
-                                "type": "null"
-                              }
-                            ],
-                            "description": "Optional value of the existing form field."
-                          }
-                        },
-                        "type": "object"
-                      },
-                      "type": "array"
-                    }
-                  ]
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Optional. An array of existing form fields to be updated in the document for a role. When needed this information can be fetch from the get template tool to find the fillable form field for each signers."
-            },
-            "phoneNumber": {
-              "anyOf": [
-                {
-                  "anyOf": [
-                    {
-                      "not": {}
-                    },
-                    {
-                      "additionalProperties": false,
-                      "properties": {
-                        "countryCode": {
-                          "description": "Country code.",
-                          "type": "string"
-                        },
-                        "number": {
-                          "description": "Phone number.",
-                          "type": "string"
-                        }
-                      },
-                      "required": [
-                        "countryCode",
-                        "number"
-                      ],
-                      "type": "object"
-                    }
-                  ]
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "The phone number of the signer, including the country code. Required for SMS authentication."
-            },
-            "privateMessage": {
-              "anyOf": [
-                {
-                  "$ref": "#/properties/body/properties/title/anyOf/0"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Displays a private message to the specified signer when they proceed to sign the document. You can include the instructions that the signer should know before signing the document."
-            },
-            "roleIndex": {
-              "description": "The index of the role, indicating the position of the signer in the signing process. Must be between 1 and 50.",
-              "maximum": 50,
-              "minimum": 1,
-              "type": "number"
-            },
-            "signerDetails": {
-              "anyOf": [
-                {
-                  "anyOf": [
-                    {
-                      "not": {}
-                    },
-                    {
-                      "additionalProperties": false,
-                      "properties": {
-                        "signerEmail": {
-                          "description": "The email address of the signer assigned to this role. This is where the signing invitation will be sent.",
-                          "type": "string"
-                        },
-                        "signerName": {
-                          "description": "The name of the signer assigned to this role.",
-                          "type": "string"
-                        },
-                        "signerOrder": {
-                          "anyOf": [
-                            {
-                              "anyOf": [
-                                {
-                                  "not": {}
-                                },
-                                {
-                                  "type": "number"
-                                }
-                              ]
-                            },
-                            {
-                              "type": "null"
-                            }
-                          ],
-                          "description": "The sequential order in which the signers in this role need to sign the document. Only relevant when 'enableSigningOrder' is true."
-                        }
-                      },
-                      "required": [
-                        "signerName",
-                        "signerEmail"
-                      ],
-                      "type": "object"
-                    }
-                  ]
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Optional. The signer information for a template role."
-            },
-            "signerRole": {
-              "anyOf": [
-                {
-                  "$ref": "#/properties/body/properties/title/anyOf/0"
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "Optional. The user defined role of the signer, which was specified while creating the template."
-            },
-            "signerType": {
-              "anyOf": [
-                {
-                  "anyOf": [
-                    {
-                      "not": {}
-                    },
-                    {
-                      "enum": [
-                        "Signer",
-                        "Reviewer"
-                      ],
-                      "type": "string"
-                    }
-                  ]
-                },
-                {
-                  "type": "null"
-                }
-              ],
-              "description": "The type of signer (e.g., 'Signer', 'Reviewer')."
-            }
-          },
-          "required": [
-            "roleIndex"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "allowFieldConfiguration": {
+          "anyOf": [
+            {
+              "default": false,
+              "type": "boolean"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "This option enables the signer to add fields at their end while signing the document. If this option is set to false, the signer cannot add fields, and they must complete the assigned ones. By default, it is set to false."
+        },
+        "authenticationCode": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "The authentication access code that the signer must enter to access the document. This should be shared with the signer privately by the sender."
+        },
+        "authenticationType": {
+          "anyOf": [
+            {
+              "enum": [
+                "None",
+                "EmailOTP",
+                "AccessCode",
+                "SMSOTP"
+              ],
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": "None",
+          "description": "This is used to allow authentication for a specific signer. We have three types of authentication. They are AccessCode and EmailOTP. The default value is None."
+        },
+        "deliveryMode": {
+          "anyOf": [
+            {
+              "enum": [
+                "Email",
+                "SMS"
+              ],
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "The method by which the document should be delivered to the signer (e.g., 'Email', 'SMS'). When SMS is enabled, you should also provide the phone number."
+        },
+        "enableEmailOTP": {
+          "anyOf": [
+            {
+              "default": false,
+              "type": "boolean"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "A flag indicating whether One-Time Password (OTP) via email should be enabled for this signer's authentication."
+        },
+        "enableQes": {
+          "anyOf": [
+            {
+              "default": false,
+              "type": "boolean"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "A flag indicating whether Qualified Electronic Signature (QES) should be enabled for this signer."
+        },
+        "existingFormFields": {
+          "anyOf": [
+            {
+              "items": {
+                "additionalProperties": false,
+                "properties": {
+                  "id": {
+                    "anyOf": [
+                      {
+                        "type": "string"
+                      },
+                      {
+                        "type": "null"
+                      }
+                    ],
+                    "description": "The unique identifier (ID) of the existing form field to be updated."
+                  },
+                  "index": {
+                    "description": "The index of an existing form field to be updated.",
+                    "maximum": 9007199254740991,
+                    "minimum": -9007199254740991,
+                    "type": "integer"
+                  },
+                  "isReadOnly": {
+                    "anyOf": [
+                      {
+                        "default": false,
+                        "type": "boolean"
+                      },
+                      {
+                        "type": "null"
+                      }
+                    ],
+                    "description": "Decides whether this form field is read only or not."
+                  },
+                  "name": {
+                    "anyOf": [
+                      {
+                        "type": "string"
+                      },
+                      {
+                        "type": "null"
+                      }
+                    ],
+                    "description": "Optional name of the existing form field."
+                  },
+                  "value": {
+                    "anyOf": [
+                      {
+                        "type": "string"
+                      },
+                      {
+                        "type": "null"
+                      }
+                    ],
+                    "description": "Optional value of the existing form field."
+                  }
+                },
+                "type": "object"
+              },
+              "type": "array"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Optional. An array of existing form fields to be updated in the document for a role. When needed this information can be fetch from the get template tool to find the fillable form field for each signers."
+        },
+        "phoneNumber": {
+          "anyOf": [
+            {
+              "additionalProperties": false,
+              "properties": {
+                "countryCode": {
+                  "description": "Country code.",
+                  "type": "string"
+                },
+                "number": {
+                  "description": "Phone number.",
+                  "type": "string"
+                }
+              },
+              "required": [
+                "countryCode",
+                "number"
+              ],
+              "type": "object"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "The phone number of the signer, including the country code. Required for SMS authentication."
+        },
+        "privateMessage": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Displays a private message to the specified signer when they proceed to sign the document. You can include the instructions that the signer should know before signing the document."
+        },
+        "roleIndex": {
+          "description": "The index of the role, indicating the position of the signer in the signing process. Must be between 1 and 50.",
+          "maximum": 50,
+          "minimum": 1,
+          "type": "number"
+        },
+        "signerDetails": {
+          "anyOf": [
+            {
+              "additionalProperties": false,
+              "properties": {
+                "signerEmail": {
+                  "description": "The email address of the signer assigned to this role. This is where the signing invitation will be sent.",
+                  "type": "string"
+                },
+                "signerName": {
+                  "description": "The name of the signer assigned to this role.",
+                  "type": "string"
+                },
+                "signerOrder": {
+                  "anyOf": [
+                    {
+                      "type": "number"
+                    },
+                    {
+                      "type": "null"
+                    }
+                  ],
+                  "description": "The sequential order in which the signers in this role need to sign the document. Only relevant when 'enableSigningOrder' is true."
+                }
+              },
+              "required": [
+                "signerName",
+                "signerEmail"
+              ],
+              "type": "object"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Optional. The signer information for a template role."
+        },
+        "signerRole": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Optional. The user defined role of the signer, which was specified while creating the template."
+        },
+        "signerType": {
+          "anyOf": [
+            {
+              "enum": [
+                "Signer",
+                "Reviewer"
+              ],
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "The type of signer (e.g., 'Signer', 'Reviewer')."
+        }
+      },
+      "required": [
+        "roleIndex",
+        "authenticationType"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / scheduledSendTime / anyOf

Previous value: -[
-  {
-    "$ref": "#/properties/body/properties/roles/anyOf/0/anyOf/1/items/properties/signerDetails/anyOf/0/anyOf/1/properties/signerOrder/anyOf/0"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / body / properties / title / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / body / required
```
Added value: +[
+  "expiryDays"
+]
```

Changedsend_reminder_for_document_sign4 fields changed

changedInput schema / properties / message / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Custom message content for the reminder email.",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / onBehalfOf / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Email address of the sender.",
-          "format": "email",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "email",
+    "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / receiverEmails / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "not": {}
-      },
-      {
-        "items": {
-          "description": "Email address of the signer.",
-          "format": "email",
-          "type": "string"
-        },
-        "type": "array"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "description": "Email address of the signer.",
+      "format": "email",
+      "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / receiverEmails / description

Previous value: -"Optional. One or more signer email addresses to send reminders for pending signatures. If multiple signers are required to sign the document, specify their email addresses. If there is not emails provided, it will send reminder to all pending signers."New value: +"Optional. One or more signer email addresses to send reminders for pending signatures. If multiple signers are required to sign the document, specify their email addresses. If there is not emails provided, it will send reminder to all pending signers. The signers of a document can be obtained from the document-properties tool, using the documentId."

14 tool updatesMay 15, 2025
- First observedget_contact
- First observedget_document_properties
- First observedget_team
- First observedget_template_properties
- First observedget_user
- First observedlist_contacts
- First observedlist_documents
- First observedlist_team_documents
- First observedlist_teams
- First observedlist_templates
- First observedlist_users
- First observedrevoke_document
- First observedsend_document_from_template
- First observedsend_reminder_for_document_sign

Deploy Server

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

TDQS

A3.7/5.0

Scored 2026-04-18 10:05 across 14 tools

Disambiguation4/5

Most tools are clearly distinct by resource type (e.g., contact, document, template, team, user) and action (get vs. list). However, list_documents and list_team_documents have overlapping purposes that could cause confusion about which to use for team-related document listings, and send_document_from_template lacks a complementary create_document tool, creating a minor gap in the action set.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, such as get_contact, list_contacts, revoke_document, and send_reminder_for_document_sign. The naming is predictable and uniform across all 14 tools, making it easy for agents to understand the pattern.

Tool Count5/5

With 14 tools, the count is well-scoped for a document signing and management server like BoldSign. It covers key resources (contacts, documents, templates, teams, users) with appropriate CRUD-like operations, avoiding both bloat and thin coverage, which is typical for such domains.

Completeness4/5

The tool set provides good coverage for retrieving and listing resources, with specific actions like revoke_document and send_reminder_for_document_sign. However, there are notable gaps: no create_document (only send_document_from_template), no update or delete operations for contacts, templates, teams, or users, and no tools for managing document signatures or status changes beyond revocation, which could limit agent workflows.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
PandaDoc MCP ServerOAuth
com.pandadoc.mcp
PandaDoc MCP server for creating, sending, signing, and tracking PandaDoc documents.
Workplace & Productivity Legal & Compliance Project Management
22
mcp-serverOAuth
com.pdfgate
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
Documentation Access File Systems
1

Related MCP Servers

OpsLevel MCPofficial
Developer Tools Observability Monitoring
OpsLevel
A
license
Not graded
quality
C
maintenance
Model Context Protocol (MCP) server for OpsLevel
Updated 2 months ago (2026-07-10 16:15 UTC)
12
MIT
MCP REST API Server
Developer Tools Code Execution
vinaykp
F
license
Not graded
quality
D
maintenance
A server implementation of the Model Context Protocol (MCP) that provides REST API endpoints for managing and interacting with MCP resources.
Updated a year ago (2025-06-01 03:08 UTC)
-
mcp-dropbox-sign
App Automation Legal & Compliance Workplace & Productivity
bmbouter
A
license
Not graded
quality
B
maintenance
MCP server for the Dropbox Sign API supporting signature requests, templates, teams, accounts, events, documents, signers, reports, bulk operations, and workflows.
Updated a month ago (2026-07-30 17:44 UTC)
MIT
Apideck MCPofficial
Cloud Platforms CRM File Systems
apideck-libraries
A
license
A
quality
A
maintenance
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Updated a month ago (2026-08-10 08:18 UTC)
4
223
17
MIT

BoldSign MCP Server

Prerequisites

Installation

Environment Variables

Install in Cursor

Install in Windsurf

Install in VS Code

Install in Claude Desktop

Install in Cline

Available Tools

Documents

Templates

Contacts

Users

Teams

Repository

Bug Tracker

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

OpsLevel MCPofficial

Apideck MCPofficial