Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PT_HOSTNoPacket Tracer IPC host. Optional; typically 127.0.0.1.
PT_PORTNoPacket Tracer IPC port. Optional; typically 39000. Packet Tracer may move to 39001+ if the port is busy.
PT_APP_IDNoPacket Tracer application ID. Optional; typically net.netacad.cisco.ptmcp.
PT_APP_KEYNoPacket Tracer application key from pt-mcp.env. Optional; if set, it must match the key in the registered .pta file.
PT_MCP_ENABLE_RAW_IPCNoSet to true to enable the opt-in raw call_ipc_api tool. Optional.
PT_ALLOW_UNVERIFIED_IPCNoSet 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

CapabilityDetails
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

NameDescription
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:

  • "Is Packet Tracer connected?"

  • "What version of Packet Tracer is running?"

  • "How many devices are in my network?"

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:

  • "What devices are in my Packet Tracer network?"

  • "List all routers and switches"

  • "Show me the topology"

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:

  • "Which router models can I add?"

  • "List the available switch models"

  • "What PC models does Packet Tracer have?"

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 name if given).

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:

  • "Add a 2911 router called R1"

  • "Put a 2960 switch at 300,200"

  • "Add two PCs to the network"

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:

  • "Rename Router0 to R1"

  • "Call PC0 'Accounting-PC'"

set_device_powerA

Power a device on or off. Powering off a Cisco device discards its unsaved running-config.

Examples:

  • "Turn off R1"

  • "Power on all the switches"

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:

  • "Delete R2"

  • "Remove the extra switch"

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:

  • "What interfaces does R1 have?"

  • "Which ports on the switch are connected?"

  • "Show PC0's IP address"

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:

  • "Give PC0 192.168.1.10/24 with gateway 192.168.1.1"

  • "Set the server's DNS to 8.8.8.8"

  • "Put PC1 on DHCP"

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:

  • "Disable PC0's FastEthernet0"

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:

  • "Connect R1 Gi0/0 to SW1 Gi0/1"

  • "Cable PC0 FastEthernet0 to the switch's Fa0/1"

  • "Add a serial link between R1 Serial0/1/0 and R2 Serial0/1/0"

get_all_linksA

List every cable in the network as device/port pairs with the cable type.

Examples:

  • "Show all the links"

  • "What is R1 connected to?"

  • "Map the topology connections"

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:

  • "Disconnect R1 Gi0/0"

  • "Remove the cable between PC0 and the switch"

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).

  • Separate multiple commands with newlines.

  • config_command=false (default): privileged exec mode (e.g. "show ip interface brief").

  • config_command=true: configuration mode -- DO NOT include "enable", "configure terminal" or "end". Sub-modes carry over, so "interface Gi0/0\nip address 10.0.0.1 255.255.255.0\nno shutdown" works.

  • status is "invalid"/"incomplete"/"ambiguous" when IOS rejected a command.

CRITICAL: Can modify device state. Review commands carefully before executing, especially when config_command=true.

Examples:

  • "Run 'show ip route' on R1"

  • "Configure Gi0/0 on R1 with 10.0.0.1/24 and bring it up"

  • "Show the running config of SW1"

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:

  • "Ping 192.168.1.1 from PC0"

  • "Run ipconfig on the laptop"

  • "Traceroute from PC1 to the server"

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:

  • "Can PC1 reach its gateway, the server and the other LAN?"

  • "Verify connectivity from PC1 to 192.168.1.1, 192.168.2.10 and 8.8.8.8"

  • "Is my static routing working?"

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:

  • "Show R1's console messages"

  • "Did any interface go down on the switch?"

  • "What happened on PC1's command prompt?"

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:

  • "What commands did I type on R1?"

  • "Make me a cheat sheet from the commands I used in this lab"

  • "Which command did I mistype?"

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:

  • "Show me R1's running config"

  • "Is SW1's startup config the same as its running config?"

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 show running-config as-is: "!" lines, "end", "enable", "configure terminal", "version", and prompt lines are skipped. Indentation does not matter. Returns how many commands were sent and only the ones IOS rejected. save=true runs "write memory" afterwards.

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:

  • "Configure OSPF area 0 on R1 for 10.0.0.0/8"

  • "Apply this config to SW1 and save it"

  • "Create VLANs 10 and 20 on the switch and assign Fa0/1-12 to VLAN 10"

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:

  • "Save R1's config"

  • "Make sure all my changes on SW1 survive a reload"

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:

  • "Wipe R1's configuration"

  • "Reset the switch to factory defaults"

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:

  • "What modules can I add to R1?"

  • "Which slots on the 2911 are free?"

  • "Does this router have serial interfaces?"

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:

  • "Add a serial card to R1 so I can do a WAN link"

  • "Put an HWIC-2T in slot 0/0 of R2"

  • "Add a NIM-2T to the ISR4331"

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:

  • "Take the serial card out of R1 slot 0/0"

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:

  • "Build a 3-router OSPF lab with a LAN behind each router"

  • "Recreate the topology I exported earlier"

  • "Set up a router-on-a-stick lab with two VLANs"

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:

  • "Export my lab"

  • "Give me a summary of everything in this network including configs"

  • "Back up this topology as JSON"

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:

  • "Describe this lab as 'CCNA 2 - OSPF single area practice'"

  • "Put the addressing table in the network description"

get_annotationsA

List the notes and drawn shapes on the logical workspace with their ids, positions and note text.

Examples:

  • "What notes are on my topology?"

  • "Find the label that says 'LAN A'"

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:

  • "Label the LAN behind R1 as 192.168.1.0/24"

  • "Add a note with the lab objectives at the top"

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:

  • "Draw a red line between the HQ and branch halves of the topology"

  • "Underline the title note"

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:

  • "Circle the devices in VLAN 10"

  • "Mark each broadcast domain with a circle"

edit_text_noteB

Replace the text of an existing note.

Examples:

  • "Change the R1 LAN label to 10.1.1.0/24"

delete_annotationA

Delete a note or drawn shape from the workspace.

CRITICAL: Destructive. Confirm with the user before deleting.

Examples:

  • "Remove the old 'TODO' note"

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:

  • "Switch to simulation mode so I can watch the ping"

  • "Go back to realtime"

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:

  • "Send a ping PDU from PC1 to the server and watch it"

  • "Show me how ARP works between PC1 and R1"

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:

  • "Step the simulation forward 5 times"

  • "Go back one step"

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:

  • "Where did the ping go?"

  • "Show only the ARP events"

  • "Did any packet get dropped?"

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:

  • "Why was event 2 dropped?"

  • "What does the switch do with the frame at event 1?"

  • "Show me the IP and Ethernet headers of the ping"

reset_simulationA

Clear the Simulation-mode event list and restart simulation time (Reset Simulation). Device configurations are not changed.

Examples:

  • "Clear the event list"

  • "Start the simulation over"

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:

  • "What does this activity ask me to do?"

  • "Read me the addressing table from the instructions"

  • "Explain task 3 of this lab"

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:

  • "Start a fresh topology"

  • "Clear the workspace"

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:

  • "Open ~/labs/ospf.pkt"

  • "Load the activity file I downloaded"

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:

  • "Save this topology to ~/labs/campus.pkt"

  • "Back up the network"

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:

  • "What methods does a Router have for OSPF?" -> class_name="OspfProcess"

  • "How do I read a port's MAC address?" -> class_name="Port", name_filter="mac"

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 45 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues