Autotask MCP Server: Give AI Autotask Context Without the Developer Gauntlet

An Autotask MCP server connects Datto Autotask PSA to an AI agent like Claude or ChatGPT, so the model can read and act on your tickets, companies, assets, time entries, and contracts through a standard protocol. Here’s the honest version: once you’re connected, Autotask’s API is genuinely pleasant to work with, arguably cleaner than ConnectWise’s. The hard part is everything before that. Getting into Autotask’s API means going through Kaseya’s developer program, passing an integration code on every single call, and respecting rate limits that punish any burst of traffic. This post is about both halves: the real hurdles, and what a good Autotask MCP does about them.

If you’re new to the concept, start with what MCP (Model Context Protocol) is for MSPs and the overview of Claude MCP servers across your stack. Autotask is one piece of Junto’s MCP for MSPs, which runs the same pattern across your whole stack, and it’s a close cousin of our ConnectWise MCP. This post is Autotask-specific.

Getting into Autotask’s API is a process, not a form

Most PSAs hand you API keys and get out of the way. Autotask doesn’t. To integrate with Autotask, you register as part of Kaseya’s developer program, and that involves real due diligence on Kaseya’s side before they let you in. Once approved, they issue you an integration code (a tracking identifier tied to your integration) that has to be passed with every API call. There’s no anonymous access; every request is attributed to a registered integration.

Getting to that first code takes a few weeks. Then you build the integration against a sandbox. When it’s built, you have a review call with Kaseya’s development team to get approval to publish the app, and only then do they hand over production keys.

None of this is a knock on Kaseya. The gate is deliberate, and in our experience their team was genuinely responsive and helpful through it. But it means “connect an AI agent to Autotask” is not a weekend project. Before you write a single tool, there’s a multi-week approval process standing between you and a production connection.

Rate limits that punish bursts

Autotask enforces API rate limits, and they’re strict enough to matter the moment you point an AI agent at them. An agent triaging tickets doesn’t make one call at a time; a single ticket might trigger lookups for the company, the contact, the asset, recent tickets, and the contract, and if you’re processing a queue in parallel, those calls stack up fast.

And Autotask doesn’t fail gracefully when you cross the line. Go over the hourly cap and it can suspend the API user rather than return a polite “slow down.” Exceed its hard limit on concurrent requests per API user and you get misleading errors (odd 404-style HTML, 500s) that look like bugs but are really throttling. Staying safe takes more than a retry loop: proactive hourly-rate accounting that adds latency before you approach the cap, a concurrency limiter that never runs more than a couple of requests at once, and serialized calls instead of parallel fan-out. It’s real engineering that every serious Autotask integration has to get right, and that a naive tool wrapper won’t.

The ticket-number vs. ticket-ID trap

Here’s the one that quietly breaks things. In Autotask, a ticket has two identifiers: an internal numeric id the API uses, and a ticketNumber (the “T-number”) that humans see in the GUI and that shows up in emails and conversations. They are not the same value.

When a tech or a ticket says “take a look at T20240517.0042,” that’s the ticket number, not the API id. If the agent passes that string where the API wants the internal id, it either errors or, worse, acts on the wrong record. So the integration has to translate: resolve the human-facing ticket number to the internal id, use the id for the API call, and show the number back to the human. Miss this and the agent looks like it’s hallucinating; get it right and nobody ever notices, which is the point. Like ConnectWise, it comes down to knowing exactly what identifier each call expects and feeding it the right one.

Once you’re in, the API is genuinely good

Credit where it’s due. Past the developer program and the rate limits, Autotask’s API is well-structured and, in our experience, easier to work with than ConnectWise’s. Statuses and picklists are global rather than defined per board, so there’s less per-entity resolution to do. The entity model is consistent. And Kaseya’s developer team was responsive when we had questions.

That’s the real shape of an Autotask integration: the difficulty is front-loaded into onboarding and rate limiting, not the day-to-day API work. Which is exactly why buying the connection instead of building it changes the math more for Autotask than for most PSAs.

What our Autotask MCP does differently

Everything above, we’ve already done as part of Junto’s Autotask integration. The developer-program registration, the integration code on every call, the review-and-publish process, the production keys: handled. The rate limiting: handled, with real burst protection so an agent processing a full queue never trips Autotask’s limits. The ticket-number translation: handled, so the agent always calls the right record. You connect your own Autotask in a short setup, not a month.

Three more things carry over from how we handle every PSA (the same design as our ConnectWise MCP):

• Smart tooling built by people who know the API. Tools that get an answer in as few calls as possible, which matters double when you’re rate-limited.
• Unified audit logs across every application. One trail for everything the agent does, in Autotask and beyond. No more “wait, what did the agent do, and who authorized that?”
• Centralized permissions by user or group. Some people can see contract and billing data; some can’t. Some can take destructive actions; others can’t. Set it once, centrally.

And one thing that’s specific to Autotask:

• Embedded right inside Autotask. Rather than living in a separate tab, Junto’s output surfaces inside the Autotask interface your techs already use, two ways: as a panel on the ticket itself and as a dashboard widget, both registered through Autotask’s Integration Center. The triage note, the context, the suggested action appear on the ticket, in the PSA, where the work happens. (These embedded surfaces need their own vendor keys from Kaseya, separate from the API integration code, which is one more piece of the setup we handle.) That in-platform surface is a big part of why a bought Autotask MCP can be cleaner than a standalone server you’d build yourself; you’re not just connecting the data, you’re putting it back where techs already look.

The full list of Autotask capabilities

Our Autotask MCP exposes 58 tools across the PSA. Read tools are safe to run freely. Write tools are permissioned per user or group. A small set of high-risk actions are approval-gated by default (flagged below). Every write is company-scoped and attributed to the resource acting.

Tickets

• at_get_ticket — full detail of a ticket by its internal numeric id (not the T-number) (read)
• at_search_tickets — search by company, queue, status, resource, text, or ticket-number prefix (read)
• at_list_ticket_statuses, at_list_queues — the global status and queue picklists (Autotask uses queues, not boards) (read)
• at_create_ticket — create a ticket under a company (write)
• at_update_ticket — update status, queue, priority, or assigned resource (write)
• at_bundle_tickets / at_unbundle_tickets — link/unlink tickets in an ITIL Problem/Incident relationship; reversible (write)
• at_reassign_ticket_company — re-home a mis-filed ticket to a different company (write · approval-gated)
• at_merge_tickets — merge duplicate tickets into a primary; irreversible (write · approval-gated)

Ticket notes

• at_create_internal_note — technician-only note (write)
• at_create_resolution_note — resolution write-up, also written to the ticket’s Resolution field (write)
• at_create_discussion_note — customer-visible note (write · approval-gated)

Companies, contacts, and resources

• at_list_companies, at_list_contacts, at_list_company_types, at_search_resources — search companies/contacts, company types, and resolve a technician to a resource id (read)
• at_create_company, at_update_company — create/update a company (write)
• at_create_contact, at_update_contact — create/update a contact (write)

Finance and contracts

• at_search_agreements, at_get_agreement, at_search_invoices, at_get_invoice — search and read contracts (with services/charges) and invoices (with line items) (read)
• at_update_company_billing — update a company’s billing settings (write · approval-gated)

Time entries

• at_get_time_entries, at_search_time_entries, at_list_billing_codes — read time on a ticket, across tickets by resource/date, and the billing codes (read)
• at_create_time_entry — log time against a ticket or a project task (write)

Projects

• at_list_projects, at_get_project — list projects and read one with its phases and tasks (read)
• at_create_project, at_create_phase, at_create_task, at_add_project_note — scaffold a project, phases, and tasks, and add notes (write)

Sales, CRM, and CPQ

• at_list_opportunities, at_get_opportunity, at_list_opportunity_stages, at_list_opportunity_statuses — read the sales pipeline and its picklists (read)
• at_list_quotes, at_get_quote, at_list_quote_locations, at_list_products, at_list_services — read quotes and the quotable product/service catalog (read)
• at_list_todos, at_list_todo_action_types — read CRM to-dos and their action types (read)
• at_create_opportunity, at_update_opportunity — create/update an opportunity (write)
• at_create_quote, at_add_quote_item — create a native CPQ quote and add line items (write)
• at_create_todo, at_update_todo — create and update CRM to-dos (write)

Reports

• at_list_reports, at_run_report — a curated report catalog for time/ticket/company/contact analytics; large results are written to a workspace file, not dumped into the ticket (read)

Attachments

• at_list_attachments, at_download_attachment — attachment metadata and content on a ticket (read)
• at_upload_attachment — attach a file to a ticket (write)

Skills built on top of the tools

• Autotask operations — the foundation skill. It encodes the platform’s hard rules: statuses are global (not per-queue), Autotask uses queues rather than boards, picklist ids are integers you resolve rather than hardcode, time entries require a resource id, and calls are serialized rather than fanned out in parallel (to respect the concurrency limit).
• Autotask projects operations and Autotask reports operations — ready-made workflows for building/reasoning about projects and running the report catalog.

How AI uses it: a real ticket

A ticket comes in referencing “T20240517.0042: VPN drops for remote staff every afternoon.”

The agent resolves the ticket number to its internal id, then, through the Autotask MCP, pulls the account, the affected contacts, the firewall configuration item on the account, and recent tickets for the same company. It finds two prior tickets with the same symptom, both resolved by adjusting an IPsec rekey timer after an ISP change. It reads the contract to confirm the work is in scope, and writes the internal note before the tech opens the ticket:

Recurring VPN drop (T20240517.0042). Matches two prior tickets (same account): afternoon disconnects tied to IPsec rekey after the June ISP swap. Both resolved by extending the rekey timer on the firewall CI. Contract: managed network, in scope. Suggested action: Apply the same rekey-timer change on the firewall CI, confirm with site, log time against the managed-network contract.

The tech reads that in thirty seconds and applies a known fix. The agent logs the time entry against the right contract on the way out, and the note is written back to the ticket in Autotask, no tab-switching required.

Build vs. buy

Building your own Autotask MCP means, before any code, surviving the developer-program approval, then building rate-limit-aware request handling, ticket-number resolution, multi-tenant scoping so Client A never sees Client B’s data, and an audit-and-permission layer you’d trust enough to enable write actions. Then you maintain it as Kaseya evolves the API. The API being pleasant to work with is real, but it’s the smallest part of the total cost.

Buying makes sense when you want Autotask as part of an agent that works across your whole stack, when the multi-week onboarding and rate-limit engineering aren’t how you want to spend a month, and when having the output embedded inside Autotask (not bolted on beside it) actually matters to adoption.

Autotask MCP server: the bottom line

Autotask has one of the nicer PSA APIs to work with, hidden behind one of the more demanding ways to get access to it. A good Autotask MCP absorbs the front-loaded pain: the Kaseya developer-program process, the integration code, the rate limits, and the ticket-number translation, and then adds the parts that make it usable day to day: smart tooling, unified audit logs, per-user permissions, and output embedded as an insight widget inside Autotask itself. The API is the easy part. The MCP is everything around it.

---

Want to see this on your own Autotask? Book a 15-minute demo. We’ll connect to your instance, pull a few real tickets, and show you the agent working inside Autotask, no developer-program wait required.