Loading ToolBench
MCP Server for PRTG Network Monitor - stdio plugin for Claude Desktop, Cursor, and other MCP clients. Provides tools to query PRTG monitoring data via database queries and PRTG API.
This PRTG MCP server demonstrates solid engineering with well-structured tool definitions. All 15 tools have complete input schemas with typed parameters and descriptions. Tool naming follows verb_noun conventions consistently (prtg_get_*, prtg_query_*). Descriptions are generally thorough and explain use cases. However, there are notable gaps: (1) output schemas are not documented, we cannot verify what fields agents should expect from responses; (2) error handling guidance is absent, no recovery hints or error categorization; (3) some parameter descriptions lack format/constraint details; (4) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear READ_ONLY classifications visible in metadata. The server is production-capable but falls short of A-grade polish. Average per-tool score: 72.
Get a complete overview of a device including all its sensors and statistics (up/down/warning counts).
Retrieve sensors in alert state (not Up). Returns sensors with warnings, errors, or down status.
Get PRTG Business Process Monitors - high-level objects that aggregate multiple sensors to represent business-critical services or workflows.
**PRIMARY TOOL for checking sensor current state and discovering available channels.** Returns ALL channels of a sensor with their current values, names, units, and last update time. Each PRTG sensor has multiple channels (measurements). Examples: SSL sensors → 'Days to Expiration', 'Response Time'; Server sensors → 'CPU Load', 'Memory Usage', 'Disk Space'; Network sensors → 'Traffic In', 'Traffic Out', 'Packet Loss'. **ALWAYS use this tool first** when asked about a sensor's current state, values, or status. Use prtg_get_sensor_timeseries only for historical trends.
List PRTG groups/probes with optional filtering. Groups organize devices in a hierarchical structure. Returns group information including paths and probe status.
Output schemas not documented. Tool descriptions explain what the tool does but never specify what fields will be returned. LLMs cannot plan downstream tool calls or extract required data (e.g. sensor_id for use in prtg_get_channel_current_values) without knowing response structure.
No error handling guidance. Tools do not document how failures should be handled, what errors are retryable, or what the LLM should do next. For example, prtg_query_sql may fail due to SQL syntax, permission denial, or network timeout, agents have no recovery path.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Navigate the PRTG hierarchy tree structure. Returns groups, devices, and optionally sensors in a tree format. Useful for understanding the organization and structure of your PRTG installation.
Retrieve **HISTORICAL** data for a specific date/time range. **For CURRENT values, use prtg_get_channel_current_values instead.** Use this when you need to analyze a specific incident timeframe (e.g., 'what happened last Tuesday between 2pm-4pm'). Useful for: incident investigation, comparing specific time windows, generating reports for past periods.
Get detailed current status of a specific sensor by ID. Returns current values, uptime, downtime, and status information.
Retrieve **HISTORICAL** time series data for analyzing trends over time. Returns time-stamped measurements showing how channel values evolved. **For CURRENT values, use prtg_get_channel_current_values instead.** Use cases: analyze performance degradation over 24h, identify when an issue started, compare metrics between time periods, detect patterns in historical data.
Retrieve PRTG sensors with optional filters (device, sensor name, type, group, status, tags). Returns current sensor status and metadata. Supports ordering by various fields.
Get aggregated statistics from PRTG: total sensors, groups, devices, and their status distribution (up/down/warning). Useful for system health overview and dashboards.
List all PRTG tags used to organize and categorize objects. Tags are labels assigned to sensors, devices, and groups for flexible organization.
Execute custom SQL queries against the PRTG database (if enabled by administrator). Returns raw database results. Requires admin configuration to enable. Use with caution.
Universal search across groups, devices, and sensors. Searches by name, host, or sensor type. Returns all matching results organized by type.
Get top sensors ranked by various metrics (uptime, downtime, or alerts).
Tool annotations missing. All tools are READ_ONLY (no side effects) but input schemas lack readOnlyHint annotation. This prevents MCP clients from optimizing caching, parallelization, or user warnings.
Parameter constraints under-specified. Several parameters lack format or range details. Example: prtg_get_sensors 'limit' defaults to 50 but no min/max is stated. prtg_get_sensor_timeseries 'time_type' enum is clear, but prtg_query_sql 'limit' has no upper bound documented, risking memory exhaustion.
prtg_query_sql description lacks security context. Tool allows 'SELECT queries only, for security' but does not mention that SQL injection must be mitigated server-side, and does not warn about information disclosure risks if the PRTG database contains credentials or sensitive config.
Pagination guidance missing. Tools returning lists (prtg_get_sensors, prtg_search, prtg_get_hierarchy, prtg_get_groups, prtg_get_tags, prtg_get_business_processes) accept 'limit' but do not document cursor/offset support or how to fetch the next page. LLMs cannot systematically iterate large result sets.
prtg_get_statistics parameter schema is empty object, unusual for a monitoring tool. Likely this tool needs documentation on what metrics it returns and any optional filters.