prtg-mcp

PRTG Network Monitor（Paessler のネットワーク/インフラストラクチャ監視）用の MCP サーバー。PRTG のネイティブ HTTP API のセンサー、デバイス、および履歴センサーデータを MCP ツールとして公開します。

概要

• ステートレスな HTTP サービス。認証情報は一切永続化されません。各リクエストはヘッダー経由で独自の認証情報を提供し、その単一リクエストの期間中のみ使用されます。

• 同時リクエストをサポート。リクエストごとの認証情報の分離は、グローバル/共有クライアントインスタンスではなく、Python の contextvars によって行われます。

• エントリポイント: POST /mcp（MCP プロトコル）および GET /health（ヘルスチェック）。

• デフォルトポート: 8080（MCP_HTTP_PORT で設定可能）。

Related MCP server: mcp-ntopng

認証

このプログラムのほとんどの統合とは異なり、PRTG には個別のログインやトークン交換はありません: ユーザー名と「passhash」（PRTG の UI の My Account -> API Key で生成されるもので、アカウントの平文パスワードではありません）は、すべての呼び出しで平文のクエリパラメータとして送信されます。したがって、キャッシュするものは何もありません。各呼び出しは、ベンダーの設計により、すでに完全に自己完結型でステートレスです。

ヘッダー認証パラメータの説明

いずれかのヘッダーが欠落している場合は 401 を返します:

{
  "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": []
}

無効な認証情報は、ツールレベルのエラーエンベロープ（下記のエラーエンベロープを参照）として表面化し、PRTG の HTTP ステータスコードから分類されます — 401/403 は unauthorized にマッピングされます。非 2xx 応答の場合、このサーバーは JSON ボディから message/error フィールドの抽出を試み、そのボディが JSON でない場合は生の応答テキストにフォールバックします（PRTG は、特定の不正なリクエストに対して、.json エンドポイントでも XML の <error> ボディにフォールバックすることがあります）。

環境変数

MCP エンドポイント

• POST /mcp — MCP プロトコル（ストリーミング可能な HTTP トランスポート）

• GET /health — ヘルスチェック。{"status": "ok"} を返します（純粋なローカルプローブであり、PRTG を呼び出しません）

ツール一覧

3 つのツールはすべて読み取り専用です（readOnlyHint=True、idempotentHint=True）。このサービスには書き込み/削除ツールはありません。

count には、PRTG の table.json エンドポイントに対するベンダー側の文書化されたハード上限がないため、このサーバーは値を無検証でそのまま渡すのではなく、プラットフォーム独自のフォールバック上限を適用します: デフォルトは 50 で、200 を超える値は PRTG にそのまま送信されるのではなく、暗黙のうちに 200 にクランプされます。

レスポンス形式

このサーバーが呼び出す両方のエンドポイント（table.json、historicdata.json）はベンダーの JSON サフィックス付きバリアントであるため、成功時にはクライアントは常に JSON のみを解析します。PRTG の HTTP API は、他のエンドポイント/パラメータでは原則として XML を返す可能性があるため、クライアントは防御的に解析します: 非 2xx 応答は下記の構造化エラーエンベロープに分類され、2xx 応答が JSON として解析に失敗した場合は、例外を発生させる代わりに、その生のテキストが raw_response キーの下で返されます。

エラーエンベロープ

ツールエラーは、発生した例外としてではなく、構造化された JSON 文字列として返されるため、呼び出し側エージェントは code に基づいて分岐し、再試行するかどうかを決定できます:

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

code は次のいずれかです: not_configured、unauthorized、not_found、invalid_argument、rate_limited、upstream_error。空の結果セットは、not_found ではなく、通常の（エラーではない）空のコレクションとして返されます。

ツールの戻り値（成功とエラーの両方）は、20,000 文字に制限されたコンパクトな JSON（ensure_ascii=False、indent なし）です。サイズ超過の結果は、無制限のブロブを返すのではなく、最大のリストフィールドを切り詰めて、truncated/original_count を報告します。

テスト例

# 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": {}
    }
  }'

実際の PRTG コアサーバーに対してライブ検証済み（2026-07-30）。3 つのツールすべてが、この実行中のサーバーを通じて実際の認証情報でエンドツーエンドに呼び出されました: prtg_get_sensors と prtg_get_devices はどちらも、実際の prtg-version 文字列と有効な（空の）結果セットを伴って 200 を返しました。この特定のテストアカウントは、その可視スコープ内にゼロ個のセンサー/デバイスがプロビジョニングされており、まったく同じ認証情報を使用して content=probes を別途クエリし、実際のデータ（PRTG Root probe といくつかの実際のスケジューリングオブジェクト）が返されたことで、これが（認証失敗ではなく）本当の「データなし」状態であることが確認されました。prtg_get_sensor_historic_data は、（実際のセンサー ID が利用できなかったため）非センサーオブジェクト ID で呼び出され、API に正しく到達し、ベンダー自身のコンテンツレベルのエラー（"The selected object cannot be used here"）を返し、リクエスト/認証パイプラインが正しく配線されていることを証明しました。

API リファレンス

• 公開、ログイン不要:

  • センサー/デバイスのテーブル形式: https://www.paessler.com/manuals/prtg/multiple_object_property_or_status#supported_output

  • 履歴データ: https://www.paessler.com/manuals/prtg/historic_data

既知のギャップ

• スコープはまさに MSPbots の設定済み 3 エンドポイントであり、ベンダーの完全な API サーフェスではない — PRTG の API は、ライブセンサー制御（一時停止/再開/確認）、オブジェクトの作成/削除、通知、レポートなどもカバーしていますが、これらはここではスコープ外です。

• センサー/デバイスのデータを実際のレコードで実証できなかった — 提供されたテストアカウント（Dash_Display、おそらくダッシュボード専用の表示アカウント）には、この特定の PRTG インスタンスの可視スコープ内にゼロ個のセンサーとゼロ個のデバイスがプロビジョニングされています。ライブテストでは、同じ認証情報で別の常にデータが入っているオブジェクトタイプ（content=probes）をクエリして実際のデータを取得できたため、これが（認証や実装のバグではなく）本当の空の結果であることが確認されました。

• prtg_get_sensor_historic_data は、実際のセンサー ID でテストできなかった — 同じ理由（参照するセンサーが存在しない）によるものです。代わりに、無効なオブジェクト ID に対するベンダー自身のコンテンツレベルのエラー応答を確認することで検証され、リクエスト形式と認証が正しいことが証明されました。