ConnectWise Automate MCP server and AI skills

What it can do

• ComputersFind machines and read them in full — hardware down to the slot, installed software, services and drivers, what has run on them, and the alerts and patch posture attached.33skills

  Reads the record only — nothing here runs anything on a machine, reboots it, or changes a field.

  • Find agents by anything Automate tracks — name, online state, client, address — and get back the trimmed record.
  • Answer 'how many' directly: counts every matching agent across the fleet without dragging the list back with it.
  • Open one machine's full record — everything Automate holds about that agent.
  • Every application installed on one machine, as the agent last inventoried it.
  • What's inside one machine — processors, memory slots, and drives.
  • What's executing on a machine right now, and what's queued behind it.
  • The trail of commands that have run on a machine — where you go when something changed and nobody owns it.
  • Every alert raised against a single machine, so you can see whether it has been shouting for weeks.
  • One machine's patch posture — compliance, what's outstanding, whether it's waiting on a reboot.
  • The firmware one machine is actually running, which is where a fleet-wide firmware advisory stops being guesswork.
  • The exact build and edition a machine is on, not the family name in the console header.
  • What a machine reports itself to be — the honest way to tell a laptop from a desktop from a virtual machine.
  • Everything plugged into one machine, down to the dock nobody documented.
  • The adapters one machine has, with the addressing that explains why it keeps landing on the wrong subnet.
  • Which printers a machine can actually see, for the ticket that just says printing stopped.
  • Every Windows service on one machine and the state it's in — the first place to look when an agent is present but silent.
  • The expansion slots in one machine, with free and occupied counts, before anyone orders the card.
  • The battery backup attached to a machine, so a site outage report can say which kit had one.
  • The display adapters in one machine, for the driver complaint that never quite reproduces.
  • Sensor readings off one machine — temperature, fan and voltage — before hardware fails slowly, then loudly.
  • Which server roles one machine is really running, so 'it's just a file server' can be checked rather than believed.
  • The driver inventory on one machine, which is where a recurring crash usually has its answer.
  • What the operating system's own scheduler runs on a machine — the automation that isn't yours.
  • A drive's own health diagnostics on one machine, read before the disk gives up rather than after.
  • The history of commands already executed on one machine, with who ran what and how it finished.
  • One of those command runs opened in full — what was asked for, and what came back.
  • Windows event-log entries collected off the agents, narrowed to a machine and a time window.
  • Space and utilization for specific drives over a lookback window — the growth curve, not just today's number.
  • How one drive's free space has moved over time, which turns 'nearly full' into a date.
  • Chassis records across the whole fleet at once — the fastest laptop-versus-desktop split you can get.
  • Every drive in the fleet in one sweep, for the capacity plan nobody wants to build by hand.
  • Memory slots across the fleet, so 'can we upgrade these instead of replacing them' has a real answer.
  • The installed-software inventory across the whole tenant — huge, and the only honest way to answer 'who still has this'.
• Clients & sitesThe companies you manage, the sites beneath them, and the people attached to both.5skills
  • Search the company list — who you manage, by name.
  • The full record behind one company, including the fields your scripts and searches key off.
  • Find sites — the offices and buildings sitting under each company.
  • One site in full, with stored credentials stripped out before the answer leaves the server.
  • Search contacts by name or email — the people attached to each client and site.
• PatchingCompliance from the whole tenant down to one device, what is missing and how exposed it leaves you, and the approval, update and override policies that decide all of it.33skills

  Reads patch state and patch policy — nothing here approves, deploys, declines or removes a patch, or triggers a reboot.

  • The tenant-wide Windows servicing picture — which releases and channels your servers and workstations are actually on.
  • The same servicing-branch picture narrowed to one company — the number you take into a quarterly review.
  • Search machines by patch posture: compliance percentages, reboot-pending, and patch jobs in flight.
  • One device's complete patch record, not just the headline percentage.
  • What's missing across the tenant, broken out by severity and exposure band — the risk, ranked.
  • The install-and-scan trail — what patched when, and what came back failed.
  • Windows servicing compliance narrowed to one location, for the site that always lags.
  • The approval rules — test, pilot and broad rollout — that decide what approves itself, searchable, so 'why did that land' has an answer.
  • One approval policy in full, including the automatic approve, ignore and deny settings buried inside it.
  • Which Windows patches one approval policy governs.
  • Which non-Microsoft patches one approval policy governs.
  • How many patches are sitting unapproved under the default policy — the backlog nobody is watching.
  • The Windows update policies configured on this server, searchable.
  • One Windows update policy in full.
  • The non-Microsoft update policies configured on this server, searchable.
  • One non-Microsoft update policy in full.
  • The per-machine overrides that quietly exempt a device from the patching its group would give it.
  • The patching override on one machine, if it has one.
  • Every patching policy one machine inherits through its groups.
  • The policy actually in force on one machine once group order and overrides resolve — the answer, not the inputs.
  • A device-count rollup by patch state, tenant-wide or scoped to one client or one site.
  • The Windows patch rollup by count and severity, tenant-wide or scoped to one client or one site.
  • Missing Windows patches by severity and exposure band, scoped to a client or a site when the tenant number is too blunt.
  • The non-Microsoft patch rollup, tenant-wide or scoped to one client or one site.
  • The full Windows patch catalogue this server knows about, searchable by severity.
  • The full non-Microsoft patch catalogue this server knows about.
  • Every version of one third-party product the server tracks — the version spread hiding behind a single 'out of date'.
  • The classification tree patches are filed under, which is what a policy's rules actually target.
  • The patching subsystem's own status on this server — read it before blaming a client's machines.
  • Every Windows update one machine has, with its state — the row-level view behind the percentage.
  • Every non-Microsoft patch on one machine, with its state.
  • The patch jobs that have run on one machine, and how each of them finished.
  • The reboot rules patch manager applies — which is usually why machines sit pending forever.
• MonitoringWhat you watch, what it has been telling you over time, the tickets it raised, and every window where alerting was deliberately turned off.25skills

  Reads monitors and their history — nothing here creates, edits or suspends a monitor, or acknowledges an alert.

  • Search what you're actually watching — internal and remote monitors, with last status and failure counts.
  • One monitor's full definition — the thresholds and settings behind the alert.
  • Search raised alerts by machine, monitor, client, or severity — the noise, finally sortable.
  • One raised alert opened in full.
  • Results from the agent-side health checks that run on the machine itself.
  • Pass and fail history across every monitor — the flapping you only notice when you look at a month of it.
  • Pass and fail history for one monitor, so a noisy alert can be proved noisy.
  • Monitor statistics across the tenant, for ranking what fires most before anyone tunes anything.
  • The statistics behind one monitor.
  • One monitor's collected readings averaged by day, week, month or year — the practical way to see a trend.
  • Every raw reading one monitor collected — heavy, and the only view when an average hides the spike.
  • What one monitor stores and for how long, which decides whether the history you want exists at all.
  • Every monitor attached to one machine — coverage per device, not per group.
  • The agent-side checks running on one machine.
  • Everything currently muting alerts on one machine, whatever put it there.
  • Alerts muted on one machine because a maintenance window is open.
  • Alerts muted on one machine because a template diverted them somewhere else.
  • The maintenance windows scheduled on one machine.
  • Maintenance windows queued on one machine but not started yet.
  • Every maintenance window open across the fleet — the first thing to read before calling a quiet night a monitoring gap.
  • When alerting is suppressed and where, as the server has it configured.
  • The hardware sensor checks defined on this server — what temperature or fan state would actually raise something.
  • One sensor check's definition in full.
  • Search the tickets Automate raises in its own ticketing system — mostly what monitors turned into work.
  • One of those tickets opened in full.
• Scripts & automationThe script library and how it's filed, the schedules that fire on their own, the built-in command catalogue, and what automation has actually saved.15skills

  Catalogue and history only — there is no execute path, so nothing here runs, queues or schedules a script or a command.

  • Search the script catalogue — names, folders, and the comments whoever wrote them left behind.
  • One script's definition and metadata, read straight from the catalogue.
  • The whole folder tree, so you can see how the script library is organized.
  • The same folders as a flat list, for when the tree is the wrong shape to search.
  • One script folder's record.
  • Every script running or queued across the tenant at this moment.
  • The recurring schedules — what fires on its own, and when.
  • What is scheduled to run on one machine, searchable.
  • One scheduled run on one machine, opened in full.
  • What has run on one machine and how each run finished.
  • The individual script runs recorded against one machine.
  • The built-in agent commands this server offers — definitions only, so you can see what exists before anyone asks for it.
  • One built-in command's definition.
  • How much technician time automation has saved over a lookback window — the number a client review never has.
  • The same time-saved figure broken out per technician.
• Groups & searchesThe groups that target everything, the saved searches that decide who lands in them, and the data views built on top.17skills

  Reads definitions and membership — nothing here adds a machine to a group, edits an auto-join search, or runs a data view against live data.

  • Search groups by their dotted path — the targeting unit behind scripts, monitors, and patch policy.
  • One group's full record, including the auto-join search that feeds it — how machines get in, not just which ones did.
  • The entire group hierarchy in one call — parents, children, and the deployment branches nobody uses.
  • The raw membership rows — which machines sit in which group, and how many, for coverage math.
  • Every link between a group and a patching policy, so you can see which groups patch at all.
  • The patching policy attached to one group.
  • Which people are attached to which group — who gets told when that group's monitors fire.
  • One of those group-and-contact links in full.
  • Which agentless devices sit in which group — targeting for the kit that has no agent.
  • One of those group-and-device links in full.
  • Search the saved-search definitions — including the ones deciding who lands in which group.
  • One saved search's full definition — the criteria it actually matches on.
  • The folders your saved searches are filed under, which is how you find the one somebody built years ago.
  • The saved data views defined on this server — the reporting shapes your team already agreed on.
  • One data view's definition in full.
  • The folder structure those data views live in.
  • One data-view folder's record.
• Network & probesWhat your probes can see at each site, what is sitting there with no agent on it, and the routers and agentless kit behind any coverage number.19skills

  Reads discovery results and probe configuration — nothing here starts a scan, changes a probe, or deploys an agent.

  • How many devices a site's probes can see with no agent on them — the coverage gap, as a number you can hand over.
  • Everything a probe has discovered at one site — the raw list behind any coverage claim.
  • The discovered topology at one site, subnet by subnet.
  • One discovered machine's entry on that map.
  • One discovered agentless device's entry on that map.
  • How probe coverage and health look at one site — the other half of the coverage-gap picture.
  • Whether a site's last discovery scan finished, and when.
  • How a site's probe is set up, outside the credentials it scans with.
  • Which probe serves a site — the lookup every other probe question needs first.
  • The probe's own log: scans started, scans finished, and the errors in between.
  • What has been asked of the probes, as history.
  • The server-wide defaults a newly deployed probe inherits.
  • Which subnets a probe is set to scan — and therefore which ones it will never find anything on.
  • The addresses deliberately left out of a probe's scan.
  • Whether network mapping is switched on for a probe at all, which explains an empty map.
  • The reference tables probe configuration is built from — scan frequencies, event levels, encryption choices.
  • The routers configured on this server, with stored passwords stripped before the answer leaves it.
  • The agentless kit your probes found — switches, printers, routers — with online state and printer health.
  • The full record for one probe-discovered device, credentials withheld.
• Security & accessWho can sign in, what their role lets them touch, what they did and when, and the antivirus and feature settings this server is running.21skills

  Reads accounts, permissions and the audit trail — nothing here creates, disables, unlocks or re-permissions anyone.

  • Search the technician accounts on this server, including the locked ones.
  • One technician account in full, password material excluded.
  • Why an account is locked — failed attempts, where they came from, and when it clears.
  • The permission classes your technicians are assigned to.
  • One permission class in full, with every grant it carries.
  • Which custom console panels a permission class can reach.
  • The audit trail of who changed what and when — the first thing an auditor asks for, without a console export.
  • The tenant-wide grant list tying people to permissions.
  • The permission grants scoped to one company.
  • The whole client permission matrix in one read.
  • Who can see or manage one particular machine.
  • How one company overrides one permission class — the exception nobody remembers making.
  • Which server features are switched on, which is often why a console does not match the documentation.
  • One feature setting's record.
  • The antivirus products this server knows how to recognise on an endpoint.
  • One of those antivirus product definitions.
  • The antivirus configuration bundles applied when an agent is deployed.
  • One antivirus template policy in full.
  • The settings rows underneath those policies — what they actually apply, not what they are called.
  • What the connected login itself is allowed to see, including whether it is limited to certain folders.
  • Which agent commands the connected login's role is permitted to invoke.
• Licensing & assetsWhat this server is licensed for, what each client's software licences, keys and documents say, and the kit you have retired.7skills

  Reads licence, key and document records — nothing here adds, edits or retires one.

  • What this Automate server itself is licensed for.
  • The software licences tracked for one company.
  • The product keys recorded against one company's software — real key material, so treat the answer as sensitive.
  • The documents filed against one company, searchable by name.
  • One client document's details.
  • The decommissioned kit, searchable — lifecycle and attrition reporting without a spreadsheet.
  • One retired asset's full record.
• Reference & serverThe custom fields your scripts key off, bulk lookups that answer for the whole fleet in one call, deployment templates and quick links, and what the server itself reports.22skills

  Reads configuration and reference data — nothing here sets a custom field, edits a template, or changes a server setting.

  • The custom fields stored on one machine, with their current values.
  • One company's custom fields — where most MSPs park deployment flags and per-client config.
  • The custom fields recorded against a single site.
  • The custom fields attached to one contact, on newer Automate builds.
  • Pull custom fields across the whole fleet at once — every client's stored values in one sweep.
  • Patch posture for a client's entire machine list in one call — compliance and reboot-pending counts together.
  • Installed-software inventory across a shortlist of machines at once — the way to spot-check whether an agent actually landed.
  • Patching policy for many groups in one call, so a whole tenant's policy map arrives at once instead of group by group.
  • The deployment templates new agents are built from, with the embedded credentials withheld.
  • One deployment template, with the same credential fields withheld.
  • The deployment and inventory schedules that keep agents current.
  • One of those schedules in full, down to its per-inventory sub-schedules.
  • The quick links configured in the console — the shortcuts your techs actually use.
  • One configured quick link.
  • The server-level notification contacts — who hears about it when nothing client-specific applies.
  • One server-level notification contact.
  • Your Automate server's build and version — the first thing to check when a feature should exist and doesn't.
  • What your own server supports — no two Automate servers offer quite the same thing, so this is what settles whether a question is answerable here before a report is built on it.
  • The licensing account this server belongs to.
  • The server's own clock and offset — read it before trusting any comparison between timestamps.
  • The tenant-wide agent rollup: how many there are, and how healthy they look.
  • Which Solution Center plugins this server has wired in — antivirus, backup, warranty — which is what the tenant really runs.

How it has been taught to work it

Playbooks are the vetted techniques a session loads for this platform — what to check, in what order, and what a number means before it is reported.

• Automate ↔ ScreenConnect — which clients are missing which coverage"Which clients have Automate agents but no ScreenConnect (or vice versa)" — remote-access coverage gaps, reconciling managed endpoints against remote-access reach.
  Vetted Sep 21, 2026
• Automate domain model (what the application IS)Always when Automate is attached. Its domain model.
  Vetted Sep 2, 2026Always on
• Every tenant is a DIFFERENT Automate serverAlways when Automate is attached. Every tenant is a different server.
  Vetted Jul 31, 2026Always on
• Finding clients, locations and contacts in AutomateResolving a client name to an id, what locations does a client have, who are the contacts, before any client-scoped Automate question.
  Vetted Aug 1, 2026
• Full-fleet pulls — paging, de-duping, aggregatingPulling the whole fleet, per-client breakdowns across all clients, anything needing more rows than fit in context.
  Vetted Aug 1, 2026
• Machine & fleet health drilldownsIs a machine or fleet healthy; offline, disk, drilldowns on one client.
  Vetted Aug 1, 2026
• Monitoring & alerts questionsMonitors, alerts, what is currently firing, alert suspensions.
  Vetted Aug 1, 2026
• MSP-analyst answer workflowsClient health snapshots and QBR-shaped multi-part answers.
  Vetted Aug 3, 2026
• Network discovery & probe coverage (per-site network map, probe health/config)What's on a site's network without an Automate agent, probe health/config at one location, network-map topology, router inventory, probe event/command history.
  Vetted Sep 2, 2026
• Operator accounts, permission classes, feature flags & AV policy configWho has Automate access, locked-out technicians, permission classes/roles, what a role can actually do, the user-action audit trail, feature flags, antivirus template policy config.
  Vetted Sep 2, 2026
• Patch compliance questionsPatch compliance, missing or failed patches, reboot state, patch policy.
  Vetted Aug 2, 2026
• Patch-policy configuration (approval rules, update policies, catalogs)What approval policy governs a client's patching, Microsoft vs third-party update policy config, per-computer patch overrides, browsing the Windows/third-party patch catalog, policy-scoped compliance rollups. NOT for "is this machine compliant right now" — that's [[patching]].
  Vetted Sep 2, 2026
• Querying ConnectWise Automate (live-build nuances)Always when Automate is attached. Conditions, paging, and its silent no-ops.
  Vetted Sep 2, 2026Always on
• Scripts & automation questionsScripts, script folders, scheduled or running scripts, command history.
  Vetted Aug 1, 2026

Plus 18 more every session carries regardless of platform — how to shape an investigation, keep every number traceable, and say plainly when something is broken.