Eine kleine Demo/ein kleiner Prototyp, der zeigt, wie ein LLM-Agent (Google Gemini) das Model Context Protocol (MCP) nutzt, um einen simulierten Netzwerkvorfall zu bearbeiten: Gerätetelemetrie abrufen, Syslogs prüfen, entscheiden, ob eine Aktion erforderlich ist, und einen Behebungsschritt ausführen — alles über Tools, die von einem lokalen MCP-Server bereitgestellt werden.
Dies ist ein Prototyp zu Lern-/Demo-Zwecken. Alle Netzwerkdaten sind simuliert und in mcp_server/mock_network_db.py hartcodiert. Es gibt kein echtes Netzwerk-Backend.
mcp_server/ — ein MCP-Server, der Folgendes bereitstellt:
get_device_telemetry(device_id) — Gerätestatus, optische Leistung, BGP-Flaps
get_latest_syslog() — letzte Syslog-Zeilen
apply_traffic_reroute(source_pop, target_pop, circuit_id) — eine Mock-Behebungsaktion (lehnt jedes Ziel ab, das kein bekannter, gesunder PoP ist)
incident_triage_prompt(device_id) — eine Prompt-Vorlage, die die Triage-Schritte und die -20.0 dBm-Reroute-Schwelle beschreibt
agent/gemini_mcp_client.py — ein Client, der den MCP-Server startet, seine Tools an Gemini als Function-Calling-Tools übergibt und eine Schleife ausführt: Gemini entscheidet, welches Tool als Nächstes aufgerufen wird, der Client führt es über MCP aus und gibt das Ergebnis zurück, bis Gemini eine endgültige Antwort gibt.
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.pyErfordert einen Gemini-API-Schlüssel von Google AI Studio:
export GEMINI_API_KEY=your-key-here
python3 agent/gemini_mcp_client.pyDer Agent ist auf das Mock-Gerät router-van-01 ausgerichtet, das als DEGRADED mit einer optischen Leistung von -28.5 dBm simuliert wird — unterhalb der -20.0 dBm-Reroute-Schwelle. Ein echter Lauf sieht wie folgt aus:
(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`.Beachten Sie, dass der erste Reroute-Versuch des Modells auf Richmond PoP abzielt, das in den Mock-Daten kein echter, gesunder Standort ist — der Server lehnt ihn mit einem ERROR ab, anstatt stillschweigend zu gelingen, und das Modell versucht es erneut mit dem korrekten gesunden Ziel (Toronto PoP), bevor es erfolgreich ist.
web/app.py ist ein kleiner FastAPI-Wrapper um dieselbe Mock-Telemetrie-/Reroute-Logik, die als einfache REST-Endpunkte bereitgestellt wird — kein MCP-Client und kein Gemini-API-Schlüssel erforderlich. /triage/{device_id} implementiert den Ablauf Abrufen → Prüfen → Reroute deterministisch in Python (nicht über ein LLM), sodass es kostenlos und sicher öffentlich bereitgestellt werden kann.
Lokal ausführen:
uvicorn web.app:app --host 127.0.0.1 --port 8001Dann, von einem anderen Terminal aus:
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 rerouteErfordert mcp<2 (bereits in requirements.txt gepinnt) — der Server verwendet die v1-FastMCP-API.
Die Verfügbarkeit von Gemini-Modellen ändert sich im Laufe der Zeit; falls Sie auf einen 404-Fehler „Modell nicht gefunden“ stoßen, listen Sie die für Ihren API-Schlüssel verfügbaren Modelle auf und aktualisieren Sie den Modellnamen in agent/gemini_mcp_client.py.
Die Tool-Calling-Runden sind pro Lauf begrenzt (GeminiMCPOrchestrator.MAX_TURNS, Standard 5), um einen unkontrollierten API-Verbrauch zu vermeiden.
This server cannot be deployed
MCP-Native LLM Orchestration Agent
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
IP intelligence, network diagnostics, and AI service availability tools for AI agents.
LLM Orchestration MCP Agent
