Skip to main content
Glama
Synctest-hub

BoldSign MCP Server

get_contact

Retrieve detailed contact information from BoldSign using the contact's unique ID to access signer details for document signing workflows.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesRequired. The unique identifier (ID) of the contact to retrieve. This can be obtained from the list contacts tool.

Implementation Reference

  • The main handler function that creates a ContactsApi instance, configures it with base path and API key, fetches the contact details by ID, and returns a formatted McpResponse or handles errors.
    async function getContactHandler(payload: GetContactSchemaType): Promise<McpResponse> {
      try {
        const contactsApi = new ContactsApi();
        contactsApi.basePath = configuration.getBasePath();
        contactsApi.setApiKey(configuration.getApiKey());
        const contactsDetails: ContactsDetails = await contactsApi.getContact(payload.id);
        return handleMcpResponse({
          data: contactsDetails,
        });
      } catch (error: any) {
        return handleMcpError(error);
      }
    }
  • Zod schema defining the input for the get_contact tool, requiring a contact ID.
    const GetContactSchema = z.object({
      id: commonSchema.InputIdSchema.describe(
        'Required. The unique identifier (ID) of the contact to retrieve. This can be obtained from the list contacts tool.',
      ),
    });
  • Tool definition object that registers the 'get_contact' tool with its method name, description, input schema, and a wrapper handler delegating to the main handler.
    export const getContactToolDefinition: BoldSignTool = {
      method: ToolNames.GetContact.toString(),
      name: 'Get contact',
      description:
        'This tool utilizes the BoldSign API to retrieve detailed information for a specific contact within your organization. To use this tool, you need to provide the unique identifier (ID) of the contact you wish to retrieve. Contacts are primarily used to store signer details, identified by their unique email address, for use when creating and sending documents for signature within the BoldSign application.',
      inputSchema: GetContactSchema,
      async handler(args: unknown): Promise<McpResponse> {
        return await getContactHandler(args as GetContactSchemaType);
      },
    };
  • Array that includes the getContactToolDefinition as part of contacts API tools, which is further aggregated into the main tools list.
    export const contactsApiToolsDefinitions: BoldSignTool[] = [
      getContactToolDefinition,
      listContactsToolDefinition,
    ];
  • Main tools definitions array that spreads contactsApiToolsDefinitions, making get_contact available to the MCP server.
    export const definitions: BoldSignTool[] = [
      ...contactsApiToolsDefinitions,
      ...documentsApiToolsDefinitions,
      ...templatesApiToolsDefinitions,
      ...usersApiToolsDefinitions,
      ...teamsApiToolsDefinitions,
    ];
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.

Install Server

Other Tools

Latest Blog Posts

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