ConnectWise MCP Server: Give AI the Whole Ticket, Not Just the Summary

A ConnectWise MCP server connects your ConnectWise PSA to an AI agent like Claude or ChatGPT, so the model can read and act on your tickets, companies, configurations, time entries, and agreements through a standard protocol. The hard part isn’t the connection. ConnectWise holds some of the richest operational data in your MSP, but getting an agent to use it well means solving two problems ConnectWise itself doesn’t: its search barely reaches the data that matters, and its API expects you to already know a lot before it lets you do anything.

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. ConnectWise is one piece of Junto’s MCP for MSPs, which runs the same pattern across your whole stack. This post is specific to ConnectWise: why its data is hard to use, what a good ConnectWise MCP has to handle, and the full list of tools and skills our MCP exposes.

ConnectWise has the data. Its search can’t reach it.

Every real answer in ConnectWise lives in the ticket. Not the summary line, not the type/subtype, but the actual back-and-forth: the notes where a tech described the symptom, the thing they tried, the setting they changed, and the sentence that says “fixed it by resetting the print spooler and pinning the driver.”

ConnectWise’s native search doesn’t reach that. You can search a ticket’s summary, type, and subtype, and that’s most of it. The conversation, where the diagnostic history and the resolution actually are, isn’t searchable in any useful way. So when the same printer goes offline again three months later, nobody finds the ticket that already solved it. The knowledge is in your PSA. It’s just unreachable.

A ConnectWise MCP server is only as good as the data it can surface, so the first thing ours does is fix the search problem. We index the full note history of every ticket, not just the metadata, into a smart, dynamic database the agent can query semantically. When a new ticket comes in, the agent can find the prior tickets that describe the same symptom, read how they were actually resolved, and bring that resolution into the new ticket, even when the summary lines look nothing alike.

Every ticket gets a clear root issue and resolution

Indexing bad data faster just gives you bad answers faster. ConnectWise data quality is uneven because it depends on whatever the tech typed on the way out the door, and “closed, resolved” is a common last note.

So the agent does more than read. On every ticket it works, it makes sure two things are captured explicitly: the root issue (what was actually wrong) and the resolution (what actually fixed it), written in plain language and stored consistently. Over time this turns a pile of inconsistent notes into a structured, reliable record, which makes the next search better and the next resolution faster. The MCP isn’t just a read pipe into ConnectWise; it improves the data it reads.

The ConnectWise API is powerful, but particular

ConnectWise’s API can do almost anything the UI can, but it’s unforgiving about how you ask. Creating a ticket, for example, isn’t one clean call. You have to supply a board, and the valid status/type/subtype/item values depend on that board, and you need the right company and site identifiers, and several of those have to be resolved before the create call will succeed.

Left to figure this out on its own, an AI agent burns calls on trial and error: attempt, get rejected for a missing or invalid field, look up options, try again. That’s slow, it’s noisy, and it’s exactly the kind of thing that makes people distrust agent automation.

Our ConnectWise MCP builds the skilling for this in. The tools know what ConnectWise requires and resolve those prerequisites automatically (the right board, the valid status and type/subtype for that board, the company and site) before making the call, so a “create a ticket” instruction becomes one reliable action instead of a five-call guessing game. The tooling encodes how ConnectWise actually works so the agent doesn’t have to discover it every time.

One setup note: ConnectWise also requires a developer client ID, which you register for at developer.connectwise.com. Any real ConnectWise integration, DIY or otherwise, needs one. Our ConnectWise PSA setup guide walks through registering it and connecting your instance.

What our ConnectWise MCP does differently

Connecting an agent to ConnectWise is table stakes; that part is the ConnectWise integration itself. Three things separate a ConnectWise MCP you’d actually run in production from a raw API wrapper.

1. Smart tooling built by people who know ConnectWise

The tools are built by people who use ConnectWise to its fullest and understand its API structure: what you can and can’t do, which fields depend on which, and how to get an answer in as few calls as possible. That matters more than it sounds. A naive wrapper might make a dozen calls (and hit rate limits) to assemble what a well-designed tool returns in one. The difference between an MCP that’s pleasant to run at scale and one that’s constantly rate-limited and half-broken is almost entirely in how the tools are designed against the real API.

2. Unified audit logs across every application

Every action the agent takes is logged in one place: not just in ConnectWise, but across every application it touches. No more hunting through separate systems asking “wait, what did the agent actually do? Who authorized that?” You get one audit trail, with the same granular access controls MSPs already expect, so an agent touching your PSA is at least as accountable as a technician touching it.

3. Centralized permissions by user or group

Access is controlled per user or per group. Some people can see agreement and billing data; some can’t. Some are allowed destructive actions like merging tickets; others aren’t. You set those boundaries once, centrally, and they apply to what the agent will do on each person’s behalf. That’s the control layer that lets you actually turn write actions on, instead of keeping everything read-only because you can’t scope who’s allowed to do what.

The full list of ConnectWise capabilities

Our ConnectWise Manage MCP exposes 66 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, irreversible or billing actions are approval-gated by default (flagged below).

Tickets

• cw_get_ticket — full detail of a ticket by id (read)
• cw_search_tickets — find related or duplicate tickets; requires at least one filter (read)
• cw_get_board_info — valid statuses, priorities, and types for a board (read)
• cw_create_ticket — create a ticket under a company and board (write)
• cw_update_ticket — update status, priority, board, or summary (write)
• cw_close_ticket — move a ticket to its board’s closed status (write)
• cw_change_board — move a ticket to a different service board (write)
• cw_bundle_tickets — group related tickets under a parent; reversible (write)
• cw_reassign_ticket_company — move a ticket to a different company (write · approval-gated)
• cw_merge_tickets — merge tickets into a parent; irreversible (write · approval-gated)

Ticket notes

• cw_create_internal_note — technician-only note the customer never sees (write)
• cw_create_discussion_note — customer-facing note (write)
• cw_create_resolution_note — resolution write-up recorded on close (write)

Boards and members

• cw_list_boards, cw_get_board_statuses, cw_search_members — list boards, a board’s statuses, and technicians (read)

Time and scheduling

• cw_get_time_entries, cw_list_charge_codes, cw_list_activities, cw_list_activity_types — time entries on a ticket, charge codes, and activity targets (read)
• cw_create_time_entry — log time against a ticket (write)
• cw_create_schedule_entry — schedule a member onto a ticket (write)
• cw_create_activity — create a standalone sales activity or task (write)

Companies and contacts

• cw_list_companies, cw_get_company_finance, cw_list_contacts — search companies, read billing settings, search contacts (read)
• cw_create_company, cw_update_company, cw_update_company_finance — create/update a company and its finance record (write)
• cw_create_contact, cw_update_contact, cw_add_contact_communication — create/update a contact and add email/phone (write)

Configurations (assets)

• cw_list_configurations, cw_list_configuration_types — list a company’s assets and asset types (read)
• cw_create_configuration, cw_update_configuration — create/update an asset (write)
• cw_add_configuration_to_ticket, cw_remove_configuration_from_ticket — attach/detach an asset to a ticket; reversible (write)

Documents and attachments

• cw_list_documents, cw_download_document — list and download attachments on a ticket (read)
• cw_upload_document — upload a file or image to a ticket (write)

Finance and invoices

• cw_get_invoice, cw_search_invoices — fetch and search invoices (read)
• cw_create_invoice — create an invoice header (write · approval-gated)

Opportunities and sales

• cw_list_opportunities, cw_get_opportunity, cw_list_opportunity_statuses, cw_list_opportunity_forecast — read the sales pipeline (read)
• cw_create_opportunity, cw_update_opportunity, cw_create_opportunity_activity, cw_add_product_to_opportunity — create/update opportunities and add lines (write)
• cw_delete_opportunity — permanently delete an opportunity; irreversible cascade (write · approval-gated)

Products, catalog, and agreements

• cw_search_products, cw_search_agreements, cw_list_agreement_additions, cw_search_product_catalog, cw_search_sales_orders, plus cw_list_product_types / _categories / _subcategories — search catalog, agreements, and product taxonomy (read)
• cw_create_product_catalog_item, cw_add_product_to_sales_order, cw_add_product_to_ticket — create catalog items and add product lines (write)
• cw_add_product_to_invoice, cw_add_agreement_addition — add billable lines to an invoice or agreement (write · approval-gated)

Reports

• cw_list_reports, cw_get_report_columns, cw_run_report — list, inspect, and run ConnectWise’s server-side reports (read)

Skills built on top of the tools

Beyond individual tools, the MCP ships packaged skills: encoded ConnectWise know-how the agent follows so it doesn’t rediscover the rules each time.

• ConnectWise operations — the foundation skill. It encodes the non-obvious model: statuses are defined per board (not global), filters and names must match exactly, a ticket search needs at least one filter, and discussion notes are customer-visible while internal notes are not.
• Stale ticket review, open-ticket backlog report, time-entry review, and ticket report — ready-made workflows built on the tools above.

(ConnectWise CPQ and ConnectWise RMM are separate integrations with their own tools, not part of the Manage/PSA set above.)

How AI uses it: a real ticket

A ticket comes in: “Reception printer keeps dropping offline again.”

With a native ConnectWise search, “again” is a dead end. The summary doesn’t match any prior ticket, and the type/subtype are just “Hardware / Printer.” The tech starts from scratch.

With our ConnectWise MCP, the agent searches the indexed note history, not the metadata, and finds a ticket from four months ago at the same company: same printer, same symptom, resolved by assigning the printer a static IP and pinning a specific driver version after a firmware update kept resetting it. It pulls the configuration record for the printer, confirms the driver, and writes the internal note before the tech opens the ticket:

Recurring issue. Matches ticket #41207 (same site, 4 months ago): printer drops offline after DHCP lease renewal. Resolved then by static IP + pinning driver v2.1 (firmware update reverts the driver). Config record shows driver back to v2.4. Suggested action: Re-pin driver v2.1 and set static IP per prior resolution. Confirm with site before firmware auto-update reverts it again.

The tech reads that in thirty seconds and applies a known fix instead of rediscovering it. On the way out, the agent records the root issue and resolution cleanly, so the next time it recurs, the trail is even shorter.

Build vs. buy

You can build a ConnectWise MCP yourself. You’ll need the developer client ID, an auth flow, and tool definitions for the endpoints you care about. What takes the time isn’t the first read tool; it’s everything this post is about: indexing note history so search is actually useful, keeping ticket data quality high, encoding the API’s field dependencies so writes don’t fail, 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.

Buying makes sense when you want ConnectWise as part of a broader agent that works across your whole stack, when data isolation and per-user permissions are non-negotiable, and when you’d rather not re-fix the integration every time ConnectWise changes something.

ConnectWise MCP server: the bottom line

ConnectWise holds the operational history of your MSP, but its native search stops at the summary line and its API makes an agent work to do anything. A good ConnectWise MCP closes both gaps: it indexes the full conversation so the agent can find how things were actually resolved, it keeps ticket data clean enough to trust, it knows the API well enough to act in one call instead of five, and it wraps the whole thing in audit logs and per-user permissions. The data is already in ConnectWise. The point of an MCP is to finally make it usable.

---

Want to see this on your own ConnectWise? Book a 15-minute demo. We’ll connect to your instance, pull a few real tickets, and show you what the agent finds in the note history that your search can’t.