Skip to content

Connect BMC Helix to Claude: Sync Service Requests & Support Teams

Learn how to connect BMC Helix to Claude using a managed MCP server to automate ITSM workflows, incident management, and change requests.

Uday Gajavalli Uday Gajavalli · · 10 min read
Connect BMC Helix to Claude: Sync Service Requests & Support Teams

If you need to connect BMC Helix to Claude to automate IT service management (ITSM), triage incoming incidents, log work notes, or orchestrate complex change requests, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and BMC Helix's notoriously complex AR System REST APIs. You can either engineer and maintain this integration layer in-house, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our guide on /connect-bmc-helix-to-chatgpt-manage-itsm-incidents-and-change-requests/ or explore our broader architectural overview on /connect-bmc-helix-to-ai-agents-orchestrate-itsm-workflows-and-tasks/.

Giving a Large Language Model (LLM) read and write access to a sprawling, legacy-rooted enterprise system like BMC Helix is a significant engineering challenge. You must handle session token lifecycles (AR-JWT), map massive, highly customized JSON schemas to MCP tool definitions, and deal with BMC's strict interface form requirements. Every time an ITSM administrator modifies a mandatory field on the HPD:Help Desk form, your server code must adapt.

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

The Engineering Reality of the BMC Helix 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, the reality of implementing it against BMC Helix's APIs is painful. You are not just integrating a modern REST API - you are interfacing with the Action Request (AR) System, a database-driven workflow engine that dictates how data is queried and modified.

If you decide to build a custom MCP server for BMC Helix, here are the specific integration challenges you will face:

Interface Forms and Pseudo-fields (z1D_Action) You cannot simply send a POST request to the core HPD:Help Desk form to create an incident. BMC Helix relies on "Interface" forms to trigger backend workflow rules. To create an incident, you must target HPD:IncidentInterface_Create and pass a pseudo-field called z1D_Action with the value CREATE. To modify an incident, you target HPD:IncidentInterface with z1D_Action set to MODIFY. An LLM has no intuition for this architecture. You must build an abstraction layer that presents unified operations to Claude while handling these routing and payload quirks in the background.

Complex AR Qualifications for Filtering Standard query parameters do not work in BMC Helix. To filter lists of incidents or change requests, you must construct an AR qualification string and pass it in the q parameter. For example, querying assigned incidents requires passing exactly q="'Status' = \"Assigned\"". Instructing an LLM to reliably generate these deeply nested, escaped string queries without hallucinating field names requires strict JSON schemas and explicit tool descriptions.

Attachment Handling in Work Logs ITSM workflows heavily rely on attachments - screenshots of errors, log files, or approvals. In BMC Helix, these are stored in attachment fields like z2AF Work Log01 on forms such as HPD:WorkLog. Downloading or uploading these requires splitting the attachment href into base and path components and making secondary requests. Exposing this capability to Claude requires multi-step orchestration hidden behind a single, clean MCP tool.

How to Generate a Managed MCP Server for BMC Helix

Instead of building a custom Node.js or Python server to wrangle AR System forms and JWT tokens, you can use Truto to dynamically generate an MCP server. Truto derives tool definitions directly from the integration's documented resources, ensuring that only curated, tested endpoints are exposed to the LLM.

Each MCP server is scoped to a single connected BMC Helix instance. The generated server URL contains a cryptographic token that securely authenticates the request, meaning the URL alone is all Claude needs to connect.

You can create this MCP server in two ways: via the Truto UI or programmatically via the API.

Method 1: Creating the MCP Server via the Truto UI

For ad-hoc agent testing or manual Claude Desktop configuration, the UI is the fastest path.

  1. Log into your Truto dashboard and navigate to the Integrated Accounts page.
  2. Select your connected BMC Helix account.
  3. Click the MCP Servers tab.
  4. Click Create MCP Server.
  5. Select your desired configuration. You can filter tools by method (e.g., only allow read operations) or by tag (e.g., only allow incident or change operations).
  6. Set an optional expiration date if this is for temporary contractor access.
  7. Click Create and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5...).

Method 2: Creating the MCP Server via the Truto API

If you are provisioning AI workspaces dynamically for your internal IT team, you should generate the MCP server programmatically. This endpoint creates the server, stores the token metadata securely in a high-speed KV store, and returns a ready-to-use URL.

Request:

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Claude ITSM Assistant - BMC Helix",
    "config": {
      "methods": ["read", "write"],
      "tags": ["incident", "worklog", "change"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

Response:

{
  "id": "mcp_8f9a2b1c",
  "name": "Claude ITSM Assistant - BMC Helix",
  "config": {
    "methods": ["read", "write"],
    "tags": ["incident", "worklog", "change"]
  },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6g7h8i9j0..."
}

This URL acts as the JSON-RPC 2.0 endpoint for Claude. When Claude connects, Truto automatically builds the tool definitions by merging query and body schemas from the underlying BMC Helix documentation, flat-mapping them into a single input namespace for the LLM.

How to Connect the MCP Server to Claude

Once you have your Truto MCP server URL, you must register it with your Claude client. You can do this visually in the UI for managed workspaces or locally via a configuration file for Claude Desktop.

Method 1: Via the Claude UI (Enterprise / Web)

If you are using Claude for Enterprise or connecting custom web connectors:

  1. Open Claude and navigate to Settings -> Integrations.
  2. Locate the MCP Servers or Custom Connectors section.
  3. Click Add MCP Server.
  4. Paste your Truto MCP URL into the connection field.
  5. Click Add. Claude will instantly execute the initialize handshake and call tools/list to discover the available BMC Helix operations.

Method 2: Via the Claude Desktop Config File

If you are running Claude Desktop locally for development or personal IT administration, you connect via the claude_desktop_config.json file. Because Truto provides a remote SSE (Server-Sent Events) endpoint, you use the standard @modelcontextprotocol/server-sse proxy to bridge the local client to the remote URL.

Locate your configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the BMC Helix server to your configuration:

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

Save the file and restart Claude Desktop. The BMC Helix tools will now be available in your prompt interface.

Hero Tools for BMC Helix Automation

Truto automatically generates descriptive, snake_case tool names based on the integration label and resource name. The query parameters and body schemas are combined into a single flat input object, preventing the LLM from struggling with HTTP structure. Here are the highest-leverage tools for BMC Helix.

list_all_bmc_helix_incident

Queries the HPD:Help Desk form to return existing incidents. You must use the q parameter to pass AR System qualification strings. This is critical for triage agents looking for unassigned or high-priority tickets.

"Find all high-urgency incidents assigned to the 'Database Admins' group. Use the q parameter with an AR qualification string to filter by 'Assigned Group' and 'Urgency'. Return only the Incident Number, Description, and Status fields."

create_a_bmc_helix_incident

Creates a new incident record by targeting the HPD:IncidentInterface_Create form. The schema explicitly requires the LLM to provide First_Name, Last_Name, Description, Impact, Urgency, and sets z1D_Action to CREATE automatically.

"Create a new critical incident for user Jane Doe. The database server in us-east-1 is unresponsive. Set the Impact to 1-Extensive/Widespread and Urgency to 1-Critical."

create_a_bmc_helix_worklog

Logs a note, update, or resolution step to an existing incident via the HPD:WorkLog form. This is the primary mechanism for an AI agent to communicate its actions back to human technicians in the ITSM system.

"Add a worklog to incident INC0000012345. State that I have initiated a restart of the affected container and am monitoring the logs for recovery. Set the Work Log Type to 'Working Log'."

create_a_bmc_helix_change

Proposes a new infrastructure change request via CHG:ChangeInterface_Create. Change management in BMC Helix is heavily regulated by internal rules; this tool forces the LLM to supply required fields like Company and Description while managing the interface action.

"Draft a new change request for patching the Apache web servers this weekend. Set the Urgency to Low, Impact to Minor, and assign it to the 'Server Management' organization."

list_all_bmc_helix_support_group

Queries the CTM:Support Group form to find the correct team for ticket routing. Since exact string matches are required for assignment in BMC Helix, the agent must look up the exact group name before attempting to reassign an incident.

"Look up the exact Support Group Name for the team that handles networking issues in the EMEA region, so I can assign this network outage ticket to them."

create_a_bmc_helix_problem

Opens a Problem Investigation via the PBM:ProblemInterface_Create form. Use this when a recurring incident needs root cause analysis. The tool supports creating problems, known errors, or solutions based on the z1D_Action field.

"Create a Problem Investigation linked to our recent string of login timeout incidents. Set the Description to 'Investigate recurring LDAP timeout spikes' and assign it to the Core Infrastructure team."

To view the complete inventory of available BMC Helix tools, required parameters, and JSON schemas, visit the BMC Helix integration page.

Workflows in Action

An LLM armed with these tools can orchestrate multi-step ITSM operations that would normally require a human to click through dozens of AR System forms.

sequenceDiagram
    participant User
    participant Claude as Claude Desktop
    participant MCP as Truto MCP Server
    participant BMC as BMC Helix API

    User->>Claude: "Triage high-urgency incidents"
    Claude->>MCP: Call list_all_bmc_helix_incident (q="'Urgency'='1-Critical'")
    MCP->>BMC: GET /api/arsys/v1/entry/HPD:Help Desk?q=...
    BMC-->>MCP: Return incident array
    MCP-->>Claude: Incident data
    Claude->>MCP: Call create_a_bmc_helix_worklog (Incident Number, note)
    MCP->>BMC: POST /api/arsys/v1/entry/HPD:WorkLog
    BMC-->>MCP: Worklog created
    MCP-->>Claude: Success confirmation
    Claude-->>User: "Incidents reviewed and worklogs updated."

Use Case 1: Triage and Escalate High-Urgency Incidents

IT Service Desks are often overwhelmed by alert storms. You can instruct Claude to act as a Level 1 dispatcher, finding unassigned critical tickets, looking up the right team, assigning the ticket, and logging its actions.

"Find all unassigned high-impact incidents submitted today. Look up the exact name of the Network Support group. Assign the incidents to that group, and create a worklog on each incident noting that the AI assistant has triaged and escalated the ticket."

Execution Steps:

  1. Claude calls list_all_bmc_helix_incident using the q parameter to filter for unassigned, high-impact records.
  2. Claude calls list_all_bmc_helix_support_group with a search term to get the precise AR System name for the networking team.
  3. Claude iterates through the tickets, calling update_a_bmc_helix_incident_interface_by_id (via the interface form) to change the Assigned Group.
  4. Claude calls create_a_bmc_helix_worklog for each ticket to leave an audit trail of the reassignment.

Result: The user gets a summary confirming which Incident Numbers were escalated, ensuring strict ITSM compliance without manual clicks.

Use Case 2: Propose and Log an Infrastructure Change Request

Change management requires meticulous documentation. Instead of manually filling out the CHG:Infrastructure Change form, an engineer can dictate the plan to Claude.

"Create a new change request for the upcoming Q3 Database Migration. Describe it as 'Q3 Prod DB Migration', set urgency to high, impact to moderate, and assign it to Database Services. Then, attach a worklog detailing the rollback plan: 'Restore from nightly snapshot prior to execution'."

Execution Steps:

  1. Claude calls create_a_bmc_helix_change with the provided parameters, mapping them to the CHG:ChangeInterface_Create schema.
  2. BMC Helix returns the new Infrastructure Change ID (e.g., CRQ0000000999).
  3. Claude takes that ID and calls create_a_bmc_helix_change_worklog, associating the rollback plan text directly with the newly created change request.

Result: The user receives the new CRQ number and confirmation that the rollback documentation is safely attached to the record.

Handling Rate Limits in Production

Enterprise systems like BMC Helix strictly enforce API quotas to prevent database degradation. When building agentic workflows that loop through records, it is easy to trigger rate limits.

Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream 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 (or the LLM framework) is entirely responsible for reading these headers and implementing appropriate retry logic and exponential backoff.

Security and Access Control

Giving an LLM direct access to your ITSM database introduces risk. Truto's MCP architecture mitigates this by providing fine-grained access control at the token level, ensuring agents only have the permissions they absolutely need.

  • Method Filtering: Use config.methods: ["read"] during token creation to restrict the server to get and list operations. This ensures a reporting agent cannot accidentally delete or modify an incident.
  • Tag Filtering: Use config.tags: ["incident", "worklog"] to expose only specific resource groups, hiding sensitive modules like employee HR records or financial change requests from the LLM.
  • Time-to-Live (TTL): Set the expires_at field to provision ephemeral servers. Truto handles automatic KV and database cleanup when the alarm fires, leaving no stale credentials behind.
  • Require API Token Auth: By setting require_api_token_auth: true, you force the client to provide a valid Truto API token in the Authorization header, adding a strict secondary layer of authentication beyond the server URL.

Strategic Wrap-Up

Connecting Claude to BMC Helix unlocks massive productivity gains for IT Service Management, but building the integration from scratch requires a deep understanding of AR System quirks, interface forms, and custom qualifications. By leveraging a dynamically generated MCP server, you abstract away the API complexity and present Claude with a clean, heavily schematized toolkit.

This approach accelerates development, enforces strict data governance, and ensures your AI agents interact safely with your core IT infrastructure.

FAQ

How do I connect Claude to BMC Helix?
You can connect Claude to BMC Helix by deploying a Model Context Protocol (MCP) server. Using a platform like Truto, you generate a secure MCP URL that acts as a translation layer, allowing Claude to securely call BMC Helix's REST APIs using natural language.
Does Truto automatically handle BMC Helix rate limits?
No. Truto passes HTTP 429 rate limit errors directly back to the caller and standardizes the rate limit headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). The client or AI agent is responsible for implementing retry and backoff logic.
Can I restrict the AI agent to read-only access in BMC Helix?
Yes. When generating the MCP server in Truto, you can use method filtering (e.g., config.methods: ["read"]) to restrict the available tools to GET and LIST operations, preventing the LLM from creating or modifying records.
How does the AI agent handle complex AR System qualifications?
The generated MCP tools map query schemas directly to the LLM. The agent passes AR qualification strings into the 'q' parameter of the tool, allowing it to filter records just like a native BMC Helix API call.

More from our Blog