BoldSign MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct, targeting specific resources like contacts, documents, teams, templates, and users. However, there is some overlap between list_documents and list_team_documents, which could cause confusion about which to use for different document scopes, though descriptions help clarify the difference.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern, such as get_contact, list_contacts, revoke_document, and send_document_from_template. This uniformity makes the tool set predictable and easy to navigate for an agent.
Tool Count5/5
With 14 tools, the server is well-scoped for managing a document signing platform like BoldSign. It covers key resources and operations without being overwhelming, allowing agents to handle typical workflows efficiently.
Completeness4/5
The tool set provides good coverage for core operations like retrieving, listing, and sending documents, with specific actions like revoking and sending reminders. However, there are minor gaps, such as the lack of tools for creating or updating contacts, templates, or teams, which might require workarounds in some scenarios.
Average 3.5/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It mentions pagination but not how it works (e.g., default page size, total count handling). It doesn't disclose rate limits, error conditions, or what 'retrieves' entails (e.g., read-only, safe operation). The description is functional but misses key behavioral traits for a tool with 9 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 a single, efficient sentence that front-loads the core action and enumerates filtering options. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., separating core purpose from parameter list). Overall, it's appropriately concise for the complexity.
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 tool with 9 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers what the tool does and its parameters at a high level, but lacks behavioral context (e.g., safety, performance) and output details. Given the schema's good coverage, it's minimally viable but could better address gaps like usage scenarios or result format.
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 documents most parameters well. The description lists all 9 parameters by name, adding minimal semantic value beyond the schema (e.g., 'search key' is described similarly in both). It doesn't explain interactions between parameters or provide examples, so it meets the baseline for high schema coverage without significant enhancement.
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 ('BoldSign templates'), and specifies it's paginated. It distinguishes from siblings like 'get_template_properties' by focusing on listing rather than getting properties, but doesn't explicitly contrast with other list tools like 'list_documents' or 'list_contacts' beyond mentioning templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as authentication or permissions, or compare with other list tools (e.g., 'list_documents' for documents vs. templates). The description only lists filtering options without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions pagination and filtering but doesn't disclose important behavioral traits: authentication requirements, rate limits, what 'details' the search term covers (name, email, etc.), default sorting, or error conditions. The description is insufficient for a mutation-free but potentially complex list 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 a single, well-structured sentence that efficiently conveys the core functionality. It's front-loaded with the main purpose and includes key modifiers. However, it could be slightly more concise by integrating the optional nature of filtering more smoothly.
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 list tool with 3 parameters, 33% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on authentication, rate limits, search scope, pagination behavior, error handling, and output format. The agent would struggle to use this tool correctly without additional context.
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 only 33% (only 'search' has a description). The description adds that filtering is 'optional' and by 'search term', which partially compensates but doesn't explain the semantics of 'pageSize' and 'page' parameters. It doesn't clarify what 'page' 1 represents or how pagination works with filtering.
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 ('BoldSign users'), and specifies it's a 'paginated list' with 'optional filtering'. However, it doesn't explicitly differentiate from sibling tools like 'list_contacts' or 'get_user', which would require more specific scope clarification.
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_user' (for single user) or 'list_contacts'. It mentions optional filtering but doesn't explain when filtering is appropriate or what the search term targets beyond 'details'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool 'creates and sends a document for signing,' which implies a write/mutation operation, but doesn't disclose critical behavioral traits: whether this is an irreversible action, what permissions are required, rate limits, error conditions, or what happens after sending (e.g., document status changes). The description is minimal and lacks necessary context for safe invocation.
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 concise with two sentences that efficiently state the core purpose. It's front-loaded with the main action ('Initiates the process of sending a document based on a pre-defined template') and follows with key capabilities. There's no wasted text, though it could be slightly more structured by separating purpose from capabilities more clearly.
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 complexity of this tool (2 parameters with extensive nested objects, no annotations, no output schema), the description is inadequate. It doesn't explain what happens after successful invocation (e.g., returns a document ID, triggers email notifications), doesn't mention error handling, and provides no context about the sending process lifecycle. For a mutation tool with significant parameter complexity, this minimal description leaves too many gaps for effective agent 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 already documents all parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'recipients, form field values, and various sending options' which loosely maps to 'roles', 'existingFormFields', and other body properties. However, it doesn't provide additional semantic context, usage examples, or clarify relationships between parameters beyond what's in the schema descriptions.
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 retrieving information. However, it doesn't explicitly differentiate from 'send_reminder_for_document_sign' which is a related but distinct operation.
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. It doesn't mention prerequisites (e.g., needing a template ID from 'list_templates'), when to use template-based sending versus other document creation methods, or exclusions. The only implicit context is that it's for sending documents from templates, but no explicit usage boundaries are defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions pagination and filtering, which adds some behavioral context, but it lacks details on permissions required, rate limits, error handling, or what the response format looks like (e.g., structure of returned team details). For a read operation with no annotation coverage, this is a significant gap in transparency.
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 and then detailing capabilities in a single, efficient sentence. Every sentence adds value without redundancy, though it could be slightly more structured by separating key points into bullet points for clarity.
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 no annotations and no output schema, the description provides basic context on purpose and parameters but lacks completeness. It doesn't cover response format, error cases, or integration details, which are important for a tool with 3 parameters and no structured output. It's adequate for minimal use but has clear gaps in fully informing the 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?
Schema description coverage is 33% (only 'searchKey' has a description), so the description must compensate. It adds meaning by explaining that filtering uses a search term to match team details like name and that pagination navigates through pages, which clarifies 'pageSize' and 'page' beyond the schema's numeric constraints. However, it doesn't fully detail all parameters (e.g., default values or practical limits), leaving some gaps.
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 ('Retrieve') and resource ('paginated list of teams within your BoldSign organization'), specifying it fetches team details like name, users, and dates. It distinguishes from siblings like 'get_team' by indicating it lists multiple teams rather than retrieving a single one, though it doesn't explicitly compare to other list tools like 'list_contacts' or 'list_users'.
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 fetching multiple teams with filtering and pagination, but it doesn't explicitly state when to use this tool versus alternatives like 'get_team' for a single team or other list tools for different resources. No guidance on prerequisites or exclusions is provided, leaving usage context inferred rather than defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states the tool retrieves details but does not mention whether it's read-only, requires authentication, has rate limits, or what the return format looks like. For a tool with no annotation coverage, this leaves significant behavioral traits undisclosed, though it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 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 highly concise and easy to parse.
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 (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameter source but lacks details on behavioral aspects like authentication or return format. For a simple retrieval tool, this is minimally viable but leaves gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 100% coverage for the single parameter 'templateId'. It mentions the ID is 'unique' and can be obtained from another tool, but this is already implied in the schema's description. With high schema coverage, the baseline is 3, as the description doesn't significantly enhance parameter understanding.
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 ('detailed properties and settings of a specific BoldSign template'), making the purpose evident. It distinguishes from siblings like 'list_templates' by focusing on a single template's details rather than listing multiple. However, it doesn't explicitly contrast with 'get_document_properties' or 'get_contact', leaving some sibling differentiation incomplete.
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 mentioning the template ID can be obtained from 'list templates tool', suggesting a workflow. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_document_properties' or 'list_templates', and does not specify prerequisites or exclusions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool retrieves detailed information and requires a contact ID, but lacks behavioral traits such as error handling, rate limits, authentication needs, or response format. The description is neutral and doesn't contradict annotations, but offers minimal behavioral context beyond basic 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 two sentences, front-loaded with the tool's purpose and usage. The first sentence clearly states the action and resource, while the second adds context about contacts and parameter sourcing. It avoids redundancy and is appropriately sized, though the second sentence could be more concise by focusing solely on parameter guidance.
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 no annotations and no output schema, the description is moderately complete for a simple read operation. It covers the purpose, parameter context, and general use of contacts, but lacks details on return values, error cases, or integration with sibling tools. For a tool with one parameter and no complex behaviors, it meets minimum viability but leaves gaps in full contextual understanding.
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 'id' fully documented in the schema as 'the unique identifier (ID) of the contact to retrieve.' The description adds that the ID 'can be obtained from the list contacts tool,' providing useful context on sourcing the parameter, but doesn't add significant meaning beyond the schema. 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 'retrieves detailed information for a specific contact' using the BoldSign API, specifying the verb (retrieve) and resource (contact). It distinguishes from sibling 'list_contacts' by focusing on a single contact rather than listing multiple, though it doesn't explicitly name the sibling. The purpose is specific and actionable.
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 contacts are 'primarily used to store signer details... for use when creating and sending documents for signature,' which suggests context in document workflows. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_user' or 'list_contacts,' and does not mention prerequisites or exclusions beyond needing the contact ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 authorization requirements and error handling for unauthorized access, which is valuable behavioral context. However, it doesn't mention rate limits, pagination, or response format details. The description adds meaningful context but falls short of fully covering 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?
The description is appropriately sized at three sentences, front-loaded with the core purpose. Each sentence adds value: purpose, authorization context, and response/error details. There's minimal redundancy, though the second sentence could be slightly more concise by integrating authorization details into the first.
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 no annotations and no output schema, the description provides adequate context for a simple read tool with one parameter. It covers purpose, authorization, and basic error handling. However, it lacks details on response structure (e.g., what 'comprehensive details' include beyond listed examples) and doesn't address potential complexities like rate limits or pagination, leaving gaps in 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%, with the single parameter 'documentId' well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples or format details). Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with extra insights.
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' with the verb 'retrieve' and resource 'document properties'. It distinguishes from siblings like 'list_documents' (which lists multiple documents) and 'revoke_document' (which modifies document status). However, it doesn't explicitly contrast with 'get_template_properties' or 'list_team_documents', which might have overlapping retrieval aspects.
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 'authorized users, including senders, signers, team admins, and account admins' and mentions unauthorized access handling. However, it lacks explicit guidance on when to use this tool versus alternatives like 'list_documents' for summaries or 'get_template_properties' for template details. No clear 'when-not' or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool retrieves detailed information, which implies a read-only operation, but does not specify behavioral traits such as authentication requirements, rate limits, error handling, or what 'detailed information' entails. The description adds basic context but lacks depth for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to understand 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 (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on output format, error cases, or integration with sibling tools. Without annotations or output schema, more context on behavior would improve completeness, but it meets the minimum for a simple retrieval tool.
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 the single parameter 'userId'. The description adds no additional meaning beyond what the schema provides (e.g., it does not explain format constraints or examples). With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate but also does not detract.
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 evident. However, it does not explicitly differentiate from sibling tools like 'list_users' beyond the 'specific' qualifier, which is implied but not stated as a distinction.
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 'list users tool' in the schema, suggesting when to use this tool (for a specific user) versus 'list_users' (for multiple users). However, it lacks explicit guidance on when to choose this over alternatives like 'get_contact' or 'get_team', and does not mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 effectively describes the paginated nature, filtering options, and data fields returned (status, sender, recipient, etc.), which are valuable behavioral traits. However, it doesn't mention authentication requirements, rate limits, error conditions, or whether this is a read-only operation (though implied by 'Retrieve').
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 with two sentences. The first sentence clearly states the core purpose, and the second adds valuable details about returned data and capabilities. There's minimal waste, though the list of data fields could be slightly more concise. The structure is front-loaded with the main purpose first.
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 basic purpose, data returned, and filtering capabilities, but doesn't address authentication, error handling, response format details, or parameter dependencies. Given the complexity, more comprehensive guidance would be helpful.
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 85%, so the schema already documents most parameters well. The description adds some value by mentioning 'options for filtering and paginated navigation' and listing example data fields, but doesn't provide additional semantic context beyond what's in the parameter descriptions. It doesn't explain parameter interactions or provide usage examples.
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 ('available in your My Documents section'). It distinguishes from siblings like 'list_team_documents' by specifying the personal document scope, and from 'get_document_properties' by focusing on listing rather than retrieving detailed properties of a single document.
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 ('Retrieve a paginated list of documents available in your My Documents section'), but doesn't explicitly state when not to use it or name specific alternatives. It implies usage for listing personal documents with filtering capabilities, but lacks explicit exclusions or comparisons to sibling tools like 'list_team_documents'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, permission requirements (admin roles), and error conditions (unauthorized response). However, it doesn't mention rate limits, response format, or what happens with large result sets beyond pagination. The behavioral disclosure is adequate but incomplete for a tool with 13 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 appropriately sized (3 sentences) and front-loaded with core purpose. Every sentence adds value: first states purpose, second explains permissions, third covers filtering and error conditions. Minor room for improvement in sentence flow, but overall efficient.
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 purpose, permissions, and filtering scope, but lacks details about response format, pagination mechanics beyond mentioning 'paginated list', and error handling beyond unauthorized response. Given the complexity, 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 85%, so the baseline is 3. The description adds value by summarizing filtering capabilities ('filtering based on status, user ID, team ID, document details, transmission type, and date range'), which helps the agent understand the parameter categories. However, it doesn't provide additional semantic context beyond what's already in the detailed 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' and resource 'paginated list of documents' with specific location 'Team Documents section of your BoldSign organization'. It distinguishes from siblings like list_documents by specifying team context and from list_teams by focusing on documents rather than 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 about when to use this tool: for team documents with specific admin permissions (team admins vs account admins). It mentions unauthorized response for non-admins. However, it doesn't explicitly contrast with alternatives like list_documents or provide when-not-to-use guidance beyond permission requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 adequately describes the core action (sending reminder emails) and mentions capabilities like multiple signers and custom messages. However, it doesn't address important behavioral aspects like rate limits, authentication requirements, whether this triggers notifications, or what happens if reminders are sent too frequently.
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 at three sentences, front-loading the core purpose. Each sentence adds value: the first states the purpose, the second explains capabilities, and the third addresses the 'on behalf of' scenario. There's minimal redundancy, though the structure 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?
For a 4-parameter mutation tool with no annotations and no output schema, the description provides adequate but not comprehensive coverage. It explains what the tool does and when to use it, but lacks details about return values, error conditions, side effects, or system limitations that would be important for an AI agent to understand the full behavioral context.
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?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description mentions 'document ID and recipient email addresses' and 'custom messages can be included', which aligns with but doesn't significantly enhance the schema's parameter documentation. 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 tool's purpose with specific verbs ('send reminder emails') and resources ('to signers for pending document signatures'). It distinguishes itself from sibling tools like 'send_document_from_template' by focusing specifically on reminder functionality rather than initial document sending.
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 ('to remind signers about outstanding signature requests') and mentions that signer information can be obtained from the 'document-properties tool'. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses this is a read operation ('Retrieve') and mentions access to specific properties, but lacks details on permissions, rate limits, or error handling. It's adequate but has gaps for a tool with no annotation support.
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?
It's front-loaded with the core purpose in the first sentence, followed by supporting details. Every sentence adds value: the first defines the action, the second lists properties and ID requirement. No 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 simple read tool with 1 parameter and no output schema, the description covers purpose and usage adequately. However, with no annotations, it could benefit from more behavioral context like response format or error cases, making it minimally viable but not fully comprehensive.
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 teamId parameter fully. The description adds no additional parameter details beyond implying it's used for retrieval, meeting the baseline of 3 when 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 verb ('Retrieve') and resource ('detailed information about an existing team'), specifying it's for a BoldSign organization. It distinguishes from siblings like list_teams by focusing on a single team via ID, not 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?
It provides clear context: use this to get details for a specific team by ID, implying an alternative is list_teams for multiple teams. However, it doesn't explicitly state when not to use it or name alternatives directly, keeping it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 capabilities, and contact types. However, it doesn't mention authentication requirements, rate limits, error conditions, or what the response structure looks like (though there's no output schema).
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 with two focused sentences. The first sentence efficiently covers the core functionality and all parameters. The second provides valuable context about contact usage. There's minimal redundancy, though the structure could be slightly more front-loaded.
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 4 parameters and no output schema, the description provides adequate coverage of what the tool does and its parameters. However, without annotations or output schema, it lacks details about authentication, error handling, response format, and explicit sibling tool differentiation that would make it more complete.
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 50% (2 of 4 parameters have descriptions). The description compensates well by explaining all four parameters' purposes: page navigation, results per page, search filtering, and contact type selection. It adds meaningful context beyond what little schema documentation exists.
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 with specific verbs ('retrieve', 'display', 'filter') and resources ('paginated list of contacts from your BoldSign organization'). It distinguishes itself from sibling tools like 'get_contact' by focusing on listing multiple contacts rather than retrieving a single one, and from other list tools by specifying the contact domain.
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 retrieve contacts for use in document signing workflows. It implicitly distinguishes from 'get_contact' by handling lists vs. single contacts, but doesn't explicitly state when to choose this over alternatives like 'list_users' or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 precondition ('in-progress status documents'), and the actor requirement ('sender of the document'). It doesn't mention error conditions or response format, but covers the essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded and efficient. The first sentence establishes the core action, the second explains the consequence, and the third specifies the precondition. Every sentence 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.
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 does well by explaining the irreversible effect, actor requirements, and document status precondition. It could be more complete by mentioning error scenarios or response format, but covers the critical context given the tool's complexity.
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, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.
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 ('revoke'), resource ('document'), and scope ('signing process'). It distinguishes this tool from sibling tools like 'list_documents' or 'send_document_from_template' by focusing on termination rather than creation or retrieval.
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 ('on the in-progress status documents') and the role requirement ('by the sender of the document'). However, it doesn't explicitly mention when NOT to use it or name specific alternatives for related actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![boldsign-mcp MCP server](https://glama.ai/mcp/servers/Synctest-hub/boldsign-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Synctest-hub/boldsign-mcp)

Score Badge

Copy to your README.md:

[![boldsign-mcp MCP server](https://glama.ai/mcp/servers/Synctest-hub/boldsign-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Synctest-hub/boldsign-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Synctest-hub/boldsign-mcp'

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