PRTG

PRTG MCP Server

MCP server for Paessler PRTG's REST API v2 - device/sensor status, monitoring data (channel measurement history), and alerts (sensors in an alarm state) across a PRTG network/infrastructure monitoring instance - for AI assistants and the WYRE Conduit gateway.

Authentication

PRTG authenticates with a static Bearer API key, generated in the PRTG web UI under Account Settings -> My Account -> API Keys. No admin approval is required to generate one - any PRTG user can create a key for themselves. Unlike most connectors in this fleet, PRTG has no fixed hosted API endpoint: this connector supports self-hosted PRTG Network Monitor at its own base URL (PRTG Hosted Monitor does not provide API v2 yet; see below), so it requires both an API key and a base URL. The key is sent as Authorization: Bearer <key> to <base URL>/api/v2/.... In gateway mode both arrive per-request via the X-PRTG-Api-Key and X-PRTG-Base-URL headers; in local/stdio mode they're read once from PRTG_API_KEY and PRTG_BASE_URL.

Credential scope

Vendor-documented, not independently verified against a live account (see Verification below for why): per Paessler's own PRTG API v2 documentation, an API key inherits the full permissions of the PRTG user account that created it - keys cannot be independently scoped to read-only. Paessler's own guidance for AI-assistant integrations is explicit: "grant [API keys used in AI assistants] the lowest user role that fits the assistant's task," and recommends creating a dedicated read-only PRTG user account first, then generating the API key under that account, rather than relying on the key itself to restrict access. This connector cannot enforce that on PRTG's side - it only implements the read-only tool surface described below - so the actual read-only guarantee depends on the customer following Paessler's own recommendation when they generate the key.

Base URL (on-premises)

On PRTG Network Monitor (on-premises), API v2 is served only by the PRTG Application Server, not by the classic web interface. Use the Application Server's HTTPS URL, by default port 1616 - e.g. https://prtg.example.com:1616. The Application Server also listens for plain HTTP on port 1615, but every request carries the bearer API key, so use http://...:1615 only on a trusted network. The classic web interface URL (port 80/443) does not serve /api/v2 and typically returns 404, a redirect, or the HTML login page, which looks like an authentication failure.

The Application Server exists only after New UI and API v2 has been activated: in the classic UI go to Setup | Overview and select Activate (ports 1616/1615 and 23580 must be free; the core server restarts). Per Paessler, it is activated by default for new PRTG users as of PRTG 25.2.106. Existing installs, upgrades, and any install where Setup | Overview still shows Activate New UI And API v2 must activate it manually. Paessler also states that API v2 is not yet available on PRTG Hosted Monitor or on PRTG installs running in cluster mode. See Paessler's I want to use the new UI and API v2. What do I need to know? and the New User Interface manual page.

Verification

This connector was built directly against PRTG's official, current OpenAPI v2 specification (prtg.api.yaml, published at paessler.com/support/prtg/api/v2/oas/), not against secondary documentation or a naming convention - every tool below maps to one real, named operation in that spec, with its exact query parameters. What it is not is independently verified against a live PRTG instance: PRTG's free tiers are (a) a 30-day trial of PRTG Network Monitor, which is Windows-only on-premises software, and (b) a 10-day trial of PRTG Hosted Monitor (app.my-prtg.com/signup), a cloud SaaS signup whose verification flow could not be completed in this build environment (no Windows host to install PRTG Network Monitor on; no email inbox available to complete PRTG Hosted Monitor's signup confirmation). Both are genuinely self-serve for a human with a Windows machine or an email inbox to check - this is an environment limitation of the build, not a vendor-side approval gate.

Configuration

Tools

Devices

• prtg_list_devices - list monitored devices (hostname/IP, status, parent group/probe).
• prtg_get_device - get the metrics and settings of a single device.

Groups

• prtg_list_groups - list groups (the organizational folders that contain devices).
• prtg_get_group - get the metrics and settings of a single group.

Probes

• prtg_list_probes - list probes (the monitoring agents - local, remote, or mini - that run the actual sensor checks).
• prtg_get_probe - get the metrics and settings of a single probe.
• prtg_get_probe_network_info - get network information for a probe.

Sensors

• prtg_list_sensors - list sensors (the individual checks - ping, HTTP, SNMP, etc. - attached to a device), with their current status.
• prtg_get_sensor - get the metrics and settings of a single sensor.
• prtg_get_sensor_data - get channel measurement history (the actual monitoring/performance data) for a sensor.
• prtg_list_alarms - list sensors currently in a Down/Warning/Unusual/etc. alarm state. PRTG's alerting surface.

Sensor status summary

• prtg_get_sensor_status_summary - get a summary of all sensor states across the whole instance.
• prtg_get_object_sensor_summary - get a sensor-state summary scoped to one probe, group, or device.

Channels

• prtg_get_channel - get the metrics and settings (units, limits, current value) of a single channel on a sensor.

System

• prtg_get_version - get the PRTG core/appserver version. Useful as a credential/connectivity sanity check.

Scope

This is a deliberately narrow, read-only v1 surface covering exactly device/sensor status, monitoring data, and alerts - nothing else. PRTG API v2 documents a large surface (object CRUD, autodiscovery, user/API-key administration, AI-assistant endpoints, an entire /experimental namespace); this connector implements 15 GET operations from it (10 stable, non-experimental, and 5 documented-but-deprecated - see below), verified one-by-one against the official OpenAPI spec, and excludes every write/pause/resume/scan/acknowledge/discovery/administration operation, plus every genuinely /experimental/* endpoint, by design, not by oversight.

A few of the 15 implemented endpoints (GET /devices, /groups, /probes, /sensors, /sensors/alarms) are marked deprecated in PRTG's own v2 spec, in favor of an /experimental/* replacement. This connector deliberately uses the documented, currently-working deprecated endpoint rather than its /experimental replacement: PRTG's own spec states experimental endpoints "might change," while a deprecated endpoint "still works" and is the only non-experimental way to list PRTG's core object types at all. A stable-but-deprecated endpoint was judged the safer choice for a production connector over an unstable-but-current one; every /experimental/* endpoint (list or otherwise) is excluded outright below.

Hard-excluded (mutation - pause/resume/scan) - never implemented: POST /devices/{id}/pause, /devices/{id}/resume, /devices/{id}/scan, /devices/pause, /devices/resume, /devices/scan, /groups/{id}/pause, /groups/{id}/resume, /groups/{id}/scan, /groups/pause, /groups/resume, /groups/scan, /probes/{id}/pause, /probes/{id}/resume, /probes/{id}/scan, /probes/pause, /probes/resume, /probes/scan, /sensors/{id}/pause, /sensors/{id}/resume, /sensors/{id}/scan, /sensors/pause, /sensors/resume, /sensors/scan, /users/{id}/pause, /users/{id}/resume, /users/pause, /users/resume.

Hard-excluded (acknowledge-alert) - never implemented: POST /sensors/{id}/acknowledge, /sensors/acknowledge - acknowledging an alarm is a write action on PRTG's alerting state, excluded per this connector's hard scope boundary even though it reads like a status query.

Hard-excluded (object mutation) - never implemented: POST /objects/{id}/move, /objects/{id}/clone, and the entire /experimental namespace's create/update/delete operations (PATCH /experimental/groups/{id}, /experimental/probes/{id}, /experimental/sensors/{id}; POST /experimental/groups/{id}/group, /experimental/probes/{id}/group, /experimental/groups/{id}/device, /experimental/probes/{id}/device, /experimental/devices/{id}/sensor; DELETE /experimental/devices/{id}) and its experimental read-only list mirrors (GET /experimental/devices, /experimental/groups, /experimental/probes, /experimental/sensors, /experimental/channels, /experimental/objects, /experimental/devices/templates) - excluded as a whole namespace PRTG's own docs describe as subject to change, not individually vetted as safe.

Hard-excluded (autodiscovery) - never implemented: GET /autodiscoveries, /experimental/autodiscoverytasks, /experimental/autodiscoverytasks/{id}; POST /experimental/devices/{id}/autodiscovery, /experimental/groups/{id}/autodiscovery, /experimental/devices/{id}/metascan, /experimental/probes/{id}/autodiscoverytask, /experimental/autodiscoverytasks/{id}/start - autodiscovery inventories and triggers network scans; out of this connector's device/sensor/monitoring/alert scope.

Hard-excluded (user/API-key/session/license administration - identity and credential management, not device/sensor/alert data) - never implemented: GET/POST/PATCH /users*, /experimental/users*, /usergroups*, /experimental/usergroups*, /users/api-keys/find, /users/{id}/api-keys, DELETE /users/api-keys/{id}, POST/GET/DELETE /session (login/renew/logout), POST /users/request-password, /users/reset-password, GET /experimental/license.

Hard-excluded (object schema/generic-CRUD/settings/AI-feature/misc administration) - out of scope, never implemented: GET/POST/PATCH /schemas/{kind}, /experimental/schemas/*, GET /experimental/objects, /objects, /objects/count, /libraries, /lookup-definitions*, /setting-lookups/{name}, /settings/public, /health (unauthenticated liveness only - prtg_get_version is this connector's authenticated sanity check instead), /devices/icons, /experimental/feature-toggles, /experimental/featureflags, /experimental/ai/analyze, /experimental/ai/status, /experimental/timeseries/{id}, /experimental/timeseries/{id}/{type}, /channels (list) and /channels/data (both deprecated in favor of the implemented GET /channels/{id}, itself not deprecated), /channels/{id}/overview, /devices/{id}/overview, /groups/{id}/overview, /probes/{id}/overview, /sensors/{id}/overview (all deprecated in favor of the implemented non-overview GET .../{id} equivalents).

They can be added as a follow-up if there's demand, after a deliberate scope decision - not by default.

Development

npm install
npm run build
npm test
npm run lint   # tsc --noEmit

Docker

docker build -t prtg-mcp .
docker run -p 8080:8080 -e PRTG_API_KEY=... -e PRTG_BASE_URL=https://prtg.example.com:1616 prtg-mcp