Skip to main content
Glama

send_reminder_for_document_sign

Send reminder emails to signers for pending document signatures, allowing users to specify recipients and include custom messages to prompt completion of outstanding signature requests.

Instructions

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

Input Schema

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

Implementation Reference

  • The core handler function that implements the tool logic by calling the BoldSign DocumentApi.remindDocument method to send reminders to specified signers for a document.
    async function sendReminderForDocumentSignHandler(
      payload: SendReminderForDocumentSignSchemaType,
    ): Promise<McpResponse> {
      try {
        const documentApi = new DocumentApi();
        documentApi.basePath = configuration.getBasePath();
        documentApi.setApiKey(configuration.getApiKey());
        const reminderMessage: ReminderMessage = new ReminderMessage();
        reminderMessage.message = payload.message ?? undefined;
        reminderMessage.onBehalfOf = payload.onBehalfOf ?? undefined;
        const documentResponse: returnTypeI = await documentApi.remindDocument(
          payload.documentId,
          payload.receiverEmails ?? undefined,
          reminderMessage,
        );
        return handleMcpResponse({
          data: documentResponse?.response?.data ?? documentResponse,
        });
      } catch (error: any) {
        return handleMcpError(error);
      }
    }
  • Zod schema defining the input parameters: documentId (required), receiverEmails (optional array), message (optional), onBehalfOf (optional).
    const SendReminderForDocumentSignSchema = z.object({
      documentId: commonSchema.InputIdSchema.describe(
        'Required. The unique identifier (ID) of the document to send a reminder email to signers for pending signatures.',
      ),
      receiverEmails: z
        .array(commonSchema.EmailSchema.describe('Email address of the signer.'))
        .optional()
        .nullable()
        .describe(
          'Optional. One or more signer email addresses to send reminders for pending signatures. If multiple signers are required to sign the document, specify their email addresses. If there is not emails provided, it will send reminder to all pending signers. The signers of a document can be obtained from the document-properties tool, using the documentId.',
        ),
      message: commonSchema.OptionalStringSchema.describe(
        'Optional. Message to be sent in the reminder email. If not provided, the system will use a default reminder message.',
      ),
      onBehalfOf: commonSchema.EmailSchema.optional()
        .nullable()
        .describe(
          'Optional. Email address of the sender when creating a document on their behalf. This email can be retrieved from the `behalfOf` property in the get document or list documents tool.',
        ),
    });
  • MCP tool definition object including the tool name 'send_reminder_for_document_sign', description, input schema, and a wrapper handler that delegates to the core handler.
    export const sendReminderForDocumentToolDefinition: BoldSignTool = {
      method: ToolNames.SendReminderForDocumentSign.toString(),
      name: 'Send reminder for document sign',
      description:
        'Send reminder emails to signers for pending document signatures. This API allows users to remind signers about outstanding signature requests by specifying the document ID and recipient email addresses. Multiple signers can receive reminders at once, and custom messages can be included. If sending reminders on behalf of another sender, specify the relevant sender email addresses.',
      inputSchema: SendReminderForDocumentSignSchema,
      async handler(args: unknown): Promise<McpResponse> {
        return await sendReminderForDocumentSignHandler(args as SendReminderForDocumentSignSchemaType);
      },
    };
  • Registers the sendReminderForDocumentToolDefinition as part of the documents API tools array for collective export and likely higher-level registration.
    export const documentsApiToolsDefinitions: BoldSignTool[] = [
      getDocumentPropertiesToolDefinition,
      listDocumentsToolDefinition,
      listTeamDocumentsToolDefinition,
      sendReminderForDocumentToolDefinition,
      revokeDocumentToolDefinition,
    ];
  • Defines the canonical tool name string in the ToolNames enum.
    SendReminderForDocumentSign = 'send_reminder_for_document_sign',
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.

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/boldsign/boldsign-mcp'

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