Skip to main content
Glama
Sign In
deenesjakoruzh
Network Incident MCP

Network Incident MCP

by asif-c
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Network Incident MCP Demo

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.txt

テストの実行

python3 -m pytest tests/

MCPサーバーの単独実行

python3 mcp_server/server.py

ライブエージェントの実行

Google 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)で再試行してから成功します。

パブリックHTTPデモ(APIキー不要)

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 reroute

注意事項

  • mcp<2が必要です(requirements.txtにすでにピン留めされています)——サーバーはv1のFastMCP APIを使用します。

  • Geminiモデルの利用可能状況は時間とともに変化します。404のモデルが見つからないエラーが発生した場合は、APIキーで利用可能なモデルを一覧表示し、agent/gemini_mcp_client.pyのモデル名を更新してください。

  • ツール呼び出しのラウンドは、API使用量の暴走を防ぐために実行ごとに上限が設定されています(GeminiMCPOrchestrator.MAX_TURNS、デフォルト5)。

This server cannot be deployed

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • network-mcp

    E-Conners-Lab
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides AI assistants with direct access to multi-vendor network devices for tasks like configuration management, health checks, and topology discovery through 35 specialized tools. It enables natural language control over platforms including Cisco, Juniper, and Nokia using SSH, NETCONF, and SNMP protocols.
    12
    MIT