LLMエージェント(Google Gemini)が**Model Context Protocol (MCP)**を使用してシミュレートされたネットワークインシデントをトリアージする様子を示す小さなデモ/プロトタイプ:デバイステレメトリの取得、syslogの検査、アクションが必要かどうかの判断、修復ステップの実行——これらすべてをローカルMCPサーバーが公開するツールを通じて行います。
これは学習/デモ目的のプロトタイプです。ネットワークデータはすべて偽物で、mcp_server/mock_network_db.pyにハードコードされています。実際のネットワークバックエンドはありません。
mcp_server/ — 以下を公開するMCPサーバー:
get_device_telemetry(device_id) — デバイスのステータス、光パワー、BGPフラップ
get_latest_syslog() — 最近のsyslog行
apply_traffic_reroute(source_pop, target_pop, circuit_id) — モックの修復アクション(既知の健全なPoPではないターゲットを拒否します)
incident_triage_prompt(device_id) — トリアージ手順と-20.0 dBmのリルートしきい値を説明するプロンプトテンプレート
agent/gemini_mcp_client.py — MCPサーバーを起動し、そのツールを関数呼び出しツールとしてGeminiに渡し、ループを実行するクライアント:Geminiが次に呼び出すツールを決定し、クライアントがMCP経由でそれを実行して結果をフィードバックし、Geminiが最終回答を返すまで繰り返します。
Related MCP server: Pulse
git clone <your-repo-url>
cd network-incident-mcp
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txtpython3 -m pytest tests/python3 mcp_server/server.pyGoogle AI StudioのGemini APIキーが必要です:
export GEMINI_API_KEY=your-key-here
python3 agent/gemini_mcp_client.pyエージェントはモックデバイスrouter-van-01を対象としており、このデバイスは光パワーが-28.5 dBmのDEGRADED状態としてシミュレートされています——これは-20.0 dBmのリルートしきい値を下回ります。実際の実行は次のようになります:
(venv) ac@ubuntuserver2026:~/network-incident-mcp$ python3 agent/gemini_mcp_client.py
Processing request of type ListToolsRequest
[+] Connected to MCP. Registered 3 tools with Gemini 3.6 Flash.
Processing request of type GetPromptRequest
[--> Model Tool Call Request]: get_device_telemetry({'device_id': 'router-van-01'})
Processing request of type CallToolRequest
[<-- MCP Execution Output]: {
"device_id": "router-van-01",
"data": {
"status": "DEGRADED",
"location": "Vancouver PoP",
"bgp_flaps": 14,
"optical_power_dbm": -28.5,
"circuits": [
"fiber-van-richmond-10G"
]
}
}
[--> Model Tool Call Request]: get_latest_syslog({})
Processing request of type CallToolRequest
[<-- MCP Execution Output]:
[2026-08-24T10:12:01Z] WARN router-van-01 BGP neighbor 192.168.10.1 DOWN (Retries: 3)
[2026-08-24T10:12:15Z] CRIT router-van-01 Optical signal loss detected on fiber-van-richmond-10G (-28.5 dBm)
[2026-08-24T10:14:02Z] WARN router-van-01 Packet loss spike: 18.4% on interface ge-0/0/1
[--> Model Tool Call Request]: apply_traffic_reroute({'target_pop': 'Richmond PoP', 'circuit_id': 'fiber-van-richmond-10G', 'source_pop': 'Vancouver PoP'})
Processing request of type CallToolRequest
[<-- MCP Execution Output]: {
"status": "ERROR",
"error": "Target PoP 'Richmond PoP' is not a known healthy PoP. Healthy PoPs: ['Toronto PoP']"
}
[--> Model Tool Call Request]: apply_traffic_reroute({'circuit_id': 'fiber-van-richmond-10G', 'target_pop': 'Toronto PoP', 'source_pop': 'Vancouver PoP'})
Processing request of type CallToolRequest
[<-- MCP Execution Output]: {
"status": "SUCCESS",
"action": "Traffic shifted from Vancouver PoP to Toronto PoP",
"isolated_circuit": "fiber-van-richmond-10G",
"new_route_metric": 10
}
[Model Final Response]: ### Incident Analysis Summary for `router-van-01`
1. **Device Telemetry Analysis**
- **Device ID:** `router-van-01`
- **Location:** Vancouver PoP
- **Device Status:** DEGRADED
- **Optical Power Level:** **-28.5 dBm**
- **BGP Flaps:** 14
- **Active Circuit:** `fiber-van-richmond-10G`
2. **Syslog Inspection**
- Critical optical signal loss log detected:
`[2026-08-24T10:12:15Z] CRIT router-van-01 Optical signal loss detected on fiber-van-richmond-10G (-28.5 dBm)`
- Additional warnings observed regarding BGP neighbor timeouts and interface packet loss spikes (`ge-0/0/1`).
3. **Remediation Action**
- **Condition Met:** Optical power level (-28.5 dBm) is below the threshold of -20.0 dBm.
- **Action Taken:** Executed `apply_traffic_reroute`.
- **Circuit:** `fiber-van-richmond-10G`
- **Source PoP:** Vancouver PoP
- **Target PoP:** Toronto PoP
- **Status:** **SUCCESS** — Traffic successfully rerouted from Vancouver PoP to Toronto PoP, isolating circuit `fiber-van-richmond-10G`.モデルの最初のリルート試行はRichmond PoPをターゲットにしていますが、これはモックデータ内の実際の健全なロケーションではありません——サーバーは黙って成功させる代わりにERRORで拒否し、モデルは正しい健全なターゲット(Toronto PoP)で再試行してから成功します。
web/app.pyは、同じモックテレメトリ/リルートロジックをラップする小さなFastAPIラッパーで、プレーンなRESTエンドポイントとして公開されています——MCPクライアントもGemini APIキーも不要です。/triage/{device_id}は、fetch → check → rerouteフローをPythonで決定的に(LLM経由ではなく)再実装しているため、公開しても無料で安全です。
ローカルで実行するには:
uvicorn web.app:app --host 127.0.0.1 --port 8001次に、別のターミナルから:
curl http://127.0.0.1:8001/devices
curl http://127.0.0.1:8001/telemetry/router-van-01
curl http://127.0.0.1:8001/syslog
curl http://127.0.0.1:8001/triage/router-van-01 # degraded device -> auto-reroutes
curl http://127.0.0.1:8001/triage/router-yyz-02 # healthy device -> no reroutemcp<2が必要です(requirements.txtにすでにピン留めされています)——サーバーはv1のFastMCP APIを使用します。
Geminiモデルの利用可能状況は時間とともに変化します。404のモデルが見つからないエラーが発生した場合は、APIキーで利用可能なモデルを一覧表示し、agent/gemini_mcp_client.pyのモデル名を更新してください。
ツール呼び出しのラウンドは、API使用量の暴走を防ぐために実行ごとに上限が設定されています(GeminiMCPOrchestrator.MAX_TURNS、デフォルト5)。
This server cannot be installed
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Phone, SMS & email for AI agents — one remote MCP endpoint, OAuth login, zero install.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/asif-c/network-incident-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server