PRTG について
セルフホスト型 Paessler PRTG Network Monitor 向けの読み取り専用 MCP サーバーです。REST API v2 を通じてデバイスやセンサーの状態、測定履歴、アラームを取得し、監視設定や管理情報は変更しません。
主な機能
- 01デバイス、グループ、プローブの一覧
- 02センサー状態と設定の確認
- 03センサー測定履歴の取得
- 04発生中のアラーム一覧
- 05センサー状態の集計
- 06PRTG バージョンの確認
活用シーン
- 01インフラのデバイスとセンサーの状態確認
- 02センサー測定履歴の調査
- 03アラーム状態のセンサー特定
- 04PRTG の接続とバージョンの確認
MCP 対応
API キーと PRTG Application Server のベース URL を使い、PRTG REST API v2 の読み取り専用操作を MCP ツールとして公開します。書き込みや管理操作は対象外です。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
docker run -i --rm -e PRTG_API_KEY -e PRTG_BASE_URL -e MCP_TRANSPORT -e AUTH_MODE -e LOG_LEVEL ghcr.io/wyre-ai/prtg-mcp:v1.0.1PRTG_API_KEYシークレットPRTG API key (Bearer token, generated in the PRTG web UI under Account Settings -> My Account -> API Keys).PRTG_BASE_URLBase URL of the PRTG Application Server for self-hosted PRTG Network Monitor (which serves API v2; HTTPS port 1616 by default), e.g. https://prtg.example.com:1616. Not the classic web interface URL. PRTG Hosted Monitor does not provide API v2.MCP_TRANSPORTTransport mode for the server. Set to 'stdio' for local CLI use; the image defaults to 'http' for gateway hosting.AUTH_MODEシークレットCredential source: 'env' reads vars locally, 'gateway' expects header injection from the WYRE MCP Gateway.LOG_LEVELLog verbosity: debug, info, warn, errorローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。
ghcr.io/wyre-ai/prtg-mcp:v1.0.1stdioツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
PRTG MCP サーバー
Paessler PRTG の REST API v2 用 MCP サーバーです。PRTG ネットワーク/インフラストラクチャ監視インスタンス全体のデバイス/センサーのステータス、監視データ(チャネルの測定履歴)、アラート(アラーム状態のセンサー)を、AI アシスタントと WYRE Conduit ゲートウェイ向けに提供します。
認証
PRTG の認証には、PRTG のウェブ UI の Account Settings -> My Account -> API Keys で生成する静的な Bearer API キーを使用します。生成に管理者の承認は不要で、どの PRTG ユーザーも自分用のキーを作成できます。このコネクターは、フリート内のほとんどのコネクターと異なり、固定のホスト型 API エンドポイントを持ちません。セルフホストの PRTG Network Monitor は独自のベース URL を使用するため、このコネクターでサポートされています(PRTG Hosted Monitor はまだ API v2 を提供していません。詳細は以下を参照してください)。そのため、API キーとベース URL の両方が必要です。キーは <base URL>/api/v2/... に Authorization: Bearer <key> として送信されます。ゲートウェイモードでは、リクエストごとに X-PRTG-Api-Key と X-PRTG-Base-URL ヘッダーで両方を受け取ります。ローカル/stdio モードでは、PRTG_API_KEY と PRTG_BASE_URL から一度だけ読み込まれます。
認証情報のスコープ
ベンダーの文書に基づく情報であり、実際のアカウントで個別に検証したものではありません(その理由については、以下の「検証」を参照してください)。Paessler の PRTG API v2 公式ドキュメントによると、API キーには、そのキーを作成した PRTG ユーザーアカウントの完全な権限が継承されます。キーに対して個別に読み取り専用のスコープを設定することはできません。AI アシスタントとの連携について Paessler が公式に推奨する方法は明確です。「[AI アシスタントで使用する API キーには、アシスタントのタスクに適した最も低いユーザーロールを付与してください」]。また、キー自体でアクセスを制限しようとせず、まず読み取り専用の専用 PRTG ユーザーアカウントを作成し、そのアカウントで API キーを生成することを推奨しています。このコネクターは PRTG 側でその設定を強制できません。以下に記載する読み取り専用のツール機能のみを実装しています。そのため、実際に読み取り専用となるかどうかは、キーの生成時にお客様が Paessler の推奨に従うかどうかにかかっています。
ベース URL(オンプレミス)
オンプレミスの PRTG Network Monitor では、API v2 はクラシックウェブインターフェースではなく、PRTG Application Server のみで提供されます。Application Server の HTTPS URL(デフォルトのポートは 1616)を使用してください。例:https://prtg.example.com:1616。Application Server はポート 1615 でプレーンな HTTP も待ち受けますが、すべてのリクエストに Bearer API キーが含まれるため、http://...:1615 は信頼できるネットワーク内でのみ使用してください。クラシックウェブインターフェースの URL(ポート 80/443)は /api/v2 を提供せず、通常は 404、リダイレクト、または HTML のログインページを返すため、認証エラーのように見えることがあります。
Application Server は、New UI and API v2 を有効化した後にのみ利用できます。クラシック UI で Setup | Overview に移動し、Activate を選択してください(ポート 1616/1615 および 23580 が空いている必要があり、コアサーバーが再起動します)。Paessler によると、PRTG 25.2.106 以降では、新規 PRTG ユーザー向けにデフォルトで有効化されています。既存のインストール、アップグレード、および Setup | Overview に Activate New UI And API v2 と表示されているインストールでは、手動で有効化する必要があります。また Paessler は、PRTG Hosted Monitor およびクラスター モードで稼働している PRTG では、API v2 はまだ利用できないとしています。Paessler の新しい UI と API v2 を使用したいのですが、何を知っておく必要がありますか?および新しいユーザーインターフェースのマニュアルページを参照してください。
検証
このコネクターは、二次資料や命名規則ではなく、PRTG の公式かつ最新の OpenAPI v2 仕様(prtg.api.yaml、paessler.com/support/prtg/api/v2/oas/ で公開)に直接基づいて構築されています。以下の各ツールは、その仕様にある実在の名前付きオペレーションと、正確なクエリパラメーターに対応しています。ただし、PRTG の実稼働インスタンスに対して独立して検証したものではありません。PRTG の無料プランは、(a)Windows 専用のオンプレミスソフトウェアである PRTG Network Monitor の30日間トライアルと、(b)クラウド SaaS の申し込みである PRTG Hosted Monitor(app.my-prtg.com/signup)の10日間トライアルです。ビルド環境では、どちらも検証フローを完了できませんでした(PRTG Network Monitor をインストールする Windows ホストがなく、PRTG Hosted Monitor の申し込み確認を完了するためのメール受信トレイもありませんでした)。どちらも、Windows マシンまたは確認できるメール受信トレイがあれば、人が実際にセルフサービスで利用できます。これはビルド環境の制約であり、ベンダー側の承認プロセスによるものではありません。
設定
| 環境変数 | 説明 |
|---|---|
PRTG_API_KEY | PRTG のウェブ UI で発行されるベアラー API キーです。 |
PRTG_BASE_URL | API v2 を提供する PRTG Application Server のベース URL です。例:https://prtg.example.com:1616。従来のウェブインターフェースの URL ではありません。上記の ベース URL(オンプレミス) を参照してください。 |
MCP_TRANSPORT | stdio(デフォルト)または http です。 |
AUTH_MODE | env(デフォルト。上記の変数を読み取ります)または gateway(Conduit ゲートウェイが挿入する X-PRTG-Api-Key / X-PRTG-Base-URL ヘッダーを通じて、リクエストごとに認証情報を受け取ります)。 |
CONDUIT_S2S_SECRET | 設定すると、HTTP トランスポートは、すべての /mcp リクエストで有効な X-Gateway-S2S ヘッダー(Conduit サイドカー認証)を必須とします。 |
LOG_LEVEL | debug | info(デフォルト)| warn | error です。 |
リクエスト制限
- HTTP リクエストボディの上限は256 KiB(262144バイト)です。
X-Gateway-S2Sの検証に成功した後、Content-Lengthが上限を超えている場合は、JSON-RPC エラーとともに 413 を返します。Content-Lengthのないボディ(例:チャンク転送)は MCP SDK トランスポートによって制限され、こちらも 413 を返します。サイズ超過のツール入力には、固定エラーTool input exceeds the maximum of 10000 elementsを返します。未認証のリクエストには、先に 401 を返します。 tools/callの引数は10,000要素までに制限されます(すべての配列項目と、任意の深さにあるオブジェクトキーを数えます)。これを超える入力にはisErrorツール結果を返し、ディスパッチは行いません。
これらの制限は、CVE-2026-111768 / GHSA-46jr-4wx8-v453(検証中のメモリ枯渇)および GHSA-f897-62hf-6gxq(リクエストボディおよびバッチの上限なし)に対処するものです。
ツール
デバイス
prtg_list_devices- 監視対象デバイス(ホスト名/IP、ステータス、親グループ/プローブ)を一覧表示します。prtg_get_device- 1台のデバイスのメトリクスと設定を取得します。
グループ
prtg_list_groups- デバイスを含む組織フォルダーであるグループを一覧表示します。prtg_get_group- 1つのグループのメトリクスと設定を取得します。
プローブ
prtg_list_probes- 実際のセンサーチェックを実行する監視エージェント(ローカル、リモート、ミニ)であるプローブを一覧表示します。prtg_get_probe- 1つのプローブのメトリクスと設定を取得します。prtg_get_probe_network_info- プローブのネットワーク情報を取得します。
センサー
prtg_list_sensors- デバイスに接続された個々のチェック(ping、HTTP、SNMP など)であるセンサーを、現在のステータスとともに一覧表示します。prtg_get_sensor- 1つのセンサーのメトリクスと設定を取得します。prtg_get_sensor_data- センサーのチャネル測定履歴(実際の監視/パフォーマンスデータ)を取得します。prtg_list_alarms- 現在、Down/Warning/Unusual などのアラーム状態にあるセンサーを一覧表示します。PRTG のアラート機能です。
センサーのステータス概要
prtg_get_sensor_status_summary- インスタンス全体にわたるすべてのセンサー状態の概要を取得します。prtg_get_object_sensor_summary- 1つのプローブ、グループ、またはデバイスに絞ったセンサー状態の概要を取得します。
チャネル
prtg_get_channel- センサー上の1つのチャネルのメトリクスと設定(単位、上限、現在値)を取得します。
システム
prtg_get_version- PRTG コア/appserver のバージョンを取得します。認証情報や接続性の健全性チェックに役立ちます。
範囲
これは、デバイス/センサーのステータス、監視データ、アラートのみを対象とした、意図的に範囲を絞った読み取り専用の v1 サーフェスです。それ以外は一切対象外です。 PRTG API v2 のドキュメントには広範な機能(オブジェクトの CRUD、自動検出、ユーザー/API キーの管理、AI アシスタントのエンドポイント、/experimental 名前空間全体)が記載されていますが、このコネクターが実装するのは、その中の GET 操作 15 件(安定した非実験的なものが 10 件、ドキュメントには記載されているものの非推奨のものが 5 件。以下を参照)です。公式 OpenAPI 仕様と 1 件ずつ照合して確認しており、設計上、書き込み/一時停止/再開/スキャン/確認/検出/管理に関する操作はすべて除外しています。また、実際に /experimental/* に属するエンドポイントもすべて除外しています。これは見落としではありません。
実装済みの 15 件のエンドポイントのうち、いくつか(GET /devices、/groups、/probes、/sensors、/sensors/alarms)は、PRTG 独自の v2 仕様で deprecated とされ、代わりに /experimental/* のエンドポイントが推奨されています。このコネクターは、/experimental の代替エンドポイントではなく、ドキュメントに記載され、現在も動作する非推奨エンドポイントを意図的に使用します。PRTG 独自の仕様によると、実験的なエンドポイントは「変更される可能性」がありますが、非推奨のエンドポイントは「引き続き動作」し、PRTG の主要なオブジェクトタイプを一覧表示できる唯一の非実験的な方法です。本番環境向けコネクターでは、不安定でも最新のエンドポイントより、安定しているものの非推奨のエンドポイントのほうが安全な選択肢と判断しました。以下では、すべての /experimental/* エンドポイントを(一覧表示用かどうかにかかわらず)例外なく除外しています。
対象外(変更操作 - 実装なし): 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。
対象外(アラートの確認 - 実装なし): POST /sensors/{id}/acknowledge、/sensors/acknowledge - アラームの確認は PRTG のアラート状態に対する書き込み操作です。ステータス照会のように見える場合でも、このコネクターの厳格な対象範囲に従って除外しています。
対象外(オブジェクトの変更 - 実装なし): POST /objects/{id}/move、/objects/{id}/clone、および /experimental 名前空間全体の作成/更新/削除操作(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})、ならびに同名前空間の読み取り専用一覧表示用ミラー(GET /experimental/devices、/experimental/groups、/experimental/probes、/experimental/sensors、/experimental/channels、/experimental/objects、/experimental/devices/templates)です。PRTG 独自のドキュメントで変更される可能性があると説明されている名前空間全体を除外しているため、安全性を個別に検証していません。
対象外(自動検出 - 実装なし): 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 - 自動検出はネットワークのインベントリー作成とスキャンの実行を行うため、このコネクターのデバイス/センサー/監視/アラートの対象範囲外です。
除外対象(ユーザー/API キー/セッション/ライセンスの管理 — デバイス/センサー/アラートデータではなく、ID と認証情報の管理)—実装しません: 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(ログイン/更新/ログアウト)、POST /users/request-password、/users/reset-password、GET /experimental/license。
除外対象(オブジェクトスキーマ/汎用 CRUD/設定/AI 機能/その他の管理)—対象範囲外のため、実装しません: GET/POST/PATCH /schemas/{kind}、/experimental/schemas/*、GET /experimental/objects、/objects、/objects/count、/libraries、/lookup-definitions*、/setting-lookups/{name}、/settings/public、/health(認証不要の稼働確認のみ — 代わりに、このコネクターでは認証済みの健全性チェックとして prtg_get_version を使用します)、/devices/icons、/experimental/feature-toggles、/experimental/featureflags、/experimental/ai/analyze、/experimental/ai/status、/experimental/timeseries/{id}、/experimental/timeseries/{id}/{type}、/channels(一覧)および /channels/data(どちらも、実装済みで非推奨ではない GET /channels/{id} を優先して非推奨)、/channels/{id}/overview、/devices/{id}/overview、/groups/{id}/overview、/probes/{id}/overview、/sensors/{id}/overview(いずれも、実装済みの概要を含まない GET .../{id} に相当するエンドポイントを優先して非推奨)。
需要があれば、対象範囲を慎重に決定したうえで、後から追加できます。デフォルトでは追加しません。
開発
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
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。