Connect Kaseya BMS to ChatGPT: Automate ticketing and client records

If you need to give your AI agents read and write access to Kaseya BMS, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between an LLM's function calls and the Kaseya BMS REST API. You can either build and maintain this infrastructure yourself or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses Claude, check out our guide on connecting Kaseya BMS to Claude or explore our broader architectural overview on connecting Kaseya BMS to AI Agents.

IT service providers and managed service providers (MSPs) live inside their Professional Services Automation (PSA) tools. Kaseya BMS handles ticketing, CRM, billing, and project management. However, giving a Large Language Model (LLM) access to this ecosystem is an engineering challenge. You have to map sprawling JSON schemas to MCP tool definitions, handle legacy authentication patterns, and navigate complex entity relationships. Every time a new custom field is added or a workflow state changes, your custom integration code risks breaking.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Kaseya BMS, connect it natively to ChatGPT, and execute complex support and account management workflows using natural language.

The Engineering Reality of the Kaseya BMS API

A custom MCP server is a self-hosted integration layer that translates an LLM's JSON-RPC 2.0 messages into HTTP REST requests. While Anthropic's open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against specific vendor APIs is painful.

If you decide to build a custom MCP server for Kaseya BMS, you own the entire API lifecycle. You are not just integrating "ticketing" - you are integrating CRM opportunities, embedded IT Glue documentation, QuickBooks Desktop synchronizations, and RMM alerts. Here are the specific integration challenges that break standard CRUD assumptions when working with Kaseya BMS:

The Internal ID Lookup Problem

LLMs operate on semantics. If an AI agent wants to log a ticket, it will try to set the issue type to "Hardware Failure". The Kaseya BMS API will reject this. Almost every entity creation or update in BMS requires strict internal numeric identifiers. You cannot pass string enums. Before an LLM can create a ticket or an opportunity, it must first execute a tool call against the lookup endpoints (like /accountcodes/lookups or /issuetypes/lookups), parse the massive response array, find the internal ID corresponding to the semantic string, and inject that ID into the final POST request payload. Your MCP server must expose dozens of these lookup endpoints as tools and instruct the LLM on how to chain them properly.

Embedded Sub-System Routing

Kaseya BMS acts as a proxy for external system integrations. For example, if you are reading QuickBooks Desktop bills or IT Glue contacts through the BMS API, the routing logic changes. To fetch QuickBooks data, you must pass an ExternalTenantId dynamically. For IT Glue, notes and assets are deeply coupled to BMS contact IDs. If your MCP server treats BMS as a flat API, the LLM will fail to construct the necessary cross-system requests. You must write explicit schema instructions telling the model exactly which tenant identifiers belong to which endpoints.

RPC-Style State Transitions

An LLM natively assumes that to update a ticket's status to "Resolved", it should execute a PATCH request to the ticket resource. Kaseya BMS often requires explicit remote procedure call (RPC) endpoints for state transitions. To resolve a ticket, you must post to /tickets/resolve. To merge tickets, you post to /tickets/merge. To assign a ticket, you post to /assignticket. If you do not map these distinct endpoints as individual, highly-described MCP tools, the LLM will hallucinate generic update payloads that Kaseya BMS will reject.

Factual Note on Rate Limits

When interacting with Kaseya BMS, you will encounter API rate limits. It is critical to understand that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Kaseya BMS API returns an HTTP 429 Too Many Requests error, Truto passes that error directly back to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (your AI agent, LangGraph loop, or custom application) is fully responsible for reading these headers and executing retry/backoff logic.

Generating a Managed MCP Server for Kaseya BMS

Instead of building a translation layer from scratch, you can use Truto to dynamically generate an MCP server. Truto's architecture derives tool definitions directly from the integration's documentation records and endpoint schemas. A tool only appears in the MCP server if it has a corresponding documentation entry - acting as a quality gate to ensure only well-documented endpoints are exposed to the LLM.

Each MCP server is scoped to a single connected tenant (Integrated Account). The generated URL contains a secure cryptographic token that encodes the account, tool filters, and expiration. No further client-side configuration is needed.

You can generate this server via the Truto UI or the API.

Method 1: Via the Truto UI

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Kaseya BMS tenant.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can filter by methods (e.g., exposing only read operations) or by tags (e.g., exposing only crm endpoints).
5. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method 2: Via the Truto API

For teams embedding this functionality into their own products, you can generate the MCP server programmatically. The API validates the configuration, generates a secure token stored in durable key-value storage, and returns a ready-to-use URL.

// POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp
// Headers: Authorization: Bearer {truto_api_token}
 
{
  "name": "Kaseya BMS Support Agent",
  "config": {
    "methods": ["read", "write", "custom"],
    "tags": ["servicedesk", "crm", "lookups"]
  },
  "expires_at": "2026-12-31T23:59:59Z"
}

The response will contain the url required by your MCP client. Because Truto flattens the input namespace, the LLM passes query parameters and body payloads as a single object, and Truto's proxy router splits them based on the derived JSON schema.

Connecting the MCP Server to ChatGPT

Once you have the Truto MCP URL, connecting it to ChatGPT takes seconds. You can configure this through the ChatGPT UI or manually via an SSE configuration if you are running a custom client.

Method A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings.
2. Select Apps and click on Advanced settings.
3. Toggle Developer mode on (MCP support is gated behind this flag).
4. Under MCP servers / Custom connectors, click to add a new server.
5. Give it a descriptive name like "Kaseya BMS (Truto)".
6. Paste the Truto MCP server URL into the endpoint field and save.

ChatGPT will immediately ping the server, execute an initialization handshake, and request the /tools/list endpoint. The Kaseya BMS tools are now available for function calling.

Method B: Via Manual Config File (SSE Transport)

If you are running custom agents, local MCP inspectors, or headless tools, you can map the Truto server URL to the standard Server-Sent Events (SSE) transport using the official Model Context Protocol NPM package.

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

Hero Tools for Kaseya BMS Automation

Kaseya BMS exposes hundreds of endpoints. Truto normalizes these into snake_case MCP tools. Here are the highest-leverage tools for automating service desk and CRM operations.

list_all_kaseya_bms_servicedesk_tickets

The core tool for support triage. This tool lists service desk tickets and supports extensive query filtering by account, status, priority, queue, and assignee. It automatically handles pagination cursors, explicitly instructing the LLM to pass the cursor back unchanged for subsequent pages.

"Fetch the 10 most recent high-priority tickets in the Support queue that are currently unassigned."

get_single_kaseya_bms_crm_opportunity_by_id

A crucial tool for account managers. This fetches the full entity record of a CRM opportunity, exposing pipeline stage, expected revenue, and account linkage.

"Retrieve the full details for the CRM opportunity with ID 48922 so I can prepare a summary for the upcoming client call."

list_all_kaseya_bms_itglue_contact_notes

This tool bridges the gap between Kaseya BMS and IT Glue. It allows the LLM to query the IT Glue notes associated with a specific BMS contact ID, pulling in vital technical context before replying to a ticket.

"Look up the IT Glue notes for contact ID 1045 to see if there are any known recurring VPN issues associated with this user."

create_a_kaseya_bms_servicedesk_ticket_note

Required for updating tickets without resolving them. This tool allows the LLM to post internal or external notes, update timestamps, and communicate back to the end-user.

"Add an internal note to ticket ID 8831 stating that we have escalated the server outage to the Level 3 engineering team."

create_a_kaseya_bms_assignticket

This is one of the specific RPC-style endpoints required for state transitions. Instead of patching a ticket, the LLM calls this tool to assign a ticket to a specific agent or team queue.

"Assign ticket ID 9102 to agent ID 44, as this requires a senior network administrator."

create_a_kaseya_bms_resolve

Another RPC-style state transition tool. This closes the ticket loop, requiring the LLM to submit the necessary resolution notes and time tracking data required by the BMS API to mark an issue complete.

"Resolve ticket ID 7721 with the resolution note: 'Cleared the print spooler cache and restarted the local service. Printing restored.'"

To view the complete inventory of available Kaseya BMS tools, exact JSON schemas, and required properties, visit the Kaseya BMS integration page.

Workflows in Action

Providing an LLM with individual tools is only step one. The real power of MCP is how ChatGPT orchestrates multiple tools to complete complex, multi-step operations. Here is how standard BMS workflows look in practice.

Scenario 1: The Intelligent Helpdesk Triage

An IT manager needs to clean up the morning queue. They prompt ChatGPT to process unassigned tickets, but they want the AI to read technical context before blindly routing them.

"Check the unassigned tickets queue. For any ticket reporting a password reset issue, look up the user's IT Glue notes to see if they require SSO bypass. If they do, add an internal note to the ticket flagging the SSO requirement, and then assign the ticket to the Security team."

Step-by-step execution:

1. Query Data: The agent calls list_all_kaseya_bms_servicedesk_tickets with filters set to queue: unassigned and keyword password.
2. Fetch Context: For the matched tickets, it extracts the contact_id and calls list_all_kaseya_bms_itglue_contact_notes.
3. Analyze: The LLM reads the IT Glue payload and identifies the SSO bypass requirement.
4. Update: It calls create_a_kaseya_bms_servicedesk_ticket_note to append the internal context.
5. Route: Finally, it executes create_a_kaseya_bms_assignticket to move the ticket to the correct team.

The manager receives a confirmation message detailing exactly which tickets were triaged and routed, saving hours of manual data cross-referencing.

Scenario 2: The Account Manager Pipeline Sync

A sales rep needs to prepare for a quarterly business review and wants to ensure all CRM data aligns with the latest service requests.

"Find the open CRM opportunity for 'Acme Corp Q3 Expansion'. Check if Acme Corp has any open high-priority support tickets. If they do, add a note to the CRM opportunity warning me about the pending support issues before I walk into the meeting."

Step-by-step execution:

1. Lookup Target: The agent calls list_all_kaseya_bms_crm_opportunities to find the specific pipeline record for Acme Corp and extracts its ID.
2. Cross-reference Data: It calls list_all_kaseya_bms_servicedesk_tickets filtering by account_id and priority: high.
3. Evaluate: The LLM determines that Acme Corp has two severe open tickets.
4. Sync Intelligence: The agent calls create_a_kaseya_bms_opportunity_note and injects the support data into the CRM record.

The sales rep gets a unified view of account health directly attached to the revenue opportunity, executed entirely through a single chat prompt.

Security and Access Control

Exposing PSA data to an LLM requires strict governance. Truto's MCP servers are designed with zero-trust principles, ensuring you maintain absolute control over what the model can see and do.

• Method Filtering: You can strictly limit an MCP server to read-only access. By setting methods: ["read"] during server creation, the server drops all POST, PATCH, and DELETE tools from the manifest. The LLM cannot alter data, regardless of the prompt.
• Tag Filtering: If you only want an agent to access CRM data but strictly forbid access to IT Glue or Finance modules, you can filter tools by tags. Setting tags: ["crm"] scopes the available endpoints entirely.
• Require API Token Auth: By default, the MCP server URL is the only credential needed. By enabling require_api_token_auth: true, the MCP client must also pass a valid Truto API token in the Authorization header. This prevents unauthorized execution even if the URL is leaked in internal logs.
• Time-to-Live Expiration: You can configure temporary access by passing an expires_at timestamp. Background scheduling primitives automatically revoke the token and clean up durable storage exactly when the timestamp is hit, ensuring no stale access points remain.

Bridging the Gap Between IT Ops and AI

Connecting ChatGPT to Kaseya BMS via a managed MCP server removes the friction of API orchestration. You no longer need to write exponential backoff loops for 429 errors, reverse-engineer lookup table dependencies, or maintain massive TypeScript schemas for endpoints that constantly change.

By leveraging Truto to generate a secure, tokenized MCP endpoint, you give your AI agents the exact tools they need to read IT Glue notes, triage service desk tickets, and manage CRM opportunities safely and reliably. Your engineering team is freed from building boilerplate, and your IT support staff gains an intelligent, context-aware co-pilot.