Connect LiveHelpNow to Claude: Manage Tickets and Engage Visitors

If your support or customer success teams need to connect LiveHelpNow to Claude to automate ticket resolution, analyze live chat transcripts, or audit operator performance, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's function-calling capabilities and LiveHelpNow's REST API. You can either write, host, and maintain this server infrastructure yourself, or use a managed platform like Truto to dynamically generate a secure, authenticated MCP server URL.

This article focuses specifically on configuring Claude. If your team uses ChatGPT, check out our sibling guide on connecting LiveHelpNow to ChatGPT. If you are building custom autonomous agents, explore our architectural overview on connecting LiveHelpNow to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling support ecosystem like LiveHelpNow presents an immediate engineering challenge. You have to handle credential lifecycles, map verbose JSON schemas to MCP tool definitions, and handle specific domain constraints around how LiveHelpNow structures tickets, callbacks, and analytics. Every time the vendor updates an endpoint, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for LiveHelpNow, connect it natively to Claude Desktop, and execute complex support workflows using natural language.

The Engineering Reality of the LiveHelpNow API

A custom MCP server is essentially a self-hosted integration proxy. While the open MCP standard provides a predictable way for models to discover tools over JSON-RPC, the reality of implementing it against specialized B2B APIs is painful. LiveHelpNow is built to manage omnichannel customer support - handling tickets, live chats, surveys, and operator routing. Its API reflects that complexity.

If you decide to build a custom LiveHelpNow MCP server from scratch, here are the specific integration challenges your engineering team will face:

Strictly Segregated Analytics vs. Operational Endpoints LiveHelpNow treats real-time operational data (like active chats or tickets) completely differently from historical analytics. Most analytics endpoints - such as fetching chat surveys, operator activity, or department statistics - strictly require date_from and date_to parameters formatted exactly as YYYY-MM-DD. An LLM notoriously struggles with rigid date formatting unless explicitly constrained by strict JSON schemas. If Claude attempts to pass an ISO-8601 timestamp to the list_all_live_help_now_analytics_chat_surveys endpoint, the API will reject the payload. A managed MCP server abstracts this by strictly enforcing the schema shape before the request leaves the client.

Fragmented Entity Lifecycles for Tickets and Callbacks Unlike simpler Helpdesk APIs where a ticket is just a database record with a status field, LiveHelpNow enforces strict state machines. For example, you cannot simply update a callback record to "closed". You must first assign it to a specific operator and department (live_help_now_callbacks_assign), have the operator explicitly accept it (live_help_now_callbacks_accept), and optionally add a comment with a specific comment_type. Similarly, resolving a ticket via live_help_now_tickets_resolve requires not just changing the status, but submitting a dedicated solution payload. Exposing raw CRUD operations to Claude will result in invalid state transitions; you need tools that map to these specific lifecycle actions.

Polymorphic File Attachments Handling file uploads in LiveHelpNow requires understanding context. If an LLM needs to attach a log file to a customer interaction, it cannot just POST a file to a generic endpoint. The API splits attachment logic into context-assigned uploads (live_help_now_attachments_upload_context for active chat sessions) versus system-level uploads (live_help_now_attachments_upload_system for tickets or callbacks). An MCP server must provide distinct, clearly described tools so the model knows which endpoint to call based on the entity it is manipulating.

Generating the LiveHelpNow MCP Server

Truto abstracts these API quirks by automatically generating documentation-driven MCP tools from LiveHelpNow's endpoint definitions. The tools are exposed via a self-contained, authenticated URL.

You can generate this URL using either the Truto UI or the REST API.

Method 1: Via the Truto UI

For teams managing integrations manually, the UI provides a quick way to provision servers.

1. Log into your Truto environment and navigate to the integrated account page for your LiveHelpNow connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure the server. You can restrict the server to only allow read methods (to prevent Claude from modifying tickets) or filter by specific tags (like support or analytics).
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...). This URL contains a hashed cryptographic token representing the LiveHelpNow tenant.

Method 2: Via the Truto API

For platform engineers building scalable, multi-tenant AI products, you can provision LiveHelpNow MCP servers programmatically.

Make an authenticated POST request to the /integrated-account/:id/mcp endpoint:

curl -X POST https://api.truto.one/integrated-account/<livehelpnow_account_id>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Claude LiveHelpNow Support Server",
    "config": {
      "methods": ["read", "write"],
      "tags": ["tickets", "chats", "analytics"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The API provisions the server at the edge and returns the connection payload:

{
  "id": "mcp_abc123",
  "name": "Claude LiveHelpNow Support Server",
  "config": { "methods": ["read", "write"], "tags": ["tickets", "chats", "analytics"] },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

Connecting the MCP Server to Claude

Once you have the managed URL, connecting it to Claude is straightforward. Claude supports both a UI-based installation for desktop/web users and a configuration file approach for programmatic environments.

Method A: Via the Claude UI

If you are using Claude Desktop or the Claude Web interface with custom connector support:

1. Open Claude and navigate to Settings -> Integrations.
2. Click Add MCP Server (or Add Custom Connector).
3. Paste the Truto MCP URL (https://api.truto.one/mcp/a1b2c3d4e5f6...).
4. Click Add.

Claude will perform the JSON-RPC initialization handshake, discover the LiveHelpNow tools, and immediately make them available in the chat interface.

Method B: Via Manual Configuration File

If you are configuring Claude Desktop manually or running it in a headless agentic environment (like Cursor or a custom LangGraph setup), you can define the server in the claude_desktop_config.json file.

Because the Truto MCP server is accessible over standard HTTPS, you connect using the official @modelcontextprotocol/server-sse transport wrapper:

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

Restart Claude Desktop. The model now has direct, authenticated access to the LiveHelpNow instance.

Core LiveHelpNow Tools for Claude

When Claude connects, Truto dynamically derives the tool schemas from the LiveHelpNow API documentation. Claude uses these detailed descriptions and JSON Schemas to construct valid request payloads.

Here are 6 high-leverage hero tools exposed by the server.

list_all_live_help_now_tickets

Fetches a paginated list of support tickets. The tool returns extensive metadata including status, priority, category, source, has_attachments, and visitor_id. This is the starting point for any triage workflow.

"Claude, list all the high-priority open tickets in LiveHelpNow that have attachments, and summarize the core issue for each."

get_single_live_help_now_ticket_by_id

Retrieves the complete, detailed record for a specific ticket. Claude uses this to read the full body of the customer's request, check the assigned operator, and review any existing tags before making a decision.

"Get the full details for ticket ID 98234 and tell me if it has been assigned to the technical support department yet."

live_help_now_tickets_resolve

Executes the resolution state transition for a ticket. This tool requires the ticket_id, a solution string, and forces the comment_type to "resolved". It handles the specific API constraints required to properly close out a customer issue.

"Resolve ticket ID 98234. Use the following solution text: 'We have restarted your API gateway, and traffic is flowing normally.'"

list_all_live_help_now_analytics_operator_stats

Retrieves daily performance statistics for operators over a given date range. Returns critical support metrics like avg_chat_time_sec, total_online_time, chats_missed, and utilization rates.

"Fetch the operator statistics for last week (2026-10-01 to 2026-10-07) and identify which operator had the highest number of missed chats."

live_help_now_chats_list_history

Retrieves the historical messages for a specific chat session. It returns the sequence of interactions between the visitor and the operator, allowing Claude to read the transcript and perform sentiment analysis or summarize the interaction.

"Pull the chat history for session ID 112233 and summarize the customer's frustration points regarding our billing page."

list_all_live_help_now_callbacks

Lists pending callback requests from customers who opted not to wait on hold. Returns the status, assigned_operator, department_name, and customer details, enabling Claude to audit the callback queue.

"Check the callback queue. Are there any callbacks assigned to the billing department that have been pending for more than 4 hours?"

For the complete inventory of LiveHelpNow tools, schemas, and required parameters, refer to the LiveHelpNow integration page.

Workflows in Action

By chaining these tools together, Claude can execute multi-step operations that would traditionally require a human to manually click through the LiveHelpNow dashboard.

Workflow 1: Tier 1 Ticket Triage & Resolution

An IT administrator wants Claude to act as a first-line support agent, identifying simple password reset tickets, providing the standard solution, and resolving them automatically.

"Check our open LiveHelpNow tickets. Find any tickets related to 'password reset' or 'cannot login'. For each one, fetch the full details, then resolve the ticket with our standard password reset instructions."

How Claude executes this:

1. Calls list_all_live_help_now_tickets filtering for open statuses.
2. Analyzes the returned list to identify tickets matching the criteria.
3. Iterates over the matches, calling get_single_live_help_now_ticket_by_id to confirm the context of the issue.
4. Calls live_help_now_tickets_resolve for each ticket, passing the generated solution text.

sequenceDiagram
    participant User as User
    participant Claude as Claude Desktop
    participant MCP as Truto MCP Server
    participant API as LiveHelpNow API

    User->>Claude: "Find and resolve password reset tickets..."
    Claude->>MCP: Call list_all_live_help_now_tickets (status=open)
    MCP->>API: GET /tickets
    API-->>MCP: Return 3 open tickets
    MCP-->>Claude: JSON ticket array
    Claude->>Claude: Identify 1 password reset ticket (ID: 5543)
    Claude->>MCP: Call get_single_live_help_now_ticket_by_id (id=5543)
    MCP->>API: GET /tickets/5543
    API-->>MCP: Return full ticket details
    MCP-->>Claude: JSON ticket record
    Claude->>MCP: Call live_help_now_tickets_resolve (id=5543, solution=...)
    MCP->>API: POST /tickets/5543/resolve
    API-->>MCP: Success status
    MCP-->>Claude: Resolved confirmation
    Claude-->>User: "I found 1 password reset ticket (ID 5543) and successfully resolved it."

Workflow 2: Operator Performance Audit

A support manager wants to generate a weekly performance report to identify team members who might need coaching based on chat handle times.

"Audit our LiveHelpNow operator chat performance for the month of October. First, list all our departments to ensure we are looking at the 'Technical Support' team. Then, get the operator stats for that date range. Tell me who had the longest average chat times and summarize their utilization."

How Claude executes this:

1. Calls list_all_live_help_now_departments to get the department IDs and map operators to the Technical Support group.
2. Calls list_all_live_help_now_analytics_operators_stats passing date_from: "2026-10-01" and date_to: "2026-10-31".
3. Processes the nested statistical data, calculating averages across the daily stats arrays for each operator.
4. Formats the output into a concise report for the manager.

flowchart TD
    A["Call list_all_live_help_now_departments"] --> B{"Identify 'Technical Support' <br>Department ID"}
    B --> C["Call list_all_live_help_now_analytics_operators_stats <br>(date_from, date_to)"]
    C --> D["Filter stats by operators <br>in Technical Support"]
    D --> E["Analyze avg_chat_time_sec <br>and utilization metrics"]
    E --> F["Generate Performance <br>Report for User"]

Security and Access Control

When deploying AI agents against a production support platform, security is paramount. The Truto MCP architecture provides strict access controls embedded directly into the server URL:

• Method Filtering: You can configure the server to only allow read operations. This ensures Claude can query tickets, chat histories, and analytics, but cannot accidentally modify, resolve, or delete customer data.
• Tag Filtering: Limit the server's scope to specific domains. By passing tags: ["analytics"], Claude will only see tools related to reporting, hiding all operational ticket and callback tools.
• Expiration Controls: Set an expires_at timestamp when creating the server. The URL automatically becomes invalid after this date, managed by background cleanup tasks, making it ideal for temporary contractor access or limited-time audit workflows.
• Secondary Authentication: Enable require_api_token_auth to force Claude to pass a valid Truto user session or API token alongside the MCP URL, preventing unauthorized access even if the URL is leaked.
• Factual Note on Rate Limits: Truto does not automatically retry, throttle, or apply backoff logic when the LiveHelpNow API enforces rate limits. If you exceed LiveHelpNow's quotas, Truto passes the HTTP 429 error directly to Claude, alongside standardized IETF rate limit headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). Your agent or prompt framework is responsible for handling the backoff and retry logic.

Moving Forward with Agentic Support

Connecting Claude to LiveHelpNow bridges the gap between conversational AI and your actual customer support infrastructure. By utilizing an MCP server, you remove the heavy lifting of maintaining OAuth tokens, normalizing pagination, and deciphering opaque payloads. Instead of writing brittle Python scripts to scrape analytics or update tickets, you grant Claude a secure, tightly scoped set of tools to interact with LiveHelpNow directly.

Whether you are building internal triage bots, automating daily performance reporting, or executing complex ticket state transitions, a managed MCP architecture lets your engineering team focus on the agent's logic - not the API plumbing.