PRTG MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTH_MODE | No | env (default, reads the vars above) or gateway (credentials arrive per-request via the X-PRTG-Api-Key / X-PRTG-Base-URL headers, injected by the Conduit gateway). | env |
| LOG_LEVEL | No | debug | info (default) | warn | error. | info |
| PRTG_API_KEY | No | Bearer API key issued by the PRTG web UI. | |
| MCP_TRANSPORT | No | stdio (default) or http. | stdio |
| PRTG_BASE_URL | No | Base URL of the PRTG core server, e.g. https://prtg.example.com. | |
| CONDUIT_S2S_SECRET | No | When set, the HTTP transport requires a valid X-Gateway-S2S header (Conduit sidecar auth) on every /mcp request. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| prtg_list_devicesA | List monitored devices (hostname/IP, status, parent group/probe). Each device's |
| prtg_get_deviceB | Get the metrics and settings of a single device by ID. |
| prtg_list_groupsA | List groups (the organizational folders that contain devices). Each group's |
| prtg_get_groupA | Get the metrics and settings of a single group by ID. |
| prtg_list_probesA | List probes (the monitoring agents - local, remote, or mini - that run the actual sensor checks). Each probe's |
| prtg_get_probeA | Get the metrics and settings of a single probe by ID. |
| prtg_get_probe_network_infoB | Get network information (the probe host's own connectivity details) for a probe. |
| prtg_list_sensorsA | List sensors (the individual checks - ping, HTTP, SNMP, etc. - attached to a device), with their current status. Each sensor's |
| prtg_get_sensorB | Get the metrics and settings of a single sensor by ID. |
| prtg_get_sensor_dataA | Get channel measurement history (the actual monitoring/performance data) for a sensor. |
| prtg_list_alarmsA | List sensors currently in a Down/Warning/Unusual/etc. alarm state that match a filter. PRTG's alerting surface - use this to find what's currently wrong. |
| prtg_get_sensor_status_summaryA | Get a summary of all sensor states (counts by status - Up, Down, Warning, Paused, etc.) across the whole PRTG instance. |
| prtg_get_object_sensor_summaryA | Get a sensor-state summary scoped to one probe, group, or device. |
| prtg_get_channelA | Get the metrics and settings (units, limits, current value) of a single channel on a sensor by ID. Channel IDs appear in prtg_get_sensor_data and prtg_get_sensor results. |
| prtg_get_versionA | Get the PRTG core server and appserver version. Useful as a quick credential/connectivity sanity check. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Each tool maps cleanly to a distinct PRTG object type or action: probes, groups, devices, sensors, channels, alarms, and version. The hierarchical relationships are explicit in the descriptions, so there is little risk of selecting the wrong tool.
All tools follow a consistent `prtg_` + verb + noun pattern, with `list` for collections and `get` for single objects or details. Naming style is uniform snake_case throughout, making the API surface predictable.
Fifteen tools is at the upper edge of the ideal range but each one maps to a necessary operation in the PRTG hierarchy. The count is well-scoped for a monitoring-focused server with no redundant or filler tools.
The read-only monitoring workflow is well covered: navigate probes/groups/devices, list sensors, retrieve channel data, and inspect alarms/status summaries. The main gap is the lack of operational actions like pausing sensors or acknowledging alarms, but those may be intentionally outside the server's scope.