boldsign

Official

by boldsign

Overview Schema Related Servers Score Discussions

TypeScript

Remote

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 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.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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/boldsign/boldsign-mcp/badges/card.svg)](https://glama.ai/mcp/servers/boldsign/boldsign-mcp)

Score Badge

Copy to your README.md:

[![boldsign-mcp MCP server](https://glama.ai/mcp/servers/boldsign/boldsign-mcp/badges/score.svg)](https://glama.ai/mcp/servers/boldsign/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/boldsign/boldsign-mcp'

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