How do I filter tickets or companies in Autotask using Claude?

Claude uses the list_all_autotask_tickets or list_all_autotask_companies tools, sending a highly specific JSON filter query in the POST body. This filter array uses 'op', 'field', and 'value' properties to execute complex searches across the Autotask database.

Why is Claude wiping out ticket data when it updates a status?

If Claude uses a standard PUT endpoint (update_a_autotask_ticket_by_id) without supplying the entire ticket payload, Autotask nullifies omitted fields. You must restrict Claude to using the autotask_tickets_partial_update tool, which executes a safe PATCH request.

Does Truto automatically retry when Autotask rate limits are hit?

No. Truto passes HTTP 429 rate limit errors directly back to the caller. However, Truto normalizes the upstream headers into standard IETF ratelimit-limit, ratelimit-remaining, and ratelimit-reset headers, allowing the MCP client to handle backoff logically.

Can I restrict Claude to read-only access in Autotask?

Yes. When generating your Truto MCP server, you can set the config.methods parameter to ["read"]. This filters the server to only expose get and list tools, completely preventing the LLM from executing writes, updates, or deletes.

Connect Autotask to Claude: Search Companies, Tickets, and Notes

If you need to connect Autotask to Claude to search companies, resolve tickets, or automate service desk dispatch, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and Autotask's complex REST APIs. 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 ChatGPT, check out our guide on /connect-autotask-to-chatgpt-manage-tickets-and-support-workflows/ or explore our broader architectural overview on /connect-autotask-to-ai-agents-automate-service-desk-tasking/.

Giving a Large Language Model (LLM) read and write access to an IT business management platform like Autotask is a massive engineering challenge. You have to handle API credentials, map massive, deeply nested JSON schemas to MCP tool definitions, and deal with Autotask's strict relational data model. Every time an endpoint changes or you need to expose a new custom field, 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 Autotask, connect it natively to Claude, and execute complex service desk workflows using natural language.

The Engineering Reality of the Autotask API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for Claude to discover tools, the reality of implementing it against Autotask's APIs is painful. You are not just building a generic proxy—you are dealing with a platform built to manage IT service providers (MSPs), which carries highly specific architectural quirks.

If you decide to build a custom MCP server for Autotask, you own the entire API lifecycle. Here are the specific challenges you will face:

Complex JSON Filter Payloads Autotask does not use standard REST query parameters for search operations. Instead, almost all list operations (for tickets, companies, notes) require a highly specific JSON body containing a filter array. This array uses op, field, and value properties to execute SQL-like queries. An LLM struggling with schema boundaries will frequently try to append query strings like ?status=New to the URL, which Autotask immediately rejects. Your MCP server must provide flawless JSON Schema definitions to force Claude into constructing these complex filter arrays accurately.

Data Destruction via PUT vs PATCH Autotask enforces strict update semantics. If an LLM uses a standard PUT request to change a ticket's status to "Complete" but fails to include the rest of the ticket's original data payload, Autotask assumes those omitted fields are meant to be deleted. The LLM will inadvertently wipe out the description, contact assignments, and custom fields. A reliable MCP implementation must expose specific PATCH endpoints (partial updates) and aggressively steer the LLM toward using them for routine modifications to prevent catastrophic data loss.

Strict Relational Dependencies and ID Lookups Autotask relies heavily on integer IDs rather than natural language references. If Claude wants to assign a ticket to a technician named "Sarah Connor," it cannot simply send "assignedResourceID": "Sarah Connor". The model must first execute a search against the Autotask Resources endpoint, parse the response to extract Sarah's integer ID, and then inject that integer into the ticket update payload. Managing this multi-step lookup logic requires deep contextual awareness and perfectly described tool schemas.

Generating and Connecting Your Autotask MCP Server

Truto's MCP servers are dynamically generated based on your integrated Autotask account. Rather than hand-coding tool definitions, Truto derives them directly from the Autotask API documentation and JSON schemas configured in the platform. A tool only appears if it has a valid documentation record, ensuring Claude only sees highly curated, context-rich endpoints.

Step 1: Create the MCP Server

You can generate an MCP server for your Autotask connection via the Truto dashboard or programmatically via the API.

Method A: Via the Truto UI

Navigate to the Integrated Accounts page in your Truto environment.
Select your connected Autotask instance.
Click the MCP Servers tab.
Click Create MCP Server.
Select your desired configuration (e.g., restrict to read methods only, or filter by specific tags).
Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method B: Via the API For platforms orchestrating agents programmatically, you can generate MCP servers on the fly. Truto will validate that the Autotask integration has valid tools, generate a secure, hashed token, and return a ready-to-use endpoint.

curl -X POST https://api.truto.one/integrated-account/autotask-account-id/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Autotask Service Desk Agent",
    "config": {
      "methods": ["read", "write", "patch"],
      "tags": ["tickets", "companies", "resources"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

Step 2: Connect the Server to Claude

Once you have the URL, you need to register it with Claude so the model can discover your Autotask tools during the initial MCP handshake.

Method A: Via the Claude UI

Open your Claude desktop application or web interface.
Navigate to Settings → Integrations → Add MCP Server.
Paste the Truto MCP URL into the connection field.
Click Add. Claude will immediately execute an initialization handshake and populate its context window with the available Autotask tools.

Method B: Via Manual Config File (claude_desktop_config.json) For developers running custom environments or using the Claude Desktop local configuration, you can wire up the server using the standard JSON configuration. Because Truto URLs act as direct endpoints, you can use the official MCP SSE wrapper command to handle the transport layer.

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

Security and Access Control

Giving an LLM unconstrained access to your entire IT service desk is dangerous. Truto provides four specific mechanisms to scope and secure your Autotask MCP server:

Method Filtering (config.methods): Restrict the server to specific HTTP verbs. Set this to ["read"] to allow Claude to query tickets and companies without the ability to accidentally delete or alter records.
Tag Filtering (config.tags): Group tools logically. You can create an MCP server tagged exclusively with "support" so Claude can access tickets and notes, but physically cannot interact with financial or billing entities.
Secondary Authentication (require_api_token_auth): By default, possessing the MCP URL is enough to authenticate tool calls. Setting this flag to true forces the MCP client to also pass a valid Truto API token in the Authorization header. If the URL leaks, it remains useless without the secondary key.
Time-to-Live (expires_at): Grant temporary access to external agents or contractors by passing an ISO datetime. Once expired, Truto automatically purges the tokens from its KV store and schedules a Durable Object alarm to clean up the database.

Hero Tools for Autotask

The following tools are automatically derived from the Autotask integration and presented to Claude with complete query and body schemas. Truto's dynamic generation handles the heavy lifting—injecting explicit instructions on how Claude should handle pagination (limit, next_cursor) so you don't have to code it yourself.

1. List All Autotask Tickets (`list_all_autotask_tickets`)

Searches Autotask Tickets using a complex JSON filter query. It returns a standardized array of Ticket objects including id, ticketNumber, title, description, status, priority, and userDefinedFields.

"Find all critical priority tickets created in the last 48 hours that are currently unassigned in the triage queue."

2. Autotask Tickets Partial Update (`autotask_tickets_partial_update`)

Partially updates an Autotask Ticket (HTTP PATCH). This is the safest way to alter records. You send the ticket id alongside only the fields you want to change (like status or assignment). All other fields remain untouched, preventing the data-wiping behavior of a standard PUT request.

"Reassign ticket T20261015.0041 to technician ID 34821 and change its status to 'In Progress'."

3. List All Autotask Companies (`list_all_autotask_companies`)

Searches your Autotask CRM for organizations using filter expressions. This is critical for context gathering—Claude must often look up a company by name to retrieve its internal companyID before creating a new ticket.

"Look up the company 'Acme Corp' in Autotask and tell me their companyID and primary account manager."

4. Create a Ticket Note (`create_a_autotask_ticket_note`)

Appends a new note to an existing ticket. This is heavily used by AI agents summarizing interactions, logging diagnostic steps, or updating technicians on automated remediation attempts. Requires the target ticket_id.

"Add a progress note to ticket 88492 explaining that the user's password reset attempt failed due to an expired Active Directory token."

5. List All Autotask Resources (`list_all_autotask_autotask_resources`)

Searches internal staff users (technicians, account managers). Because Autotask ticket assignments require an assignedResourceID, Claude relies on this tool to translate human names into system integers.

"Find the resource ID for technician 'David Bowman' so I can assign the server outage ticket to him."

6. Get Single Ticket By ID (`get_single_autotask_ticket_by_id`)

Retrieves the complete payload of a single ticket by its internal integer id. This returns everything, including deep metadata, SLAS, timestamps, and custom UDFs.

"Pull the complete details and full description for ticket ID 109344."

Looking for the full API inventory? See the Autotask integration page for complete endpoint schemas and supported resources.

Workflows in Action

When Claude is equipped with Truto's Autotask tools, it can chain them together to automate multi-step IT management tasks autonomously.

Workflow 1: The Automated Triage & Dispatch

Persona: Service Desk Dispatcher

"Find any unassigned critical tickets submitted by 'Wayne Enterprises'. If you find any, look up the resource ID for technician 'Bruce Fox' and assign the ticket to him. Then, add a note to the ticket saying it has been escalated via AI dispatch."

sequenceDiagram
    participant User
    participant Claude
    participant Truto as Truto MCP Server
    participant Autotask as Autotask API

    User->>Claude: "Find unassigned critical tickets..."
    
    Claude->>Truto: call list_all_autotask_companies(filter: {"op": "eq", "field": "companyName", "value": "Wayne Enterprises"})
    Truto->>Autotask: POST /Companies/query
    Autotask-->>Truto: Return companyID 5012
    Truto-->>Claude: Result: companyID 5012

    Claude->>Truto: call list_all_autotask_tickets(filter: {"companyID": 5012, "status": "New", "priority": "Critical"})
    Truto->>Autotask: POST /Tickets/query
    Autotask-->>Truto: Return Ticket 99402
    Truto-->>Claude: Result: Ticket 99402

    Claude->>Truto: call list_all_autotask_autotask_resources(filter: {"firstName": "Bruce", "lastName": "Fox"})
    Truto->>Autotask: POST /Resources/query
    Autotask-->>Truto: Return resourceID 882
    Truto-->>Claude: Result: resourceID 882

    Claude->>Truto: call autotask_tickets_partial_update(id: 99402, assignedResourceID: 882)
    Truto->>Autotask: PATCH /Tickets/99402
    Autotask-->>Truto: Success
    Truto-->>Claude: Update Confirmed

    Claude->>Truto: call create_a_autotask_ticket_note(ticket_id: 99402, title: "AI Dispatch", description: "Escalated via AI dispatch.")
    Truto->>Autotask: POST /Tickets/99402/Notes
    Autotask-->>Truto: Success
    Truto-->>Claude: Note Added

Step-by-step breakdown:

Claude uses list_all_autotask_companies to translate "Wayne Enterprises" into integer ID 5012.
It queries list_all_autotask_tickets using the retrieved company ID, filtering for "New" status and "Critical" priority.
Upon finding an unassigned ticket, Claude calls list_all_autotask_autotask_resources to fetch the integer ID for Bruce Fox (882).
It executes a safe autotask_tickets_partial_update to inject assignedResourceID: 882 without destroying other ticket data.
Finally, it uses create_a_autotask_ticket_note to leave an audit trail of its actions.

Workflow 2: Customer Context & Escalation Prep

Persona: Technical Account Manager

"I'm jumping on a call with Global Dynamics. Look them up in Autotask, tell me how many open tickets they have, and give me a quick summary of the oldest open ticket. If the oldest ticket hasn't been updated in 3 days, bump the priority to 'High' and add an internal note that the TAM is reviewing it."

sequenceDiagram
    participant User as Account Manager
    participant Claude
    participant Truto as Truto MCP Server
    participant Autotask as Autotask API

    User->>Claude: "Prep me for Global Dynamics..."
    
    Claude->>Truto: call list_all_autotask_companies(filter: {"companyName": "Global Dynamics"})
    Truto->>Autotask: POST /Companies/query
    Autotask-->>Truto: Return companyID 104
    Truto-->>Claude: Result: companyID 104

    Claude->>Truto: call autotask_tickets_count(filter: {"companyID": 104, "status": "not_equal_to_Complete"})
    Truto->>Autotask: POST /Tickets/count
    Autotask-->>Truto: Return count: 14
    Truto-->>Claude: Result: 14 open tickets

    Claude->>Truto: call list_all_autotask_tickets(filter: {...}, limit: 1, sort: "createDate ASC")
    Truto->>Autotask: POST /Tickets/query
    Autotask-->>Truto: Return Ticket 4432 (Oldest)
    Truto-->>Claude: Result: Ticket 4432 details

    Claude->>Truto: call autotask_tickets_partial_update(id: 4432, priority: "High")
    Truto->>Autotask: PATCH /Tickets/4432
    Autotask-->>Truto: Success
    Truto-->>Claude: Priority Updated

    Claude->>Truto: call create_a_autotask_ticket_note(ticket_id: 4432, description: "TAM is reviewing.")
    Truto->>Autotask: POST /Tickets/4432/Notes
    Autotask-->>Truto: Success
    Truto-->>Claude: Note Added

Step-by-step breakdown:

Claude resolves the company ID using list_all_autotask_companies.
It leverages the lightweight autotask_tickets_count tool to quickly determine the volume of open issues (14) without downloading heavy payloads.
It queries list_all_autotask_tickets to fetch the oldest record.
Evaluating the timestamps, Claude determines the ticket is stale and uses autotask_tickets_partial_update to escalate the priority.
It logs the action using create_a_autotask_ticket_note and responds to the user with the summary.

Handling Autotask Rate Limits

When deploying AI agents that rapidly chain tool executions, you will inevitably hit Autotask's API rate limits. It is critical to understand that Truto does not absorb, retry, or apply backoff to rate limit errors.

When the Autotask upstream API returns an HTTP 429 Too Many Requests error, Truto passes that error directly down to the MCP caller. However, Truto normalizes the disparate rate limit information from Autotask into standardized IETF headers:

ratelimit-limit
ratelimit-remaining
ratelimit-reset

The caller (your agent framework or Claude client) is strictly responsible for inspecting the ratelimit-reset header and implementing its own retry or backoff logic. Truto's proxy API handlers ensure you always receive structured, predictable data, but you own the pacing.

Moving from Prototypes to Production

Building a custom MCP server to map Claude to Autotask is an excellent weekend project, but it is a terrible long-term engineering commitment. The Autotask REST API is deep, heavily relational, and unforgiving of bad data payloads. By the time you build reliable JSON schemas for filters, implement safe PATCH wrappers, and handle OAuth refreshes, you have built an entire integration platform from scratch.

Truto's dynamically generated MCP servers eliminate this entire layer of infrastructure. Because the tools are derived directly from curated documentation and integration schemas, Claude gets perfectly constructed instructions every time. You get secure authentication, precise access control, and immediate zero-downtime scalability, allowing your engineering team to focus on the AI agent's logic instead of the plumbing.

Stop hand-coding Autotask integrations. Automate your service desk operations securely and at scale.