pt-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PT_HOST | No | Packet Tracer IPC host. Optional; typically 127.0.0.1. | |
| PT_PORT | No | Packet Tracer IPC port. Optional; typically 39000. Packet Tracer may move to 39001+ if the port is busy. | |
| PT_APP_ID | No | Packet Tracer application ID. Optional; typically net.netacad.cisco.ptmcp. | |
| PT_APP_KEY | No | Packet Tracer application key from pt-mcp.env. Optional; if set, it must match the key in the registered .pta file. | |
| PT_MCP_ENABLE_RAW_IPC | No | Set to true to enable the opt-in raw call_ipc_api tool. Optional. | |
| PT_ALLOW_UNVERIFIED_IPC | No | Set to true to allow raw IPC calls to methods outside the verified allow-list when raw IPC is enabled. Optional. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_pt_informationA | Connect to Cisco Packet Tracer over IPC and report its version, the IPC API spec in use, device/link counts, workspace mode (logical/physical, realtime/simulation) and the open file. Call this first to confirm the connection works. Examples:
|
| get_devices_in_networkA | List every device in the active Packet Tracer network: name, IPC class, model, device type, power state and logical-workspace x/y position. Packet Tracer's auto-created power distribution device is hidden unless include_infrastructure=true. Examples:
|
| get_device_modelsA | List the device models Packet Tracer offers for a device type. Use one of these model strings with add_device_to_network. Examples:
|
| add_device_to_networkA | Add a device to the logical workspace. Returns the device's name (Packet Tracer assigns one such
as 'Router0'; it is renamed to Required: device_type (e.g. "router", "switch", "pc", "server"), model (e.g. "2911", "ISR4331", "2960-24TT", "PC-PT", "Server-PT" -- discover via get_device_models). Optional: x/y position, name. Examples:
|
| rename_deviceA | Change a device's display name (the name used by all other tools). This does not change the IOS hostname; use send_cli_command with "hostname X" for that. Examples:
|
| set_device_powerA | Power a device on or off. Powering off a Cisco device discards its unsaved running-config. Examples:
|
| delete_device_from_networkA | Delete a device and all of its links from the network. CRITICAL: Destructive and irreversible (the device's configuration is lost). Always ask "Confirm deletion of [device]?" and wait for the user's "yes" before invoking this tool. Examples:
|
| get_interfaces_for_deviceA | List a device's ports: name, IPC class, link/protocol state, MAC, IPv4 address/mask (host ports), and the remote port name if a cable is attached. Examples:
|
| configure_host_interfaceA | Set IPv4 settings on an end device's port (PC, laptop, server, printer...). Typical port names: 'FastEthernet0' (PC-PT), 'GigabitEthernet0'. For routers and switches use send_cli_command. subnet_mask defaults to 255.255.255.0 when ip_address is given. dhcp=true switches the port to DHCP. Examples:
|
| set_interface_powerA | Administratively enable or disable a port at the physical level (like plugging/unplugging the port's power in Packet Tracer). For IOS 'shutdown'/'no shutdown' use send_cli_command. Examples:
|
| connect_two_devicesA | Cable a port on one device to a port on another and return the cable type used. Both ports must exist and be free; use get_interfaces_for_device to find port names. cable="auto" (default) picks like Packet Tracer's GUI: serial for Serial ports, console for console ports, straight-through between a switch and a host/router, crossover between like devices. Examples:
|
| get_all_linksA | List every cable in the network as device/port pairs with the cable type. Examples:
|
| delete_linkA | Remove the cable attached to a device port. CRITICAL: Destructive. Always ask "Confirm removal of the link on [device] [port]?" and wait for the user's "yes" before invoking this tool. Examples:
|
| send_cli_commandA | Send IOS commands to a Cisco device (router, switch, multilayer switch, ASA, WLC...) and return each command's status and output. Works even before the device finishes booting (boot is skipped).
CRITICAL: Can modify device state. Review commands carefully before executing, especially when config_command=true. Examples:
|
| send_terminal_commandA | Type one command into a device's terminal and collect its output -- for PCs, laptops and servers this is the Desktop > Command Prompt ('ping 10.0.0.1', 'ipconfig /all', 'tracert 8.8.8.8', 'arp -a'). Output is collected until Packet Tracer reports the command ended or the timeout passes; pings in Realtime mode take a few seconds. Examples:
|
| verify_connectivityA | Ping each destination from a device (PC/server Command Prompt or a Cisco device) and report sent/received/ loss per destination. A destination that loses everything is retried (ARP resolution and STP on fresh switch links make the first ping fail). Raw output is included only for failures. The standard way to verify a CCNA lab end to end. Examples:
|
| get_console_logA | Return the device's console/terminal buffer as shown in its CLI tab (or the PC's Command Prompt): boot messages, %LINK/%LINEPROTO and other syslog messages, and recent command output. Examples:
|
| get_command_historyA | Return Packet Tracer's command log: commands typed into device terminals (by a person in the CLI tab, or by send_terminal_command/verify_connectivity; send_cli_command and configure_device are not logged), with time, device and prompt (so the mode is visible, e.g. "R1(config-if)#"). Great for reviewing how a lab was solved, spotting a typo, or building a study sheet of the commands used. Most recent last. Examples:
|
| get_device_configurationA | Return a Cisco device's running-config (default) or startup-config as text. Useful for reviewing a lab, comparing running vs startup ("did I save?"), or exporting a config to reuse. Examples:
|
| configure_deviceA | Apply a block of IOS configuration to a Cisco device, like pasting it into the CLI in global
config mode. Accepts output of Prefer this over send_cli_command for multi-line configs (VLANs, OSPF, ACLs, interface blocks). CRITICAL: Changes device configuration. Show the user the config and confirm before applying. Examples:
|
| save_device_configurationA | Save a Cisco device's running-config to startup-config ("write memory" / "copy run start") so it survives a reload or power cycle. Returns true when IOS reports [OK]. Examples:
|
| erase_device_configurationA | Erase a Cisco device's startup-config ("write erase") and, by default, reload it so it boots with a blank configuration -- the classic way to reset lab gear. Prompts are answered automatically (the running config is NOT saved before reload). CRITICAL: Destructive and irreversible. Always ask "Erase the configuration of [device]?" and wait for the user's "yes" before invoking this tool. Examples:
|
| get_device_model_detailsA | Show a device's expansion slots (installed module and its ports, or empty) and every module model it supports with Packet Tracer's description. Use before add_module_to_device. Examples:
|
| add_module_to_deviceA | Install a hardware module (e.g. HWIC-2T for two serial ports, NIM-2T on ISR4000s, HWIC-4ESW, SFPs) into a free slot. The device is powered off for the change and powered back on, so an unsaved running-config on it is lost -- save first if needed. Returns the new port names (e.g. ["Serial0/0/0", "Serial0/0/1"]). Examples:
|
| remove_module_from_deviceA | Remove the module in a slot. The device is power-cycled; cables on the module's ports are removed. CRITICAL: Destructive. Confirm with the user ("Remove the module in [slot] of [device]?") first. Examples:
|
| create_full_network_topologyA | Build a whole network in one call into the open Packet Tracer file (existing devices are kept). Same format export_network_topology returns, so exports can be rebuilt. Steps run in order: devices (+modules), links, host IP settings, then IOS configs; errors are collected, not fatal. Format: { "description": "OSPF lab", "devices": [ {"name": "R1", "device_type": "router", "model": "2911", "x": 100, "y": 100, "modules": [{"slot": "0/0", "module": "HWIC-2T"}], "config": "hostname R1\ninterface Gi0/0\n ip address 192.168.1.1 255.255.255.0\n no shutdown"}, {"name": "SW1", "device_type": "switch", "model": "2960-24TT", "x": 300, "y": 100}, {"name": "PC1", "device_type": "pc", "model": "PC-PT", "x": 500, "y": 100} ], "links": [{"device_a": "R1", "port_a": "GigabitEthernet0/0", "device_b": "SW1", "port_b": "GigabitEthernet0/1"}, {"device_a": "PC1", "port_a": "FastEthernet0", "device_b": "SW1", "port_b": "FastEthernet0/1"}], "hosts": [{"name": "PC1", "port": "FastEthernet0", "ip_address": "192.168.1.10", "subnet_mask": "255.255.255.0", "default_gateway": "192.168.1.1"}] } Use full port names. cable defaults to "auto". Discover models with get_device_models and modules with get_device_model_details. Examples:
|
| export_network_topologyA | Export the open network as a topology object: devices (type, model, position, installed modules, running-config), links, and host IPv4 settings. The result can be fed back to create_full_network_topology, saved as a study reference, or reviewed for mistakes. Examples:
|
| set_network_descriptionA | Set the network file's description (shown in Packet Tracer under File > Network description / Info). Handy for lab notes, objectives, or an IP addressing table. Examples:
|
| get_annotationsA | List the notes and drawn shapes on the logical workspace with their ids, positions and note text. Examples:
|
| add_text_noteA | Place a text note on the logical workspace (the "Place Note" tool) -- e.g. subnet labels, "VLAN 10 - Sales", an addressing table, or lab instructions. Returns the note's id. Examples:
|
| add_line_annotationA | Draw a line on the logical workspace, e.g. to separate sites, mark a WAN boundary, or underline a label. Returns the line's id. Examples:
|
| add_circle_annotationA | Draw a circle on the logical workspace, e.g. to group a LAN, mark a broadcast or collision domain, or highlight an OSPF area. Returns the circle's id (get_annotations lists circles as kind "ellipse"). Examples:
|
| edit_text_noteB | Replace the text of an existing note. Examples:
|
| delete_annotationA | Delete a note or drawn shape from the workspace. CRITICAL: Destructive. Confirm with the user before deleting. Examples:
|
| set_simulation_modeA | Switch Packet Tracer between Simulation mode (enabled=true: time advances only when stepped, every packet is recorded) and Realtime mode (enabled=false). Returns the resulting mode. Switching back to Realtime clears the event list, so read events/details first. Examples:
|
| send_simple_pduA | Create a Simple PDU (the envelope tool: an ICMP echo) from one device to another. In Simulation mode, step_simulation then moves it hop by hop and get_simulation_events shows where it went -- including any ARP it triggers. Returns the PDU's index in the user-created PDU list. Examples:
|
| step_simulationA | Advance (or rewind) Simulation mode by N steps, like clicking Capture/Forward. Returns the simulation time, total event count and how many new events were recorded. Examples:
|
| get_simulation_eventsA | List Simulation-mode events (the Event List): time, the device the PDU is at, where it came from, protocol, and what happened (sent, accepted, dropped, buffered...). Examples:
|
| get_simulation_event_detailsA | Explain one Simulation-mode event the way Packet Tracer's PDU Information window does: the device's OSI-layer decisions in plain English ("The frame destination MAC address is not in the MAC table. The Switch floods the frame...") plus the inbound and outbound headers decoded field by field (Ethernet, 802.1Q, IP, ICMP, ARP, TCP/UDP, STP, OSPF, DHCP, ...). Great for learning why a packet was forwarded or dropped. Examples:
|
| reset_simulationA | Clear the Simulation-mode event list and restart simulation time (Reset Simulation). Device configurations are not changed. Examples:
|
| get_activity_instructionsA | If the open file is a Packet Tracer activity (.pka, e.g. a NetAcad CCNA lab), return its instruction pages as plain text: objectives, addressing table, and the tasks to complete. This server cannot read an activity's answers, score or completion percentage (it does not hold Packet Tracer's ACTIVITY_WIZARD privilege). Use Check Results in Packet Tracer for grading. When helping a student, prefer explaining concepts and hinting over doing the graded tasks for them. Examples:
|
| create_new_networkA | Close the current network and start a new, empty one without a save prompt. CRITICAL: Unsaved changes to the current network are lost. Always ask "Discard the current network?" (or offer save_network_file first) and wait for the user's "yes" before invoking this tool. Examples:
|
| open_network_fileA | Open a .pkt (network) or .pka (activity) file. Returns Packet Tracer's result code. CRITICAL: Replaces the open network; unsaved changes may be lost. Confirm with the user first. Examples:
|
| save_network_fileA | Save the current network as a .pkt file at an absolute path, without a dialog. Overwrites an existing file at that path. Returns the saved path. Examples:
|
| describe_ipc_classA | Show an IPC class's inheritance and method signatures, (param types) -> return type plus the ExApp privilege each needs. Use with call_ipc_api. Examples:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 45 tools
Most tools have clearly distinct resource/action targets, especially around devices, links, annotations, files, and simulation. A few boundaries overlap slightly: send_cli_command, configure_device, and send_terminal_command all send commands, though the descriptions explain when to use each.
All tool names use consistent snake_case verb_noun phrasing such as get_devices_in_network, add_device_to_network, delete_link, and set_simulation_mode. Variants like get_interfaces_for_device and get_device_model_details are still predictable and readable.
The 45-tool surface is very large for an MCP server and exceeds the expected range even for a broad Packet Tracer automation domain. While many tools are justified, the set could likely be consolidated into fewer higher-level operations.
Coverage is strong across topology building, device configuration, interfaces, links, modules, annotations, files, and simulation workflows. Minor gaps remain, such as repositioning existing devices or reading back some workspace metadata like the network description, but core lifecycles are well covered.