Skip to content
Truto
Back
AI & Agents

Connect N-able N-central to ChatGPT: Manage Assets and Device Tasks

Learn how to connect N-able N-central to chatgpt using Truto. Step-by-step guide to tool calling, API quirks, and autonomous workflows.

Uday Gajavalli Uday Gajavalli · · 9 min read
Connect N-able N-central to ChatGPT: Manage Assets and Device Tasks

If you need to connect N-able N-central to ChatGPT to automate device monitoring, asset lifecycles, or scheduled tasks, you must deploy a Model Context Protocol (MCP) server. This server functions as the deterministic translation layer between ChatGPT's nondeterministic tool calls and N-central's rigid REST APIs. You can either engineer and maintain this infrastructure in-house, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses Claude, check out our guide on connecting N-able N-central to Claude or explore our broader architectural overview on connecting N-able N-central to AI Agents.

Giving a Large Language Model (LLM) read and write access to an enterprise Remote Monitoring and Management (RMM) system is an engineering challenge with zero margin for error. You have to handle JWT token lifecycles, map deeply nested asset schemas to MCP tool definitions, and deal with strict state changes. Every time an endpoint shifts or a new field is mandated, 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 N-able N-central, connect it natively to ChatGPT, and execute complex IT administration workflows using natural language.

The Engineering Reality of the N-able N-central API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, implementing it against N-able N-central's specific endpoints—or maintaining custom connectors across your ecosystem—is painful.

If you build a custom MCP server for N-central, you own the entire API execution lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with N-able N-central:

Asset Categorization and Deeply Nested Schemas When you ask an LLM to retrieve device information, you cannot rely on a flat JSON response. N-able N-central categorizes asset data into discrete, nested namespaces. A single device asset pull (list_all_n_able_n_central_device_assets) returns isolated objects for the os, application, computersystem, networkadapter, and processor, alongside a supplemental _extra object for undocumented properties. If your MCP server does not accurately serialize these nested schemas into standardized JSON Schema definitions for the LLM to read, the agent will hallucinate hardware specifications or fail to parse critical system metrics.

Scheduled Task Constraints and Execution Identity Creating a task in N-central (create_a_n_able_n_central_scheduled_task) is not a simple POST request. You must define a taskType, associate it to a specific customerId and deviceId, and provide the executing credential. If an LLM attempts to push a direct-support task without perfectly aligning the required credential map to the target device's active directory context, the task fails silently or throws an opaque 400 error. Your server logic must handle this relational validation before the request hits the RMM.

Explicit Rate Limits and 429 Handling RMM APIs are strictly rate-limited to protect core infrastructure. If an LLM enters a retry loop while scanning 5,000 devices for an active issue, N-central will aggressively reject the traffic with a 429 Too Many Requests. Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream API returns an HTTP 429, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit data into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) following the IETF spec. The LLM framework or the client executing the MCP call is entirely responsible for reading these headers and implementing exponential backoff. Do not build an integration assuming the proxy will absorb these limits for you.

Generating the N-able N-central MCP Server

Truto’s MCP feature turns any connected integration into an MCP-compatible tool server dynamically. Instead of hand-coding tool definitions for N-able N-central, Truto derives them straight from the integration's documented resources. Tools only appear if they have corresponding schema documentation, acting as a strict quality gate.

Each MCP server is scoped to a single integrated account (a connected tenant instance). The server URL contains a cryptographic token encoding the account, tool availability, and expiration logic. There are two ways to generate this URL: via the Truto UI or programmatically via the API.

Method 1: Creating via the Truto UI

For ad-hoc agent configuration and testing, you can generate the URL directly from the dashboard.

  1. Navigate to the Integrated Accounts page in your Truto environment.
  2. Select your connected N-able N-central account.
  3. Click the MCP Servers tab.
  4. Click Create MCP Server.
  5. Select your desired configuration (e.g., limit methods to read, apply specific tags for devices).
  6. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3...).

Method 2: Creating via the Truto API

For production workflows, you should dynamically provision MCP servers on behalf of your users. Make an authenticated POST request to the Truto API:

Endpoint: POST /integrated-account/:id/mcp

curl -X POST https://api.truto.one/integrated-account/ACCOUNT_ID_HERE/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "N-central Devices and Tasks Worker",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The API validates the available integration tools, securely hashes the generated token into a highly available edge key-value store, and returns the ready-to-use endpoint:

{
  "id": "mcp-789-xyz",
  "name": "N-central Devices and Tasks Worker",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6g7h8i9j0"
}

Connecting the MCP Server to ChatGPT

Once you have your Truto MCP URL, you need to expose it to your LLM environment. Because Truto handles protocol execution over HTTP using JSON-RPC 2.0, the URL is entirely self-contained.

Method A: Connecting via the ChatGPT UI (Custom Connectors)

If you are using ChatGPT Enterprise, Team, or Pro with Developer Mode enabled, you can drop the URL straight into the application:

  1. Open ChatGPT and navigate to Settings → Apps → Advanced settings.
  2. Toggle Developer mode on.
  3. Under MCP servers / Custom connectors, click Add new server.
  4. Name: Give the server a recognizable label (e.g., "N-central Production Admin").
  5. Server URL: Paste the Truto MCP URL.
  6. Save the configuration. ChatGPT will immediately perform a handshake, run the tools/list JSON-RPC method, and inject the N-central operations into its context window.

Method B: Connecting via Manual Configuration File (SSE Transport)

If you are running an agentic framework locally, testing via the Claude Desktop application, or building a custom LangChain orchestrator, you must configure the Server-Sent Events (SSE) transport. Truto's MCP endpoint expects standard HTTP POST requests, which you can proxy using the official @modelcontextprotocol/server-sse package.

Add the following definition to your MCP configuration JSON file:

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

When your agent boots, it will execute the npx command, establish an SSE connection to the Truto edge router, and expose all authorized RMM tools to the LLM.

Hero Tools for N-able N-central

Truto automatically maps N-able N-central's endpoints into descriptive, snake_case tools. Here are the highest-leverage operations for IT automation.

List All Devices

Tool: list_all_n_able_n_central_devices Returns a high-level array of all devices the logged-in RMM user can access, including deviceId, longName, deviceClass, and lastApplianceCheckinTime. This is the required first step for almost any device-centric workflow, as LLMs need the exact deviceId to execute subsequent actions.

"Fetch a list of all devices in our N-central environment. Identify any devices where the deviceClass indicates a server and the lastApplianceCheckinTime is older than 24 hours. Give me their deviceIds and longNames."

Get Detailed Device Asset Information

Tool: list_all_n_able_n_central_device_assets Retrieves the complete, deep asset schema for a specific device_id. This includes exact processor models, installed applications, OS versions, and network adapters. It is essential for compliance auditing and vulnerability mapping.

"Using device_id '748392', pull the complete asset information. Extract the OS version and build number, and list all network adapters currently connected to the machine."

Get Service Monitor Status

Tool: n_able_n_central_devices_service_monitor_status Checks the execution state of specific service monitoring tasks assigned to a device_id. Returns granular metrics like stateStatus, lastScanTime, and the specific moduleName that triggered a warning.

"Check the service monitor status for device_id '10045'. Are there any failed thresholds or stateStatus values indicating critical failures on the disk utilization or memory modules?"

List Active Issues

Tool: list_all_n_able_n_central_active_issues Queries N-central for active issue tickets assigned to a specific org_unit_id. Returns the associated deviceId, the offending serviceName, and raw alert data in the _extra object.

"Pull the active issues for org_unit_id '5501'. Summarize the services currently throwing alerts, cross-reference them with the associated device IDs, and categorize them by serviceType."

Get Device Asset Lifecycle

Tool: list_all_n_able_n_central_device_asset_life_cycle Fetches critical procurement and depreciation data for a specific device. Returns warrantyExpiryDate, purchaseDate, cost, and the physical location or assetTag.

"Get the asset lifecycle data for device_id '3321'. Tell me when the warrantyExpiryDate is, and calculate how many months remain before the expectedReplacementDate."

Update Device Asset Lifecycle

Tool: update_a_n_able_n_central_device_asset_life_cycle_by_id Modifies asset lifecycle fields. Because the API enforces strict validation, the LLM must submit properly formatted ISO dates for expiration fields while explicitly ignoring read-only fields like updateWarrantyError.

"Update the asset lifecycle for device_id '3321'. Set the leaseExpiryDate to '2026-12-31' and append 'Approved for remote work' to the description field."

Create Scheduled Direct-Support Task

Tool: create_a_n_able_n_central_scheduled_task Deploys an immediate direct-support task against a device. Requires exact structural alignment, including the credential, taskType, and target deviceId.

"Create a direct-support scheduled task for device_id '9984' under customerId '102'. The taskType is a service restart. Use the default administrative credential mapped to the org unit, and return the taskId to confirm execution."

To view the complete schema definitions and remaining operations, visit the N-able N-central integration page.

Workflows in Action

When you connect N-able N-central to ChatGPT via Truto, you unlock autonomous workflows that previously required a human technician to click through dozens of RMM menus. Here are two concrete examples of multi-step tool orchestration.

Scenario 1: Automated Device Health and Active Issue Triage

An IT administrator needs to triage an alert flood for a specific customer organization without manually investigating every system.

"Review the active issues for org_unit_id '409'. Find any devices that have failing services. For each failing device, retrieve its exact OS asset information and check its specific service monitor status to give me a consolidated root cause report."

Execution Steps:

  1. list_all_n_able_n_central_active_issues: The agent queries the org unit and retrieves an array of alerts, extracting deviceId: '7721' and serviceName: 'Disk Space'.
  2. list_all_n_able_n_central_device_assets: The agent targets the specific device to pull its hardware profile, discovering it is running Windows Server 2019.
  3. n_able_n_central_devices_service_monitor_status: The agent checks the granular monitor metrics, confirming that the C: drive threshold has been breached by 98%.

Result: The administrator receives a concise Slack or ChatGPT message stating exactly which server is failing, what its OS is, and the precise metric threshold that triggered the event, completely bypassing the RMM dashboard.

Scenario 2: Asset Lifecycle and Warranty Audit

A procurement manager wants to forecast hardware replacements for the upcoming fiscal quarter by auditing the current deployment fleet.

"Pull all devices in the system. Filter for physical workstations. For those devices, pull their asset lifecycle data. If the warrantyExpiryDate is in the past, update their description to include the tag ' [WARRANTY EXPIRED - SCHEDULE REPLACEMENT]'."

Execution Steps:

  1. list_all_n_able_n_central_devices: The agent retrieves the global device list and filters the array based on deviceClass.
  2. list_all_n_able_n_central_device_asset_life_cycle: The agent iterates over the filtered deviceIds, retrieving the procurement records.
  3. update_a_n_able_n_central_device_asset_life_cycle_by_id: For any device where the date calculation shows an expired warranty, the agent formulates a precise JSON body and patches the record via Truto.

Result: The LLM audits the entire fleet and updates the RMM database dynamically, providing the procurement manager with a final text summary of how many machines were tagged for replacement.

Security and Access Control

Giving an AI agent access to an infrastructure management platform is inherently high-risk. Truto enforces security at the MCP token level, ensuring the model cannot overstep its boundaries:

  • Method Filtering: Enforce strict architectural limits during server creation by passing config.methods: ["read"]. The proxy drops any tool definition matching create, update, or delete, rendering the LLM strictly read-only.
  • Tag Filtering: Restrict tool sets functionally using config.tags: ["devices", "tasks"]. The agent will be blinded to unrelated modules like customer sites or access group configurations.
  • Mandatory API Auth: By setting require_api_token_auth: true, the URL itself is no longer sufficient. The MCP client must provide a valid Truto API token in the Authorization header to execute a tool, guaranteeing that leaked URLs cannot be abused.
  • Time-to-Live (TTL): Set an expires_at ISO datetime when creating the MCP server. Truto's edge compute will automatically invalidate the cryptographic token and wipe the reverse lookup records when the alarm fires, making the endpoint dead for temporary vendor audits or specific diagnostic sessions.

Ship Your IT Automation Pipelines

Connecting N-able N-central to ChatGPT transforms an RMM platform from a passive monitoring tool into an active, conversational automation engine. You no longer have to waste engineering hours mapping nested custom property objects, maintaining pagination cursors, or writing error handlers for upstream XML/JSON quirks.

Truto’s managed MCP infrastructure translates the friction of third-party API connectivity into a single, standardized JSON-RPC interface. You declare your security filters, provision the URL, and let the LLM do the heavy lifting.

More from our Blog