# Packet Tracer MCP

> Build, edit, inspect, troubleshoot, and verify Cisco Packet Tracer labs through the configured Mats2208 Packet Tracer MCP and MCP-BUILDER extension. Use for recreating network diagrams or photos, configuring routing, VLANs, DHCP, ACLs or port security, testing simulated connectivity, and saving real .pkt projects. Also use for diagnosing this MCP bridge. Not for configuring real network devices or unrelated MCP servers.

- Skill: `thesuperteacher/packet-tracer-mcp` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add thesuperteacher/packet-tracer-mcp`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thesuperteacher/packet-tracer-mcp/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Thesuperteacher (https://skillmd.com/u/thesuperteacher)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/thesuperteacher/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](references/local-setup.md) and use the bundled [stdio client](scripts/mcp_client.py). 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](references/api-and-verification.md) 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.