NinjaOne logo
Live

NinjaOne MCP server and AI skills

Your whole RMM — and its ticketing — answerable in plain English.

NinjaOne runs your clients' endpoints, and it carries its own ticketing/helpdesk on top. Connect your instance and a session can read all of it: which organizations and devices it manages, what's healthy or alerting, OS-patch and software inventory across the fleet, and the full ticket system — boards, tickets, statuses, and each ticket's log. Reads only today: no credential we issue carries a write scope, and no connected session can reach a write tool, so nothing here runs a script, pushes a patch, moves a device, or touches a ticket. Switchboard connects through an MSPStuff-hosted MCP server, so there's nothing to install and no API keys to hand your techs.

  • 23 skills
  • 6 playbooks
  • Read-only by default
  • Every answer traced
See the shape of an answer

A question in plain English. A result you can work with.

This illustrative session shows one of the documented questions below. Your results come from your connected environment and the access your admin grants.

NinjaOne · illustrative session
“Which devices haven't checked in for a week, across every organization?”
Here are the devices that have been quiet for at least a week.
Stale devices across organizations
Device / organizationLast seen
ACME-WS-04 · Acme14 days ago
HBR-LT-12 · Harbor10 days ago
NTH-WS-06 · Northstar8 days ago
Example source: NinjaOne · scoped read
Sample data. Illustrative results, not a customer report.

The story

What changes once it’s connected.

Hosted and external AI connections provide read-only access. Guidance, shared playbooks and automations we release for everyone are included with Dedicated. Bespoke automation builds are scoped separately. Any change a platform could make is held back — refused by our server before anything reaches the platform — until a person switches it on, and nothing is switched on today. Vendor consent does not switch any change on.

The questions that matter about an RMM rarely stop at one organization. Which devices haven't checked in for a week — across every client. Pending OS patches, grouped by organization, so you can see who's actually behind. What triggered last night's alerts. Connected, those get asked once and answered across the whole book of clients, instead of one console tab per org.

The coverage follows how NinjaOne is really structured. Organizations — the clients — down through Locations to Devices, with a device-health rollup as the first call for 'what is unhealthy'. Inventory as its own surface: installed software, OS-patch status, and antivirus status, fleet-wide. Alerts and the activity feed for 'what is firing right now'. And the fleet model itself — device groups, roles, and agent policies — which is what lets a session reason about the fleet rather than just list it.

NinjaOne is unusual in this catalog because it also has a real helpdesk, and the connector reads it: ticket boards, the tickets on a board, a ticket in full, its comment and activity log, the status list, and the custom-field definitions. That means a session can cross-reference a firing alert against the ticket that should already exist for it — RMM state and service state from one connection. Nothing here opens, assigns, or closes a ticket — to act, a human uses the NinjaOne console. Any change the integration could make in NinjaOne is held back — refused by our server before anything reaches NinjaOne — until a person switches it on, and nothing is switched on today.

Things you can ask

Ask it like you’d ask a teammate.

>Which devices haven't checked in for a week, across every organization?
>Pending OS patches, grouped by organization — who's furthest behind?
>What triggered last night's alerts?
>What software is installed across that client's fleet?
>Which endpoints are reporting antivirus problems right now?
>What tickets are open on the helpdesk boards, and what's the latest on ticket 4821?
>Which organizations have the most devices, and how healthy are they?

Skills and playbooks

Every skill, in the open.

23skills6playbooksLast vetted Sep 21, 2026

Read-only today, across every organization NinjaOne manages: device health and alerts, software, patch and antivirus inventory, the fleet model, and the helpdesk. No credential we issue carries a write scope, and no connected session can reach a write tool — so there is no path from a session to running a script, pushing or approving a patch, moving or rebooting a device, changing a policy, or opening, assigning or closing a ticket. The credential is your own NinjaOne client-credentials app, scoped for monitoring reads, so everything a session sees is exactly what that app can see and every read is attributed to it. Any change the integration could make in NinjaOne is held back — refused by our server before anything reaches NinjaOne — until a person switches it on, and nothing is switched on today.

What it can do

  • Organizations & sitesThe shape of the instance: the client organizations NinjaOne manages, their locations (sites), and the devices and sites under one org — the resolver for 'which client is this about'.5skills

    Reading only — no organization, location, or mapping is created or changed from here.

    • List customer organizations — resolve a client name to its org id.
    • Everything NinjaOne holds about one client — the record behind the name, when the id alone is not enough.
    • Locations (sites) across every organization.
    • Every endpoint that belongs to one client, so "what do we actually manage for them" has an answer before the renewal call.
    • The sites one client runs, which is how a fleet-wide problem gets narrowed to the office it is actually in.
  • Devices & healthThe endpoint roster, from a fleet-wide health rollup down to one machine's full detail, plus the device-data query behind the inventory views.4skills

    Reading only — no device is moved, rebooted, or sent anything. Health flags are triage filters, not actions.

    • Page through devices, filtered by NinjaOne's device-filter syntax.
    • One machine opened in full — the whole record behind a health flag, not the summary row.
    • Device-health rollup across the fleet — the first call for 'what is unhealthy'.
    • Run a device-data query (the dataset engine behind software / patches / AV).
  • Software, patches & AVFleet-wide inventory as three cursor-paged datasets: installed software, OS-patch status, and antivirus status.3skills

    Reading only — nothing is installed, patched, or scanned; a pending patch is a fact, not an instruction.

    • What is installed across the fleet — the fastest way to answer "who still has that application" when an advisory lands.
    • Where patching really stands across every client, so "are we behind" is a number rather than a feeling.
    • Which endpoints are reporting antivirus trouble right now — the protection gap, before someone else finds it.
  • Alerts & activityThe 'what is happening right now' surface: active condition alerts, and the activity feed of jobs, alerts, and actions.2skills

    Reading only — no alert is reset or acknowledged, and no job is run.

    • What is firing right now across every client, so triage starts from the whole fleet instead of one console tab.
    • Activity feed — jobs, alerts, and actions, cursor-paged.
  • Groups, roles & policiesThe fleet model a session reasons over: device groups (saved searches), device roles/node classes, and agent policies.3skills

    Reading only — no group, role, or policy is created, edited, or assigned.

    • Device groups (saved device searches), with counts.
    • How NinjaOne classifies the machines it manages — servers from workstations from hypervisors, when a question needs the right slice.
    • The agent policies in force, which is where "why is that machine behaving differently" usually has its answer.
  • Ticketing & helpdeskNinjaOne's built-in helpdesk, read end to end: boards, the tickets on a board, one ticket in full, its comment/activity log, the status list, and the custom-field definitions.6skills

    Reading only — no ticket is created, assigned, commented on, or closed.

    • Ticketing boards (saved ticket views) — find a board id.
    • Tickets on a board (a server-side board run that only reads).
    • One ticket in full — attributes, requester, priority, severity.
    • A ticket's comment / activity log — the conversation and audit trail.
    • All ticket statuses, to translate a ticket's status.
    • Ticket custom-field (attribute) definitions.

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.

  • Active threats, vulnerabilities and firing alertsSecurity posture on NinjaOne — active or quarantined threats, critical and high vulnerabilities, antivirus product state, what alerts are firing right now, which clients are exposed.
    Vetted Sep 21, 2026
  • NinjaOne — what the platform ISAlways when NinjaOne is attached. Its domain model — organizations/locations/devices, device health, alerts, tickets on boards — the definitions the mirror computes, and why it is neither Automate nor Asio.
    Vetted Sep 21, 2026Always on
  • Offline devices, by organizationWhich clients have machines offline or not checking in, who has the worst coverage, is this device actually down, agent contact and fleet roster questions on NinjaOne.
    Vetted Sep 21, 2026
  • Patch failures and pending patchesWhat is failing to patch, what is pending, which clients are behind on updates, OS versus third-party software patching, reboot-pending machines on NinjaOne.
    Vetted Sep 21, 2026
  • Querying NinjaOne — paging, device filters and boardsAlways when NinjaOne is attached. How to page it — three different result shapes on one surface — how device filters behave, which ticket board is which, and the traps found live.
    Vetted Sep 21, 2026Always on
  • Ticket backlog, unassigned and staleNinjaOne helpdesk questions — how big is the backlog, what is unassigned, what has been sitting, which client has the most open tickets, what happened on this ticket.
    Vetted Sep 21, 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.

Connecting

Wire it in, in an afternoon.

How to connect

  1. 01In NinjaOne, add a client-credentials API app (Administration → Apps → API) and grant the Monitoring (read) scope.
  2. 02Note your region host — the ***.ninjarmm.com you sign in at.
  3. 03Enter the region, client id, and secret on the connect page — it validates live against NinjaOne before saving.

Common questions

Asked before you had to ask.

Does NinjaOne have an API or MCP server?

NinjaOne publishes the NinjaOne Public API 2.0. MSPStuff hosts a NinjaOne MCP server for you: across every organization NinjaOne manages, tickets included, read-only today, with every answer traced to the real tool calls behind it and nothing to install or host yourself.

Is there an AI skill for NinjaOne?

Yes — MSPStuff ships AI skills for NinjaOne, hosted in Switchboard. You connect NinjaOne once; sessions then answer questions about it in plain English. There is nothing to install to use Switchboard and no API keys to hand your techs.

Is there a NinjaOne MCP server?

Yes. The NinjaOne integration is an MCP server that MSPStuff hosts and operates for you — Switchboard sessions call it with credentials you control, and every answer is traced to the real tool calls behind it.

Can it read NinjaOne tickets as well as devices?

Yes. NinjaOne carries its own ticketing, and the connector reads it — boards, tickets, statuses, and each ticket's log — alongside device health, patches and alerts, so a session can cross-reference an alert against its ticket.

Can it change anything in NinjaOne?

No. Read-only today: no credential we issue carries a write scope, and no connected session can reach a write tool, so nothing runs a script, pushes a patch, moves a device, or touches a ticket. Any change the integration could make in NinjaOne is held back — refused by our server before anything reaches NinjaOne — until a person switches it on, and nothing is switched on today. See the access section above for the exact guarantee.

Does this use the NinjaOne API?

Yes. The NinjaOne integration is an MSPStuff-hosted MCP server built on the NinjaOne API. Read-only today: no credential we issue carries a write scope, and no connected session can reach a write tool. You connect once with credentials you control; nothing is installed on your side.

Is there a NinjaOne connector for my AI?

Yes. Supported clients such as ChatGPT (OpenAI), Claude, Copilot and Cursor use the same MSPStuff MCP endpoint. Your admin controls access per person and data domain, and every platform call uses read-only permissions.

Get AI connected to your stack.

Apply for the beta: 14 days free on the Hosted plan against your own environment, read-only, every answer traced. Accepted MSPs get half off seats and client tenants for the first year. Dedicated infrastructure is priced separately.

MSPStuff