Packet Tracer MCP

Packet Tracer MCP

Use the live Packet Tracer workspace as the source of truth. A generated plan, accepted command, or exported configuration is not proof that the simulated network works.

Connect and inspect

1. Discover the currently available Packet Tracer tools and their schemas. Prefer the exposed MCP tools. Do not guess arguments from their names.
2. Call pt_bridge_status and pt_query_topology before modifying anything. pt_list_devices lists the model catalog, not the current topology.
3. If this task has no Packet Tracer tools, read local setup and use the bundled stdio client. Missing tools in an already-open task do not establish that registration failed.
4. For raw scripting, console commands, or service configuration, read API and verification first. Consult the installed Cisco IPC documentation for any unfamiliar method.

Build or edit a lab

1. Translate the user's request or diagram into devices, links, addressing, routing, services, and access rules. Separate visible facts from assumptions. Choose sensible private addressing when unspecified; ask only about ambiguity that materially changes the intended behavior.
2. Inspect model ports using pt_get_device_details(model_name=...). For example, ISR4331 uses GigabitEthernet0/0/0; a 2911 uses GigabitEthernet0/0. Check port capacity before selecting devices.
3. Preserve the current project before a requested replacement: save it to a separate .pkt path and verify that file exists. Only then create a new workspace. For edits, preserve a backup and change the necessary devices without rebuilding the whole lab.
4. Validate the plan before deployment. Apply dependent steps sequentially: devices and links, interfaces/VLANs, routing, services, access controls. Batch independent operations only when their individual results remain inspectable.
5. Allow realistic bridge timeouts (180 seconds normally; larger builds may need more). If a mutation times out, inspect the topology or configuration before retrying so that devices and links are not duplicated.
6. Read back actual configuration and host addresses. In server 0.9.0, the generated full-build workflow may assign a static fallback to the last host on each DHCP subnet. If every host must use DHCP, explicitly configure all DHCP clients and verify flags and leases.
7. Match security rules to the actual traffic path. Router ACLs cannot filter traffic switched within one subnet. Use a routed server VLAN when needed. IP-based host rules require predictable addresses and do not authenticate device identity.

Verify and deliver

• Check actual devices, ports, links and addresses. Packet Tracer may include an auxiliary Power Distribution Device in the inventory; distinguish it from planned logical devices.
• Verify routing neighbors and learned routes when dynamic routing is requested. Verify VLAN membership and trunks when relevant.
• Test representative end-to-end traffic. Record packet loss accurately; allow startup/ARP convergence and repeat only where that explains initial failures.
• For an ACL, test both an allowed and a denied source against the intended service, then inspect ACL counters. For web access, check returned page content; a successful request-start call or ping alone does not prove HTTP works.
• For DHCP, inspect real leases, masks, gateways and DHCP-enabled flags. For port security, inspect learned MACs, limits and violation mode. Do not claim failover, reboot persistence or an attack test unless actually tested.
• Save the completed .pkt to the task's deliverable folder and check the file. Export and visually inspect the logical diagram when useful. A JSON plan is not a substitute for a .pkt project.
• State the delivered file, major configured features, checks that passed and any material unverified behavior. Keep technical logs in the task's working folder.