Packet Tracer MCP

MCP-Server, der es Claude Code ermöglicht, Topologien in Cisco Packet Tracer in natürlicher Sprache aufzubauen und zu konfigurieren: Geräte erstellen, verkabeln, IOS-Befehle anwenden, VLANs, OSPF, NAT, ACLs, VoIP oder ein komplettes Netzwerk anhand des Bildes eines Diagramms nachbilden.

Tu -> Claude Code --stdio--> mcp_server.py --HTTP--> bridge :54321
                                                         |
                              Packet Tracer  <-----------+
                              modulo Builder:
                                bridge.js         (pagina: hace el polling)
                                bridge_runner.js  (motor: ejecuta y devuelve)

Die HTTP-Bridge läuft innerhalb des MCP-Servers: Es ist kein separates Terminal nötig, um sie zu starten. Und die Polling-Schleife lebt im Builder-Modul: Auch dort muss nichts in Packet Tracer eingefügt werden.

Voraussetzungen

Related MCP server: packet-tracer-mcp

Inbetriebnahme (einmalig)

1. Abhängigkeiten

uv sync

2. Builder-Modul in Packet Tracer installieren

packet_tracer/Builder.pts ist das Skriptmodul, das innerhalb von PT die Funktionen definiert, die dieses Projekt verwendet (addDevice, addLink, addModule, configureIosDevice, configurePcIp, getDevices, removeLink, addLabel, saveTopology) sowie die Brücke, die es mit der HTTP-Bridge verbindet. Ohne dieses Modul funktioniert nichts.

In Packet Tracer (Menüs auf Englisch, verifiziert mit PT 9.0.0):

1. Extensions -> Scripting -> Configure PT Script Modules

2. Add -> wähle packet_tracer/Builder.pts aus diesem Repo

3. Wähle Builder in der Liste -> Settings -> aktiviere On Startup, damit das Modul jedes Mal automatisch startet, wenn du PT öffnest

4. Zur Bestätigung, dass es läuft: Im Menü Extensions muss der Eintrag Builder Code Editor erscheinen. Wenn er nicht erscheint, ist das Modul nicht gestartet.

Beim Start öffnet das Modul automatisch das Fenster Builder Code Editor. Dieses Fenster beherbergt die Polling-Schleife, daher muss es geöffnet bleiben, während du arbeitest; wenn sein Titel „bridge aktiv" anzeigt, ist die Brücke funktionsfähig.

3. Projekt in Claude Code öffnen

Von einem Terminal aus, im Projektordner:

claude

Claude Code liest .mcp.json und startet den MCP-Server (und damit auch die HTTP-Bridge) automatisch. Beim ersten Mal kann es dich auffordern zu bestätigen, dass du dem Ordner vertraust.

Um zu prüfen, ob der Server verbunden ist, gib /mcp in Claude Code ein: packet-tracer muss mit seinen Tools erscheinen.

Tägliche Nutzung

1. Abre Packet Tracer
   -> la ventana "Builder Code Editor" se abre sola y debe quedarse abierta

2. En una terminal, en la carpeta del proyecto:
      cd ruta/al/pt_MCP
      claude

3. Dentro de Claude Code:
      /pt-iniciar     -> confirma que las 3 piezas responden

Es muss nichts weiter gestartet werden: weder main.py, noch Skripte in Packet Tracer einfügen, noch zusätzliche Terminals.

Und von da an in natürlicher Sprache:

• „Erstelle zwei 2911-Router, verbunden über Serial mit 10.0.0.0/30, und einen PC in jedem LAN"

• /pt-desde-imagen diagramas/ejemplo-red1.jpeg — reproduziert die Topologie eines Diagramms

• „Konfiguriere VLAN 10 VENTAS auf SW1 und setze die Ports 1-4 auf access"

Wenn etwas nicht auf der Zeichenfläche erscheint, bitte Claude, verificar_entorno() aufzurufen: Es sagt, welches der drei Teile ausgefallen ist und wie man es wieder hochfährt.

Struktur

Die beiden .js-Dateien in packet_tracer/ sind bereits in Builder.pts enthalten; sie liegen im Repo separat vor, um sie lesen, versionieren und bei Bedarf neu importieren zu können.

uv run python main.py funktioniert weiterhin, um die Bridge allein ohne MCP zu starten (das ist es, was diese Debug-Skripte benötigen).

Wie ein Befehl übertragen wird

1. Claude ruft ein MCP-Tool auf, das in eine Zeile PT-JavaScript übersetzt.

2. mcp_server.py stellt sie mit POST /add_command in die Warteschlange.

3. bridge.js, im Fenster Builder Code Editor, holt sie mit GET /next_command ab (alle 2 s) und ruft $se('runCodeBridge', codigo) auf.

4. bridge_runner.js führt sie in der Script-Engine aus und, wenn sie einen Wert zurückgibt, übergibt ihn der Seite mit evaluateJavaScriptAsync zurück.

5. Die Seite veröffentlicht ihn mit POST /command_result und mcp_server.py nimmt ihn entgegen.

Schritt 4 ist notwendig, weil $se() nur bestätigt, dass der Aufruf weitergeleitet wurde (löst zu true auf), aber niemals den Wert des ausgeführten Codes liefert.

Jede Anfrage reist in einer eindeutigen Markierung verpackt (a1b2c3d4|...) und nur das Ergebnis, das sie zurückbringt, wird akzeptiert. Ohne das bliebe eine verspätete Antwort in der Warteschlange und die nächste Anfrage würde die falsche Antwort abholen.

Bekannte Einschränkungen

• Packet Tracer gibt die Ausgabe der IOS-Befehle nicht preis: hacer_ping() und obtener_tabla_routing() senden den Befehl, aber seine Ausgabe ist nur in der Gerätekonsole innerhalb von PT sichtbar. API-Abfragen (getDevices(), Portstatus) liefern dagegen Daten.

• crear_dispositivo(), conectar_dispositivos(), agregar_modulo_router() und eliminar_conexion() bestätigen das tatsächliche Ergebnis ([OK] / [ERROR]). Die übrigen Schreibbefehle (IOS-Konfiguration) werden ohne Bestätigung in die Warteschlange gestellt: Exito: Comando enviado bedeutet in der Warteschlange, nicht ausgeführt.

• Beim Erstellen bestimmter Geräte fügt PT automatisch ein Power Distribution Device0 zur Zeichenfläche hinzu. Es erscheint in den Inventaren und ist kein Fehler.

• obtener_puertos_dispositivo() liest die tatsächlichen Ports des Geräts in PT, einschließlich derer der installierten Karten, und gibt an, welche frei sind.

• diagnosticar_red() sieht keine 802.1Q-Subinterfaces, VLANs oder Routing-Tabellen: Dass keine Fehler gemeldet werden, garantiert keine Konnektivität.

• Das Fenster Builder Code Editor muss geöffnet bleiben: Dort lebt die Schleife.