Connect Ninjaone to Claude: Track Software, Patches, and Device Logs

If you need to connect Ninjaone to Claude to automate device inventory management, track software patches, or triage system alerts, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's LLM tool calls and Ninjaone's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting Ninjaone to ChatGPT or explore our broader architectural overview on connecting Ninjaone to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling Remote Monitoring and Management (RMM) ecosystem like Ninjaone is a severe engineering challenge. You have to handle API authentication lifecycles, map massive nested JSON schemas to MCP tool definitions, and deal with strict IT-centric rate limits. Every time an endpoint changes or a new device class is added, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Ninjaone, connect it natively to Claude Desktop, and execute complex IT administration workflows using natural language.

The Engineering Reality of the Ninjaone API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover and execute tools, the reality of implementing it against a deeply complex vendor API like Ninjaone is painful. You are not just integrating a simple SaaS app - you are interfacing with a multi-tenant RMM platform that tracks hundreds of data points per endpoint device, orchestrates software deployments, and logs thousands of system activities.

If you decide to build a custom MCP server for Ninjaone, you own the entire integration lifecycle. Here are the specific challenges you will face:

Highly Nested and Segmented Object Models Ninjaone organizes data hierarchically: Organizations contain Locations, which contain Devices, which are governed by Policies and Node Roles. When an LLM wants to perform a seemingly simple task like "find the offline server in the London office," it has to navigate a highly fragmented data model. The base device record contains references (organizationId, locationId, nodeClass), but resolving those requires subsequent API calls. Writing the logic to flatten these relationships into consumable schemas for an LLM context window is tedious and prone to token exhaustion.

Complex Patching and Software Inventories Software inventory and patch history in Ninjaone are not simple arrays attached to a device object. They are entirely separate sub-resources (/device/{id}/software, /device/{id}/os-patch-installs). A naive MCP implementation will dump the entire payload of these endpoints into the LLM context, which quickly exceeds context limits and dilutes the model's attention. You have to build intelligent cursor handling and schema curation so the model only sees actionable fields like productIdentifier, impact, and installedAt.

Strict Rate Limits and Error Handling Ninjaone enforces strict API quotas to protect their multi-tenant RMM environment. If your AI agent gets stuck in a loop trying to iterate through thousands of device activity logs, Ninjaone will return a 429 Too Many Requests error.

It is critical to understand how this is handled in a managed environment: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Ninjaone API returns an HTTP 429, Truto passes that error directly back to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) following the IETF specification. The caller (your agent framework or MCP client) is strictly responsible for implementing its own retry and exponential backoff logic using these standardized headers.

Instead of building this infrastructure from scratch, you can use Truto. Truto normalizes authentication, pagination, and schema definitions, exposing Ninjaone's endpoints as ready-to-use, dynamically generated MCP tools.

How to Generate a Ninjaone MCP Server with Truto

Truto dynamically generates MCP tools based on an integration's underlying REST resources and documentation. Tools are not pre-compiled; they are generated on the fly. A tool only appears in the MCP server if it has a corresponding documentation entry mapping its query and body schemas. This acts as a strict quality gate, ensuring your LLM only sees well-defined endpoints.

Each MCP server is scoped to a single integrated account (a specific authenticated instance of Ninjaone). The server URL contains a cryptographically hashed token that encodes which account to use and what operations are permitted.

You can create this server in two ways.

Method 1: Via the Truto UI

For ad-hoc agent testing or internal operations, generating a server through the dashboard is the fastest path.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Ninjaone account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure the server parameters. You can name the server (e.g., "Ninjaone IT Ops Agent"), set an expiration date if you want temporary access, and apply method filters (e.g., allowing only read operations to prevent accidental device reboots or updates).
5. Click Save and copy the generated MCP server URL. You will not be able to see the full URL again.

Method 2: Via the REST API

For production workflows, you should generate MCP servers programmatically. This allows you to provision scoped access for specific automation runs or tenant environments.

Make a POST request to /integrated-account/:id/mcp with your desired configuration.

const response = await fetch('https://api.truto.one/integrated-account/<ninjaone_account_id>/mcp', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${TRUTO_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: "Ninjaone Patch Auditor",
    config: {
      methods: ["read"], // Restrict the LLM to get/list operations
      tags: ["devices", "software"] // Only expose device and software endpoints
    },
    expires_at: "2026-12-31T23:59:59Z" // Automatically revoke access
  })
});
 
const data = await response.json();
console.log(data.url); // https://api.truto.one/mcp/a1b2c3d4e5f6...

The API securely provisions the token in a distributed key-value store and schedules a distributed alarm to automatically purge the database record and cache entries when the expires_at timestamp is reached. The returned URL is fully self-contained.

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, you need to connect it to your LLM interface. The protocol handles the handshake (versioning, capability exchange) automatically via JSON-RPC 2.0 over HTTP POST.

Method A: Via the Claude UI

If you are using Claude Desktop or an enterprise workspace, adding the toolset is straightforward.

1. Open your Claude Desktop or Workspace settings.
2. Navigate to Integrations or Connectors.
3. Select Add MCP Server or Add Custom Connector.
4. Paste the Truto MCP URL you generated.
5. Click Add.

Claude will immediately call the tools/list endpoint, parse the dynamically generated JSON schemas, and register the Ninjaone endpoints as callable functions.

Method B: Via Manual Config File

If you are using the Claude Desktop app locally for development, you can configure the MCP server directly in the claude_desktop_config.json file. Because Truto MCP URLs are self-contained HTTP endpoints, you map them using the Server-Sent Events (SSE) transport adapter.

Open your configuration file (typically located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows) and add the server:

{
  "mcpServers": {
    "ninjaone_ops": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_SECURE_TOKEN_HERE"
      ]
    }
  }
}

Restart Claude Desktop. The initialization routine will fetch the available tools directly from your Ninjaone instance.

Ninjaone MCP Hero Tools

Truto provides a comprehensive mapping of the Ninjaone API. When Claude queries the MCP server, it receives the exact query parameters, body requirements, and descriptions necessary to execute operations flawlessly. Here are six high-leverage hero tools your agents can use immediately.

list_all_ninjaone_search_devices

This tool allows the LLM to search for endpoints across your entire fleet using a specific query term. It bypasses the need to iterate through location-specific device lists, returning the ID, display name, and status of matching hardware.

"Find any devices in the fleet with 'WIN-SRV' in their hostname and check if they are currently offline."

get_single_ninjaone_device_by_id

Once an agent has a specific device ID, this tool retrieves the deep technical profile of the endpoint. This includes the public and private IPs, MAC addresses, warranty status, maintenance windows, and applied policies.

"Get the full system details for device ID 4892. I need to know its primary IP address, what node class it belongs to, and if it is currently under a maintenance window."

list_all_ninjaone_device_software_patch_history

This tool pulls the historical log of OS patches and software updates applied to a specific device. It exposes the product identifier, title, impact rating, and the precise installation timestamp, which is critical for compliance auditing.

"Retrieve the software patch history for device ID 4892 over the last 30 days. Did the recent critical Windows security rollup install successfully?"

list_all_ninjaone_alerts

This operation returns all active system alerts across the organization. It provides the alert message, creation time, source type, and the underlying device context. Agents can use this to triage failing systems before users report them.

"List all currently active alerts with a severity of 'Critical' or 'High'. Group them by device and summarize the core issue for each."

list_all_ninjaone_tickets

If you use Ninjaone's built-in ticketing or a synchronized PSA board, this tool fetches the active service desk queues. It requires a board_id and returns ticket statuses, severity, assignees, and CC lists.

"Pull the active tickets from board ID 12. Show me all tickets marked as 'New' or 'Open' that are related to network connectivity issues."

update_a_ninjaone_device_by_id

Agents can execute configuration changes using this tool. It allows updates to the device's display name, organizational mapping, policy assignment, or custom user data fields.

"Update the display name of device 4892 to 'LON-DC-01-DECOMMISSIONED' and move it to the 'Archive' policy ID 88."

For the complete, real-time inventory of supported endpoints, schemas, and return models, visit the Ninjaone integration page.

Workflows in Action

Connecting Ninjaone to Claude transforms manual IT administration into conversational automation. By chaining multiple tools together, Claude can execute multi-step diagnostic and remediation workflows.

Workflow 1: Vulnerability and Patch Auditing

IT administrators frequently need to verify if specific CVEs or required security patches have been applied across high-value endpoints.

"Check if our primary database server (hostname 'DB-PROD-01') has received the latest security patches. If it hasn't been patched in the last 14 days, let me know what software it is currently running."

Tool execution sequence:

1. list_all_ninjaone_search_devices: Claude searches for the query DB-PROD-01 to resolve the human-readable hostname into a Ninjaone internal id.
2. list_all_ninjaone_device_software_patch_history: Claude queries the patch history using the retrieved device ID, analyzing the installedAt timestamps to verify compliance.
3. list_all_ninjaone_device_software: If the patch history is stale, Claude queries the current software inventory to snapshot the vulnerable state of the machine.

Result: The user receives a concise audit report confirming the server's identity, a flag indicating the patch deficiency, and a summarized list of installed software that may be exposing the endpoint to risk.

Workflow 2: Automated Alert Triage and Ticketing

When a monitoring system triggers a flood of alerts, filtering the noise from critical failures takes significant manual effort.

"Review all active Ninjaone alerts. Find any servers that are currently offline. For those servers, check their recent activity logs to see if a reboot was initiated, and format a summary of the incident."

Tool execution sequence:

1. list_all_ninjaone_alerts: Claude fetches the active alert queue, filtering the JSON response in-memory for entries matching "offline" or "unreachable" status flags.
2. get_single_ninjaone_device_by_id: For each offline device identified in the alert payload, Claude retrieves the detailed device schema to verify its nodeClass (ensuring it is a server, not a workstation) and its maintenance status.
3. list_all_ninjaone_device_activity_logs: Claude queries the specific activity history for the offline server, looking for activityType logs related to shutdowns, reboots, or administrative actions immediately preceding the outage.

Result: The user receives an incident summary that bypasses the noise. Instead of a raw list of offline alerts, Claude provides the context: "Server LON-DB-02 is offline and generated a critical alert 10 minutes ago. However, reviewing the activity logs shows that User JSmith initiated a remote reboot 12 minutes ago. No immediate panic required - server is likely in a restart cycle."

Security and Access Control

Exposing IT infrastructure data to an AI model requires strict governance. Truto provides several mechanisms to lock down your Ninjaone MCP servers:

• Method Filtering: You can restrict a server to specific operation categories. Setting methods: ["read"] ensures the LLM can never invoke update_a_ninjaone_device_by_id or other destructive actions, enforcing a strict read-only audit persona.
• Tag Filtering: You can restrict access to specific API domains. Passing tags: ["software"] ensures the MCP server only exposes patch and software inventory endpoints, preventing the model from reading user directories or ticketing data.
• Require API Token Auth: By default, possessing the MCP URL grants access. Enabling require_api_token_auth enforces a secondary authentication layer, requiring the client to also pass a valid Truto API token in the Authorization header. This prevents unauthorized execution if the URL is leaked in logs.
• Automated Expiration: Setting an expires_at timestamp ensures the MCP server is ephemeral. Once the datetime is reached, distributed systems automatically purge the token from all caches and databases, making the URL permanently invalid.

Architecting for Scale

Connecting Claude to Ninjaone using a custom-built integration layer is a massive undertaking that distracts your engineering team from core product work. You have to maintain parity with a massive RMM data model, handle relentless cursor pagination logic, and build custom fallback mechanisms for rate limits.

Using Truto's dynamically generated MCP servers, you eliminate the integration boilerplate. You map your Ninjaone account once, generate a filtered, secure URL, and instantly give your AI agents the tools they need to track patches, triage alerts, and manage device fleets.