Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
pt_statusA

Bridge + Packet Tracer status: connection, PT version, open file, device/link counts.

pt_setup_instructionsA

How to install the one-time PT-side bridge module (needed if pt_status says NOT CONNECTED).

pt_topologyA

Whole canvas, compact: every device (model, position, power) with its addressed/cabled interfaces, peers and link state. detail=true adds MACs, switchport modes, descriptions and unused ports.

pt_deviceB

One device in depth: all physical ports (IP, peer, state, switchport mode), free ports, module slots.

pt_running_configA

Running (or startup) config of an IOS device, read from the device model (fast, no paging). section: only blocks whose header contains this text, e.g. 'interface', 'router ospf', 'line vty'.

pt_showB

Run show/exec commands (privileged EXEC) on a router/switch and return their output. commands: one or more, e.g. ['show ip interface brief', 'show ip route']. grep: optional regex; keep only matching lines (like '| include').

pt_command_logC

Recent commands typed into any device CLI (PT's command log), oldest first.

pt_screenshotB

Image of the logical workspace (the topology as drawn in PT).

pt_add_devicesA

Add devices. devices: [{name, model, x?, y?}], model like '2911', 'ISR4331', '2960-24TT', '3560-24PS', 'PC-PT', 'Laptop-PT', 'Server-PT' (see pt_catalog). Missing x/y are laid out automatically. Routers/switches have their boot skipped so they are ready immediately.

pt_connectA

Cable devices. links: [{a, b, a_port?, b_port?, cable?}]. Ports are optional: the first free port of the right media is chosen (fastest first; on switches use a_pref/b_pref='access' to keep gigabit uplinks free). cable: auto (default) | straight | cross | serial | fiber | console | coaxial | phone. For serial links the device needs a serial module (pt_add_module).

pt_disconnectB

Remove cables by endpoint: ['R1:GigabitEthernet0/0', 'S1:FastEthernet0/3'].

pt_delete_devicesB

Delete devices (and their cables).

pt_clear_canvasA

Delete EVERY device on the canvas. Requires confirm=true.

pt_update_deviceC

Rename, move and/or power a device on/off.

pt_add_moduleA

Insert a module (device is power-cycled automatically). Common: HWIC-2T (2 serial, 1941/2901/2911), WIC-2T (1841/2811), NIM-2T (ISR4321/4331), HWIC-4ESW, NM-1FE-TX, PT-ROUTER-NM-1S (Router-PT), AC-POWER-SUPPLY (3650). slot omitted = first slot that accepts it. Returns the device's ports afterwards.

pt_device_modulesB

Module slot tree of a device: slot path, slot type and installed module.

pt_buildA

Build a whole network in one call. spec = { devices: [{name, model, x?, y?, modules?: [{module, slot?}]}], links: [{a, b, a_port?, b_port?, cable?}], # ports auto-picked when omitted configs: {device: ["ios line", ...]}, # global-config lines, applied + saved hosts: {pc: {ip, mask | cidr, gateway, dns} | {dhcp: true}}, auto: {routing: 'ospf'|'eigrp'|'rip'|'static'|'none', lan_pool, p2p_pool, dhcp, lan_prefix}, # optional checks: [[src, dst], ...] # ping pairs, run when verify=true } auto runs pt_auto_address after cabling, so addresses fit whatever ports were chosen.

pt_labB

Build a complete, pre-computed lab (devices, cabling, IPs, configs, hosts, test pairs) in one call. name='list' shows blueprints and their params: small-office, router-on-a-stick, intervlan-l3, routing (ospf|eigrp|rip|static x chain|ring|star|mesh, optional serial), nat-internet, hsrp, etherchannel-stp, ipv6-dual-stack. verify=true pings the test pairs after convergence.

pt_cliA

Run IOS commands on a router/switch/ASA. mode=config: lines are entered from global config (sub-modes like 'interface g0/0' work, 'end' is added); the reply lists only failing lines. mode=exec: privileged EXEC, returns output (prefer pt_show). save=true appends 'write memory'.

pt_configure_hostsB

IP settings for PCs/laptops/servers/printers. hosts: [{name, ip, mask? | ip:'10.0.0.5/24' | cidr, gateway?, dns?, dhcp?: true, port?, ipv6?: '2001:db8::5/64', gw6?}].

pt_apply_featureA

Generate IOS config for a feature (see ios_features) and apply it to a device in one step. e.g. feature='ospf', params={'networks':['10.0.0.0/30','192.168.1.0/24'],'router_id':'1.1.1.1', 'passive':['GigabitEthernet0/0']}. dry_run=true returns the lines without applying.

pt_auto_addressA

Address the live topology and generate routing, computed from the actual cabling: each L3 segment (router/host ports joined through switches) gets a subnet: LANs from lan_pool (/lan_prefix, or right-sized when null), router-only links get /30s from p2p_pool. Routers take the first host addresses (gateway), hosts .10+ (or DHCP pools on the router with dhcp=true). Existing addresses are kept unless overwrite=true. apply=false only shows the plan and configs.

pt_save_configsC

'write memory' on the given (default: all) routers/switches.

pt_pingA

Ping from devices and report OK/PARTIAL/FAIL per pair. pairs: [[src, dst], ...] where dst is a device name or IP. Sources can be PCs/servers (Command Prompt) or routers/switches (IOS ping). Pairs from different sources run in parallel. A first-ping loss is usually ARP warm-up: count>=2 hides it.

pt_ping_matrixB

All-pairs reachability between end hosts (default: every PC/laptop/server, max 10) as a matrix.

pt_tracerouteB

Traceroute (tracert on hosts) from a device to a device name or IP; returns the hop list.

pt_diagnoseA

Find misconfigurations from the live state: duplicate IPs, mixed subnets on a segment, hosts without IP / wrong or missing gateway, cabled-but-down interfaces, powered-off devices, uncabled hosts. deep=true also reads every router's routing table and lists subnets each router cannot reach.

pt_fast_forwardB

Fast-forward PT's realtime clock (speeds up STP, OSPF/EIGRP convergence, DHCP).

pt_simulationC

Simulation mode control. action: simulation|realtime (switch mode), pdu (simple ICMP PDU src->dst), forward/back (steps events), reset, frames (last events with status), status.

pt_fileA

Packet Tracer file operations on the open workspace: new, open , save, save_as (.pkt).

pkt_inspectA

Read a .pkt/.pka file WITHOUT Packet Tracer: devices, models, IPs, links, and (configs=true) every device's running-config. Good for grading or understanding a lab file.

pkt_convertB

Convert .pkt <-> .xml without Packet Tracer (decrypt to editable XML, or re-encrypt XML into a .pkt).

pkt_export_configsB

Write every device's running-config from a .pkt file to <out_dir>/.txt.

net_subnetB

Subnet facts for an address/prefix: network, mask, wildcard, broadcast, host range, count, class.

net_vlsmB

VLSM plan: needs = {'Sales': 50, 'Eng': 25, 'R1-R2': 2}. Largest first; returns subnet, mask, wildcard, gateway (first host), host range and broadcast per segment.

net_summarizeB

Route summarization: exact collapsed set and the single covering supernet (+ how much extra it covers).

net_splitA

Split a block into count equal subnets or into /new_prefix subnets (first 64 shown).

ios_featuresA

List IOS config generators and their parameters (used by ios_generate / pt_apply_feature).

ios_generateA

Generate IOS config lines for a feature without applying them. See ios_features for names/params. e.g. ('dhcp_pool', {'name':'LAN','network':'192.168.1.0/24','dns':'8.8.8.8','exclude_first':10}).

pt_catalogA

Device models PT 9 offers (exact names for pt_add_devices) with ports, slots and usage notes. category: router | switch | l3-switch | host | firewall | ap | wireless-router ... modules=true lists modules.

pt_api_lookupA

Search Packet Tracer's IPC/scripting API (6000+ methods, 374 classes) for use with pt_run_js. query: a class name ('TerminalLine'), a method fragment ('Vlan', 'ospf'), or 'Class.method'.

pt_run_jsA

Escape hatch: run JavaScript inside PT's script engine and return the JSON result. The code is a function body: use return. Globals: ipc (IPC root: ipc.network(), ipc.appWindow(), ipc.simulation()), PTM (this server's helpers: PTM.dev(name), PTM.snapshot(), PTM.cli(name, lines, mode)...). Example: return ipc.network().getDevice('R1').getPort('GigabitEthernet0/0').getMacAddress();

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.2/5.0

Scored across 42 tools

Disambiguation3/5

Several tools overlap by design: pt_show vs pt_cli (mode=exec) both run EXEC commands, pt_build vs pt_lab both construct whole topologies, and pt_apply_feature vs ios_generate vs pt_cli all produce/apply IOS config. The descriptions do provide guidance (e.g. 'prefer pt_show', dry_run on pt_apply_feature), so boundaries are workable but require careful reading.

Naming Consistency3/5

Names are snake_case throughout, but the surface mixes several prefix families (pt_, pkt_, net_, ios_) and verb styles, including bare nouns like pt_topology, pt_device and pt_status. The grouping is semantically meaningful but not a uniform verb_noun convention, so an agent must learn each family.

Tool Count2/5

42 tools is heavy for a Packet Tracer bridge, and much of the count comes from layered abstractions of the same jobs (build/lab/add_devices/connect vs pt_cli, pt_show vs pt_cli, ios_generate vs pt_apply_feature). The extra granularity is useful for power users but expands the selection space considerably.

Completeness5/5

The surface covers the full lifecycle: topology inspection, device/cable CRUD, modules, IOS and host configuration, auto-addressing and routing, verification (ping/traceroute/ping_matrix), file operations, offline .pkt inspection/conversion, subnet math, and a JS escape hatch. Very few obvious gaps remain for the stated Packet Tracer domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues