Connect Claude, or another MCP client, to Autotask PSA

As of 22 October 2026, Kaseya publishes no MCP server of its own for Autotask that we could find. Community servers exist; most run on each computer with the API user's secret in their settings, and some can be self-hosted over HTTP. A hosted gateway keeps the secret in one sealed place instead, and every technician's agent draws from it under its own limits.

What the agent can do in Autotask

The Autotask connector covers the objects an MSP works in every day. Each action is marked read, write or destructive, which is what the key grammar below uses.

Ticket actions also answer to the shared name service.ticket.create, which 54 connectors implement. An agent that learns it once can open a ticket in HaloPSA or ConnectWise PSA the same way. See canonical action names.

Step 1: Add actionlake to your MCP client

Claude Code (tested):

claude mcp add --transport http actionlake https://connect.actionlake.com/mcp

The Claude app (tested on our own account with an existing key): Settings, Connectors, Add custom connector, URL https://connect.actionlake.com/mcp, then Connect.

Other MCP clients that support remote servers over Streamable HTTP (MCP revisions 2025-06-18 and 2025-11-25) should connect the same way; we have not tested them. Add a server with the same URL. The client registers itself with OAuth 2.1 dynamic client registration, or you send an actionlake key as Authorization: Bearer. Per-client steps are in how to add a remote MCP server to Claude Code, Cursor and VS Code.

On the consent page, paste your actionlake key, or press Create one for a free sandbox tenant. We tested Create one in Claude Code. In the Claude app we tested an existing key only, so if Create one fails there, create the sandbox in Claude Code or the console and paste its key.

Step 2: Create an API-only user in Autotask

Autotask's REST API authenticates an API user, not a person. In Autotask's admin settings:

1. Create a new API user with an API-only security level.
2. Give it the narrowest security level that covers what your agents will do. If agents will only read, a read-focused level is enough.
3. Set its tracking identifier. Autotask then shows an API integration code.
4. Note the user name and generate the secret.

Least privilege starts here. actionlake's key scopes narrow what each agent may run, but they cannot grant more than the Autotask API user may do.

Step 3: Store the connection

Ask your agent: "Connect Autotask." It asks actionlake what Autotask needs (free), then sends the three credentials:

{
  "op": "connections.create",
  "service": "autotask",
  "name": "default",
  "secrets": {
    "integration_code": "…",
    "username": "…",
    "secret": "…"
  }
}

There is no zone or base URL to look up. At connect time actionlake asks Autotask which zone your instance lives in and stores it. The three values are sealed on arrival under your tenant's own data key, and no endpoint returns them.

Prefer not to paste secrets into a chat? Enter them in the console, under Connections.

Step 4: One key per agent or technician

Do not leave agents on the root key. Mint a key for each technician's agent, from the console or with your root key over REST (an OAuth connection cannot mint keys):

curl -X POST https://api.actionlake.com/v1/account/keys.create \
  -H "Authorization: Bearer $ACTIONLAKE_ROOT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "desk-agent-sam",
    "holder": "agent",
    "allowed_actions": ["autotask.read:*", "autotask.ticket_notes.create", "autotask.time_entries.create"],
    "cap_calls": 3000,
    "confirm_policy": "human",
    "approval_rules": [
      { "match": "autotask.tickets.update", "approver": "[email protected]" }
    ]
  }'

What each line does:

• autotask.read:* lets the agent read every Autotask object, but not write. A read that reveals a secret is never covered by read:*; it needs a grant that names it.
• Notes and time entries are allowed outright. They add to a ticket and change nothing already there.
• autotask.tickets.update is not in allowed_actions, so it is refused. To allow it behind a sign-off, add it to allowed_actions and keep the rule: each update then waits for the service manager. See human-in-the-loop approval.
• cap_calls caps the key in upstream calls. At the cap the next call is refused before it is sent, so one busy agent cannot spend the Autotask API threshold your ticket sync depends on.

Revoke the key and that agent stops at once. Any key it minted is revoked with it.

Step 5: Ask in plain words

Technicians do not type tool calls. They ask:

• "What's open for Contoso, oldest first?"
• "Log 30 minutes against ticket 48211 with a note that the printer driver was reinstalled."
• "Which of my tickets have had no activity for a week?"

For the first question, the agent runs:

{
  "action": "autotask.tickets.query",
  "input": { "company_id": 689, "status": 1 },
  "limit": 50,
  "intent": "The technician asked for Contoso's open tickets, oldest first."
}

Status and queue values are picklists that differ between Autotask instances. The agent reads yours with get_action and the picklist actions before it filters.

Protect your Autotask API threshold

Autotask limits API requests per hour across your whole instance. Every integration shares that budget: your RMM sync, your billing tools and now your agents. Three things keep agents inside it:

Writes are never cached and never retried, so an agent cannot double-post a time entry because a request timed out.

What it costs

You pay per upstream call: one request sent to Autotask that returned a definitive answer. Cache hits, check, searches and refused calls are free. Calls Autotask answers with 401, 403, 429, a 5xx or a timeout are free too. The Free plan has 100,000 calls a month and a hard stop. Starter is US$49 a month for 250,000 calls. See pricing.