Connect BoloSign to Claude: Automate Templates and Form Responses

If you need to connect BoloSign to Claude to automate e-signatures, extract form responses, or dispatch PDF templates, you need a Model Context Protocol (MCP) server. This infrastructure layer acts as the translation engine between Claude's function calls and BoloSign's REST API. You can either build, host, and maintain this server yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP endpoint. If your team uses ChatGPT, check out our guide on connecting BoloSign to ChatGPT or explore our broader architectural overview on connecting BoloSign to AI Agents.

Giving a Large Language Model (LLM) read and write access to an e-signature platform is a massive engineering challenge. You must handle strict data validation, nested arrays for signers, Base64 document encoding, and unpredictable rate limits. Every time an API endpoint drifts or a schema updates, your custom integration breaks. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for BoloSign, connect it natively to Claude Desktop, and execute complex contract workflows using natural language.

The Engineering Reality of the BoloSign API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools over JSON-RPC, the reality of implementing it against an e-signature API is painful.

If you decide to build a custom MCP server for BoloSign, you own the entire API lifecycle. Here are the specific challenges you will face when mapping this API to an LLM:

Complex Nested Payload Structures Dispatching a PDF template in BoloSign is not a simple flat JSON request. It requires arrays of signers, deeply nested customVariables, and optional mailData to format the email dispatch. LLMs are notoriously bad at generating perfectly structured nested JSON from scratch. They frequently hallucinate keys or use the wrong data types for array elements. Truto solves this by extracting the exact JSON Schema from the integration's documentation and injecting explicit property descriptions, forcing Claude to format the tool call correctly.

Temporal Assets and Pagination When you query BoloSign for documents, the API returns signed assets as temporary URLs (finishedPdfUrl). Additionally, retrieving thousands of historical documents requires traversing cursor-based pagination. If you expose raw pagination tokens to an LLM, it will often attempt to guess the next page token or malform the cursor. Truto normalizes BoloSign's pagination into a standard limit and next_cursor schema, explicitly instructing the LLM to pass cursor values back unchanged.

Aggressive Rate Limiting Document generation and template rendering are computationally heavy tasks. E-signature APIs enforce strict rate limits to prevent abuse. A common mistake engineers make is attempting to build complex backoff logic directly into the MCP server or absorbing errors silently. Truto takes a different approach: it does not retry, throttle, or apply backoff on rate limit errors. When BoloSign returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers per the IETF specification (ratelimit-limit, ratelimit-remaining, ratelimit-reset). The caller (your LLM agent or framework) is entirely responsible for reading these headers and executing its own retry and backoff strategy.

sequenceDiagram
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant BoloSign as BoloSign API
    
    Claude->>Truto: call_tool (create_a_bolo_sign_pdf_template_lambda)
    Truto->>BoloSign: POST /v1/templates/dispatch
    BoloSign-->>Truto: 429 Too Many Requests (Rate Limited)
    Truto-->>Claude: JSON-RPC Error with IETF headers<br>(ratelimit-reset: 60)
    Note over Claude: Claude waits 60s<br>then retries execution
    Claude->>Truto: call_tool (create_a_bolo_sign_pdf_template_lambda)
    Truto->>BoloSign: POST /v1/templates/dispatch
    BoloSign-->>Truto: 200 OK (documentId: 12345)
    Truto-->>Claude: JSON-RPC Success

How to Generate a BoloSign MCP Server

Truto automatically generates MCP tools from an integration's resource definitions and documentation records. Rather than hand-coding endpoints, Truto reads the BoloSign configuration, applies any requested filters, and exposes the exact API surface your LLM needs.

You can generate your BoloSign MCP server via the Truto User Interface or programmatically via the API.

Method 1: Via the Truto UI

If you prefer a visual setup, generating an MCP server takes less than a minute.

1. Log into your Truto account and navigate to the Integrated Accounts page.
2. Select your connected BoloSign instance.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Configure the server (e.g., name it "BoloSign Contract Automation", select allowed methods like read or write).
6. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method 2: Via the Truto API

For platform engineers building automated provisioning pipelines, you can generate MCP servers programmatically.

Make a POST request to the /integrated-account/:id/mcp endpoint using your Truto API key. You can pass configuration filters in the body to restrict what the LLM is allowed to do.

curl -X POST "https://api.truto.one/integrated-account/YOUR_ACCOUNT_ID/mcp" \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "BoloSign Production Agent",
    "config": {
      "methods": ["read", "write"],
      "require_api_token_auth": false
    }
  }'

The API validates that the integration is AI-ready, hashes a secure token, and returns the endpoint URL:

{
  "id": "mcp_8f7d6e5c",
  "name": "BoloSign Production Agent",
  "config": { "methods": ["read", "write"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, you can connect it directly to Claude. Because Truto manages the protocol translation and authentication natively via the tokenized URL, there is no need to write local wrapper scripts.

Method A: Via the Claude UI

If you are using the Claude web interface or enterprise workspace, you can add the server directly through the UI settings.

1. Open Claude and navigate to Settings.
2. Locate the Integrations or Connectors section.
3. Click Add MCP Server or Add Custom Connector.
4. Paste your Truto MCP URL.
5. Click Add. Claude will immediately perform a JSON-RPC handshake to discover the BoloSign tools.

(Note: If you are connecting via ChatGPT instead of Claude, the process is nearly identical: go to Settings -> Apps -> Advanced settings, enable Developer Mode, and add the server URL under Custom Connectors).

Method B: Via the Claude Desktop Configuration File

If you are running Claude Desktop locally, you configure the MCP server by modifying the claude_desktop_config.json file. Truto provides Server-Sent Events (SSE) transport out of the box. Use the standard @modelcontextprotocol/server-sse package to proxy the connection.

{
  "mcpServers": {
    "bolosign_agent": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_TRUTO_TOKEN"
      ]
    }
  }
}

Restart Claude Desktop. The model will initialize the connection, read the tool schemas, and be ready to execute prompts against BoloSign.

BoloSign Hero Tools

Truto automatically translates BoloSign's API endpoints into callable tools with detailed JSON Schemas. Below are the core tools your agent will use to automate document dispatch and tracking.

list_all_bolo_sign_get_documents

This tool retrieves a paginated list of signature documents. It supports powerful filtering by search query, date ranges, document ID, and sorting. It returns critical metadata including documentId, status, authorEmail, and the finishedPdfUrl.

"Find all BoloSign documents created between January 1st and January 31st that currently have a 'pending' status. Return a list of their document names and IDs."

create_a_bolo_sign_pdf_template_lambda

This is the most critical writing tool in the integration. It dispatches a predefined BoloSign PDF or form template for signing. The schema accepts the template ID, a nested array of signers (with names and emails), and an array of customVariables to dynamically fill out fields inside the template.

"Send the 'Standard Mutual NDA' template to jane.doe@example.com and john.smith@example.com. Fill in the custom variable 'CompanyName' with 'Acme Corp'. Let me know when the request is successfully dispatched."

list_all_bolo_sign_get_template_respondents

When a template is sent out for signature, you need to track who has responded. This tool lists the respondents for a specific document or template, allowing the LLM to audit the isSigningOrder progress and verify which signers have completed their tasks.

"Check the respondent status for document ID 'doc_987654'. Tell me which signers have completed the document and who we are still waiting on."

list_all_bolo_sign_get_form_responses

If you use BoloSign for intake forms or questionnaires alongside signatures, this tool extracts the completed form responses. It returns the formId, the respondentEmail, and the structured response payload.

"Get the form responses for the 'Vendor Onboarding Questionnaire' submitted yesterday. Summarize the responses provided by vendor@external.com."

For the complete tool inventory and exact JSON Schema specifications, visit the BoloSign integration page.

Workflows in Action

Connecting BoloSign to Claude turns manual contract tracking into an autonomous workflow. By combining multiple tools in sequence, the LLM can orchestrate complex, multi-step operations.

Scenario 1: Automated NDA Dispatch and Verification

A recruiting manager asks Claude to handle the paperwork for a new hire.

"Send the standard employee NDA template to our new hire, alex.jones@example.com. Assign the 'EmployeeName' variable to 'Alex Jones'. Once sent, verify that the document appears in our pending queue."

Execution Steps:

1. Claude calls create_a_bolo_sign_pdf_template_lambda passing the template ID, the signer array [{ "name": "Alex Jones", "email": "alex.jones@example.com" }], and the custom variables.
2. BoloSign returns a successful 200 response with the newly generated documentId.
3. Claude immediately calls list_all_bolo_sign_get_documents filtering by the new documentId to confirm its status is pending.

Result: The user gets confirmation that the NDA was dispatched perfectly, along with the tracking ID, without ever opening the BoloSign dashboard.

flowchart TD
    A["User Prompt:<br>Send NDA to Alex"] --> B["Claude Engine"]
    B --> C["Call Tool:<br>create_a_bolo_sign_pdf_template_lambda"]
    C --> D{"API Rate Limit Check"}
    D -->|"200 OK"| E["Return documentId"]
    E --> F["Call Tool:<br>list_all_bolo_sign_get_documents"]
    F --> G["Confirm 'pending' status"]
    G --> H["Reply to User"]

Scenario 2: Form Response Auditing

A compliance officer needs to audit vendor questionnaires submitted last week.

"Fetch all completed vendor compliance forms submitted between October 10th and October 15th. Check the responses and flag any vendor who answered 'No' to the SOC2 compliance question."

Execution Steps:

1. Claude calls list_all_bolo_sign_get_documents using the dateFrom and dateTo parameters, filtering for completed form templates.
2. Claude iterates over the returned document IDs and calls list_all_bolo_sign_get_form_responses for each.
3. The LLM reads the structured JSON response payloads, parses the answers natively, and isolates the vendors who answered "No" to the specific compliance question.

Result: The user receives a concise, formatted list of non-compliant vendors, completing a manual audit task in seconds instead of hours.

Security and Access Control

Giving an AI agent access to sensitive contracts requires strict security controls. Truto MCP servers are self-contained and heavily governed by database-backed token configurations. You can secure your BoloSign MCP server using the following mechanisms:

• Method Filtering: Restrict the server to safe operations. By configuring methods: ["read"], the MCP server will silently drop any write tools like create_a_bolo_sign_pdf_template_lambda during generation, ensuring the LLM cannot accidentally dispatch contracts.
• Tag Filtering: You can group tools by tags (e.g., "hr_docs" vs "sales_contracts"). A server generated with specific tags will only expose endpoints matching those labels, creating strict domain boundaries for your agents.
• Require API Token Auth: By default, possession of the MCP URL is sufficient to connect. For enterprise deployments, set require_api_token_auth: true. This forces the MCP client to pass a valid Truto API token in the Authorization header, adding a mandatory second layer of identity verification.
• Expiration (TTL): Pass an ISO datetime to the expires_at field when creating the server. The token is stored in a distributed key-value store with an automatic TTL. Once expired, the server self-destructs, instantly revoking the LLM's access to the API.

Moving Beyond Manual Contract Management

Connecting BoloSign to Claude transforms your AI assistant from a simple text generator into an active participant in your legal and operational workflows. Instead of writing custom integration scripts, parsing complex nested schemas, or writing exponential backoff loops for rate limits, you can rely on Truto's managed architecture to handle the boilerplate.

By normalizing the protocol layer, enforcing strict method filters, and passing standardized rate limit headers down to the model, Truto ensures your AI agents interact with BoloSign safely and reliably.