prtg-mcp

MCP-Server für PRTG Network Monitor (Paessler Netzwerk-/Infrastruktur-Monitoring). Stellt die nativen HTTP-API-Sensoren, -Geräte und historischen Sensordaten von PRTG als MCP-Tools bereit.

Übersicht

• Zustandsloser HTTP-Dienst. Es werden niemals Anmeldedaten gespeichert – jede Anfrage liefert ihre eigenen Anmeldedaten über Header, die nur für die Lebensdauer dieser einzelnen Anfrage verwendet werden.

• Unterstützt gleichzeitige Anfragen; die Isolierung der Anmeldedaten pro Anfrage erfolgt über Python-contextvars, nicht über eine globale/geteilte Client-Instanz.

• Einstiegspunkte: POST /mcp (MCP-Protokoll) und GET /health (Healthcheck).

• Standard-Port: 8080 (konfigurierbar über MCP_HTTP_PORT).

Related MCP server: mcp-ntopng

Authentifizierung

Im Gegensatz zu den meisten Integrationen in diesem Programm hat PRTG keinen separaten Login oder Tokenaustausch: Der Benutzername und ein „Passhash" (in der PRTG-Oberfläche unter My Account -> API Key generiert, nicht das wörtliche Kontopasswort) werden bei jedem einzelnen Aufruf als einfache Abfrageparameter gesendet. Es gibt daher nichts zu cachen – jeder Aufruf ist bereits vollständig in sich geschlossen und zustandslos, ganz im Sinne des Herstellers.

HEADER-Autorisierungsparameter

Fehlt ein Header, wird 401 zurückgegeben:

{
  "error": "Missing credentials",
  "message": "This server requires the X-PRTG-Server-Url, X-PRTG-Username, and X-PRTG-Passhash headers",
  "required_headers": ["X-PRTG-Server-Url", "X-PRTG-Username", "X-PRTG-Passhash"],
  "optional_headers": []
}

Eine ungültige Anmeldeinformation erscheint als Tool-Ebene-Fehlerumschlag (siehe Fehlerumschlag unten), der anhand des HTTP-Statuscodes von PRTG klassifiziert wird – ein 401/403 wird auf unauthorized abgebildet. Bei jeder Nicht-2xx-Antwort versucht dieser Server, ein Feld message/error aus dem JSON-Textkörper zu extrahieren, und fällt auf den rohen Antworttext zurück, wenn dieser Textkörper kein JSON ist (PRTG kann bei bestimmten fehlerhaften Anfragen selbst auf dem .json-Endpunkt auf einen XML-<error>-Textkörper zurückfallen).

Umgebungsvariablen

MCP-Endpunkt

• POST /mcp — MCP-Protokoll (streambarer HTTP-Transport)

• GET /health — Healthcheck, gibt {"status": "ok"} zurück (reine lokale Prüfung, ruft PRTG nicht auf)

Werkzeugliste

Alle 3 Werkzeuge sind schreibgeschützt (readOnlyHint=True, idempotentHint=True); es gibt keine Schreib-/Löschwerkzeuge in diesem Dienst.

count hat kein dokumentiertes serverseitiges hartes Maximum für den table.json-Endpunkt von PRTG, daher wendet dieser Server die eigene Fallback-Obergrenze der Plattform an, anstatt Werte ungeprüft durchzureichen: Standard 50, Werte über 200 werden stillschweigend auf 200 begrenzt und nicht unverändert an PRTG gesendet.

Antwortformat

Beide von diesem Server aufgerufenen Endpunkte (table.json, historicdata.json) sind die JSON-Suffix-Varianten des Herstellers, sodass der Client bei Erfolg nur JSON parst. Die HTTP-API von PRTG kann grundsätzlich für andere Endpunkte/Parameter XML zurückgeben, daher parst der Client defensiv: Eine Nicht-2xx-Antwort wird in den unten beschriebenen strukturierten Fehlerumschlag eingeordnet, und wenn eine 2xx-Antwort jemals nicht als JSON geparst werden kann, wird ihr roher Text unter einem Schlüssel raw_response zurückgegeben, anstatt eine Ausnahme auszulösen.

Fehlerumschlag

Tool-Fehler werden als strukturierter JSON-String zurückgegeben, nicht als ausgelöste Ausnahme, damit der aufrufende Agent auf code verzweigen und entscheiden kann, ob ein erneuter Versuch sinnvoll ist:

{"error": {"code": "upstream_error", "message": "...", "retryable": true}}

code ist einer von: not_configured, unauthorized, not_found, invalid_argument, rate_limited, upstream_error. Leere Ergebnismengen werden als normale (nicht fehlerhafte) leere Sammlung zurückgegeben, nicht als not_found.

Tool-Rückgabewerte (Erfolg und Fehler gleichermaßen) sind kompaktes JSON (ensure_ascii=False, kein indent) mit einer Obergrenze von 20.000 Zeichen – ein übermäßig großes Ergebnis kürzt sein größtes Listenfeld und meldet truncated/original_count, anstatt ein unbegrenztes Blob zurückzugeben.

Testbeispiel

# Health check
curl -s http://localhost:8080/health

# Call a tool via the MCP protocol (streamable HTTP) — requires an
# initialize handshake first per the MCP spec; abbreviated example below
# shows the tool-call request body only:
curl -s -X POST http://localhost:8080/mcp \
  -H "X-PRTG-Server-Url: prtg.example.com" \
  -H "X-PRTG-Username: api_user" \
  -H "X-PRTG-Passhash: <your-passhash>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: <session-id-from-initialize>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "prtg_get_sensors",
      "arguments": {}
    }
  }'

Live-verifiziert (2026-07-30) gegen einen echten PRTG-Core-Server, alle 3 Werkzeuge Ende-zu-Ende durch diesen laufenden Server mit echten Anmeldedaten aufgerufen: prtg_get_sensors und prtg_get_devices lieferten beide 200 mit einer echten prtg-version-Zeichenfolge und einer gültigen (leeren) Ergebnismenge – dieses spezielle Testkonto hat null Sensoren/Geräte in seinem sichtbaren Bereich bereitgestellt, was durch eine separate Abfrage von content=probes als echte „Keine-Daten"-Bedingung (kein Auth-Fehler) bestätigt wurde; diese Abfrage lieferte echte Daten (die PRTG-Root-Probe plus mehrere echte Planungsobjekte) mit genau denselben Anmeldedaten. prtg_get_sensor_historic_data, aufgerufen mit einer Nicht-Sensor-Objekt-ID (da keine echte Sensor-ID verfügbar war), erreichte korrekt die API und gab den herstellereigenen Fehler auf Inhaltsebene zurück („The selected object cannot be used here"), was beweist, dass die Anfrage-/Auth-Pipeline korrekt verdrahtet ist.

API-Referenz

• Öffentlich, keine Anmeldung erforderlich:

  • Sensor-/Geräte-Tabellenformat: https://www.paessler.com/manuals/prtg/multiple_object_property_or_status#supported_output

  • Historische Daten: https://www.paessler.com/manuals/prtg/historic_data

Bekannte Lücken

• Der Umfang entspricht exakt den 3 konfigurierten Endpunkten von MSPbots, nicht der vollständigen API-Oberfläche des Herstellers – die PRTG-API umfasst auch Live-Sensorsteuerung (Pause/Fortsetzen/Bestätigen), Objekterstellung/-löschung, Benachrichtigungen, Berichte und mehr; diese sind hier nicht im Umfang enthalten.

• Sensor-/Gerätedaten konnten nicht mit echten Datensätzen demonstriert werden – das bereitgestellte Testkonto (Dash_Display, wahrscheinlich ein Nur-Dashboard-Anzeigekonto) hat null Sensoren und null Geräte in seinem sichtbaren Bereich auf dieser speziellen PRTG-Instanz bereitgestellt. Der Live-Test bestätigte, dass es sich um ein echtes leeres Ergebnis handelt (kein Auth- oder Implementierungsfehler), indem erfolgreich ein anderer, immer gefüllter Objekttyp (content=probes) mit denselben Anmeldedaten abgefragt wurde und echte Daten zurückkamen.

• prtg_get_sensor_historic_data konnte aus demselben Grund nicht mit einer echten Sensor-ID getestet werden (es gibt keine Sensoren, auf die verwiesen werden kann); stattdessen wurde es verifiziert, indem die herstellereigene Fehlerantwort auf Inhaltsebene für eine ungültige Objekt-ID bestätigt wurde, was beweist, dass das Anfrageformat und die Authentifizierung korrekt sind.