← Back to blog

NinjaOne MCP Server: Give AI Full RMM Context on Every Ticket

10 min read

A NinjaOne MCP server is the bridge between your RMM data and an AI agent. It takes everything NinjaOne knows — device health, patch status, alerts, installed software, OS details, scripting capabilities — and makes it available to Claude, GPT, or any AI model through a standardized protocol. Instead of your technician opening NinjaOne in a second tab to look up a device, the AI queries NinjaOne directly and brings the data into the ticket before anyone touches it.

If you’ve read about MCP (Model Context Protocol) in the context of MSPs, you know the general concept. For the broader picture on setting up Claude MCP servers across your MSP stack, see our companion guide. This post goes deeper on the NinjaOne-specific implementation: what data the NinjaOne API actually exposes, what a NinjaOne MCP server looks like in practice, the multi-tenancy challenges MSPs face when building one, and when it makes sense to build versus buy.

What the NinjaOne API gives you

Before you can build an MCP server for NinjaOne, you need to understand what’s available through the API. NinjaOne’s v2 API is well-documented and covers most of what techs look up manually. Here are the endpoint categories that matter for AI-assisted triage:

Device endpoints

The core of any NinjaOne automation. You can query devices by organization, get detailed system information for a specific device, and list all devices matching certain criteria.

  • GET /v2/devices — list devices with filters for organization, device class (workstation, server, cloud monitor), and status
  • GET /v2/device/{id} — full device details including hostname, OS version, last contact time, system info
  • GET /v2/device/{id}/os-patches — installed and pending patches, including severity ratings
  • GET /v2/device/{id}/os-patch-installs — patch installation history with timestamps
  • GET /v2/device/{id}/software — installed software inventory with versions
  • GET /v2/device/{id}/disks — disk utilization including capacity, used space, and free space
  • GET /v2/device/{id}/processors — CPU information
  • GET /v2/device/{id}/volumes — volume details

This is the data your tech manually checks when they open NinjaOne to investigate a device. An MCP server makes all of it available to the AI in a single structured response.

Organization endpoints

MSPs manage multiple clients, and NinjaOne organizes everything by organization. The API lets you list organizations, get details, and — critically — scope device queries to a specific organization.

  • GET /v2/organizations — list all organizations
  • GET /v2/organization/{id} — organization details including custom fields
  • GET /v2/organization/{id}/devices — all devices for a specific client

This per-organization scoping is what enables multi-tenant AI queries. More on that below.

Alerts and activities

  • GET /v2/alerts — active alerts across all organizations or filtered by device/org
  • GET /v2/device/{id}/alerts — alerts for a specific device
  • GET /v2/activities — activity log including system events, user actions, and automated task results

Alerts are particularly valuable for AI triage. When a ticket comes in about a slow server, the AI can check whether NinjaOne has active alerts for that device — high CPU, low disk, service failures — and include them in the triage context.

Scripting and actions

This is where a NinjaOne MCP server goes beyond read-only context:

  • POST /v2/device/{id}/script/run — execute a script on a device
  • POST /v2/device/{id}/reboot — trigger a device reboot
  • POST /v2/device/{id}/windows-service/{serviceId}/control — start/stop/restart a Windows service

With write access, an AI agent can execute a diagnostic script through NinjaOne, capture the output, and include the results in the ticket — all as part of an automated runbook that the tech approves with a single click.

What a NinjaOne MCP server actually does

An MCP server is a translation layer. It takes the MCP protocol (the standardized way AI models request data and actions from external tools) and maps it to NinjaOne’s REST API. When the AI needs device information, it makes an MCP request like “get device details for ACME-WS-042,” and the MCP server translates that into the appropriate NinjaOne API call, handles authentication, and returns the structured response.

In practical terms, a NinjaOne MCP server exposes tools like:

  • get_device_status — given a hostname or device ID, return CPU, RAM, disk, uptime, OS, last contact
  • get_device_patches — return pending and installed patches for a device
  • get_device_software — return installed software inventory
  • get_device_alerts — return active alerts for a device
  • get_org_devices — list all devices for a client organization
  • run_script — execute a script on a device and return the output
  • search_devices — find devices matching a search query across organizations

Each of these tools wraps one or more NinjaOne API calls, handles pagination, formats the response for the AI to consume, and includes error handling for common failure modes (device offline, API rate limited, invalid device ID).

How AI uses it: a real triage example

Here’s the concrete workflow when a NinjaOne MCP server is connected to your AI triage pipeline.

A ticket arrives: “John’s laptop has been freezing every afternoon for the past three days.”

The AI agent reads the ticket, identifies John as a user at Acme Corp, and resolves his assigned device to ACME-WS-042 via the PSA and NinjaOne records. Then, through the NinjaOne MCP server, it:

  1. Queries device status — gets current CPU load, RAM utilization, disk space, uptime (38 days), OS build, last contact time
  2. Checks patch status — finds 7 pending patches including 2 critical security updates and a pending reboot flag
  3. Pulls recent alerts — NinjaOne shows a recurring high memory alert triggered at 2:15 PM on each of the last three days
  4. Checks installed software — spots that a new application was installed 4 days ago, one day before the freezing started
  5. Runs a diagnostic script — executes the workstation triage script via NinjaOne’s scripting API, captures the output showing Chrome at 6.2 GB RAM (52% of total) with 47 browser tabs

All of this happens in seconds, before the tech opens the ticket. The internal note reads:

Device: ACME-WS-042 (Acme Corp) Uptime: 38 days. Pending reboot for Windows Update. 7 patches pending (2 critical). Recurring high memory alert at ~2:15 PM daily for 3 days. Chrome consuming 6.2 GB RAM (52%) with 47 tabs. New application installed 4 days ago: WidgetDesigner Pro v3.1. Suggested action: Schedule reboot to clear pending patches, investigate WidgetDesigner memory behavior, review Chrome tab usage with end user.

The tech reads that in 30 seconds and knows exactly what to do. No tab switching. No manual lookup. No 10-minute research phase.

Building a NinjaOne MCP server yourself

If you’re technically inclined and want to build your own NinjaOne MCP server, here’s what the project involves.

Authentication

NinjaOne uses OAuth 2.0 with client credentials for API access. You’ll need to create an API application in NinjaOne’s administration panel, get your client ID and secret, and implement the token refresh flow. Tokens expire, so your MCP server needs to handle refresh automatically without dropping requests.

POST https://app.ninjarmm.com/ws/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
&scope=monitoring management control

Note the /ws/ in the token URL — and that the base URL is region-specific (eu.ninjarmm.com for EU, ca.ninjarmm.com for Canada, oc.ninjarmm.com for Oceania).

NinjaOne has three API scopes: monitoring for read access, management for write actions like updating devices, and control for remote actions like running scripts and triggering reboots. Be deliberate about which scopes your MCP server requests — a read-only triage server only needs monitoring.

Rate limits

NinjaOne applies rate limits to API calls. As of this writing, the documented limits are generous for normal usage, but an AI agent that’s processing 50 tickets in parallel — each querying device status, patches, software, and alerts — can hit them. Your MCP server needs request queuing, backoff logic, and ideally a caching layer for data that doesn’t change frequently (installed software, OS version, organization membership).

Multi-tenancy: the hard part

This is where most DIY NinjaOne MCP server projects get complicated. As an MSP, you manage dozens or hundreds of organizations in NinjaOne. When the AI processes a ticket for Acme Corp, it should only see Acme Corp’s devices. When it processes a ticket for Beta Industries, it should only see Beta Industries’ devices.

NinjaOne’s API supports organization-scoped queries, but your MCP server needs to know which NinjaOne organization maps to which PSA client. That mapping has to be maintained as you onboard and offboard clients. And the AI’s queries need to be scoped correctly every time — getting this wrong means the AI might reference Device X from Client A when processing a ticket for Client B. That’s a data isolation failure.

The mapping typically works like this:

  1. Ticket comes in for “Acme Corp” from your PSA
  2. MCP server looks up Acme Corp’s NinjaOne organization ID from a mapping table
  3. All device queries are scoped to that organization ID
  4. Results are filtered and returned only for that client’s devices

Building the mapping is straightforward. Keeping it accurate over time — especially as client names don’t always match perfectly between your PSA and NinjaOne — is the ongoing maintenance burden. (This is one of the specific problems Junto’s NinjaOne integration handles automatically — tenant scoping based on ticket context, with fuzzy matching for client name discrepancies.)

Error handling and device resolution

The AI says “check John’s laptop.” Your MCP server needs to figure out which device that is. The ticket might contain a hostname, a serial number, a user’s name, or just “my computer.” Device resolution — turning a vague reference into a specific NinjaOne device ID — is a non-trivial problem that requires fallback logic:

  1. Try exact hostname match
  2. Try serial number match
  3. Try matching the user’s name to a device’s assigned user
  4. Try matching the client + device description
  5. Return multiple candidates and let the AI disambiguate

Each of these requires a different API call or search strategy. A robust NinjaOne MCP server handles all of them.

What the project looks like

Realistically, building a production-quality NinjaOne MCP server takes 40-80 hours of development work for a single tool. That includes OAuth handling, all the device/org/alert/patch endpoints, multi-tenant scoping, device resolution, caching, rate limit management, error handling, and testing across your actual NinjaOne instance.

And that’s just NinjaOne. Your AI triage pipeline also needs context from your PSA, documentation platform, identity provider, and security tools. Each one is another MCP server with its own API quirks.

When to build vs. when to buy

Building your own NinjaOne MCP server makes sense if:

  • You have a developer on staff who enjoys this kind of project
  • You only need NinjaOne integration (not the full stack)
  • You want deep customization over which endpoints are exposed
  • You’re running Claude Desktop or a similar tool where individual MCP servers plug in directly

Buying makes sense if:

  • You need NinjaOne as part of a broader AI triage pipeline across your entire stack
  • Multi-tenancy and data isolation are critical (they should be)
  • You don’t want to maintain API integrations when NinjaOne ships breaking changes
  • You want the AI layer on top — not just the data connection, but the triage logic, runbook execution, and tech workflow

How Junto handles NinjaOne integration

Junto provides a pre-built NinjaOne integration as part of its tool integrations. The connection is multi-tenant by design — every query is scoped to the correct client organization automatically based on the ticket context. Device resolution handles hostnames, serial numbers, user lookups, and fuzzy matching without configuration.

Remember the slow laptop scenario from earlier in this post? That’s not hypothetical — it’s what happens on every hardware-related ticket. The tech opens the ticket and sees: “ACME-WS-042, uptime 38 days, pending reboot, Chrome at 6.2 GB RAM, WidgetDesigner installed 4 days before symptoms started.” All pulled from NinjaOne, cross-referenced with ConnectWise ticket history and ITGlue documentation, posted as an internal note before the tech clicks in.

For NinjaOne automation specifically, Junto’s runbooks can execute scripts through NinjaOne as part of a resolution workflow. The workstation triage script is a good example — the AI triggers the script, captures the output, interprets the results, and includes actionable findings in the ticket. If the diagnostic points to a reboot-and-patch situation, the runbook proposes that action and the tech approves it in Slack.

The NinjaOne AI connection isn’t just about reading data. It’s about making that data actionable inside the ticket workflow where your techs already work. That’s the difference between a data pipe and a triage system. For more on how this works in practice, see our post on how AI supercharges NinjaOne for MSPs.

NinjaOne MCP server: the bottom line

NinjaOne holds the richest device data in your MSP stack. Patch status, installed software, alerts, system health, scripting capabilities — it’s all there, behind an API that’s well-structured and well-documented. A NinjaOne MCP server unlocks that data for AI, turning your RMM from a tool techs manually check into a data source the AI queries automatically on every ticket.

Whether you build that server yourself or use a platform that provides it, the outcome is the same: your AI gets full RMM context on every ticket, your techs stop switching tabs, and your triage time drops from minutes to seconds. The data is already in NinjaOne. The question is how you get it into the ticket.

Want to see NinjaOne device data on your next ticket — automatically? Book a 15-minute demo. We’ll connect to your NinjaOne and ConnectWise, pull a few real tickets, and show you what full RMM context looks like when the AI does the lookup instead of your tech.

See Junto in action

15-minute demo. We'll show you AI triage working on your actual tickets.

Book a Demo