A terminal agent for Cisco Packet Tracer. Conversation on the left; on the right, the topology drawing itself from every tool the agent runs — not from anything it claims.
PACKETSMITH · PROVIDER KIMI/CODING · MODEL K3 · EFFORT HIGH 61 TOOLS
─────────────────────────────────────────────────────────────────────────────
AGENT │ [ TOPOLOGY ] ● BRIDGE UP
pt_full_build pt_verify_connectivity │ 14 NODES · 13 LINKS
│
A two-level star: the 3560 does the │ ◆ ROUTERS 1
core with SVIs per VLAN, and each │ ▣ SWITCHES 5
department hangs off its own 2960. │ ▪ HOSTS 8
│
Verified against the devices: │ ── FABRIC ──────────────
VLANs 10/20/30 all present │ ◆ R-EDGE
PC-VEN1 → SRV-WEB OK (4/4) │ └── ▣ SW-CORE
│ ├── ▣ SW-VENTAS
⏱ 2m40s · 34s in packet tracer (21%) │ │ ├── ▪ PC-VEN1
─────────────────────────────────────────────────────────────────────────────
○ READY · 1 TURN · 14 NODES CTX ░░░░ 4% 5H ███░ 23% 7D 51% Install
The binary carries its runtime inside — no Bun, no Node, no npm required on the machine.
npm
npm i -g packetsmith
bun
bun add -g packetsmith
macOS · Linux · WSL
curl -fsSL https://raw.githubusercontent.com/Mats2208/packetsmith/main/scripts/install.sh | sh
Windows
irm https://raw.githubusercontent.com/Mats2208/packetsmith/main/scripts/install.ps1 | iex
Then, once
packetsmith setup
Installs the MCP server, registers it, and fetches the Packet Tracer extension.
Run it with --dry-run to see the plan without touching anything.
Full install guide, including what to do when it does not work →
Why a terminal
A general coding agent in a chat window can drive the MCP server perfectly well. What it cannot do is show you the network.
Not what the model said it did. The topology is parsed from the raw result of every pt_* tool call, so a device the agent claims to have created but did not, simply does not appear.
A fabric tree answers what hangs off what. A canvas plan, drawn from Packet Tracer own x,y coordinates, answers how it is laid out. An uplink crossing the canvas is obvious in one and invisible in the other.
Context window, plan quota, and where the time actually went — split between time in Packet Tracer and time in the model. That last one is usually the answer to "why is this slow".
Model, effort, provider, theme, language. 13 palettes whose contrast is enforced by a failing test, not by good intentions.
Providers
PacketSmith runs its own agent loop, so it is not tied to one vendor. A provider is not an endpoint either — Kimi is one provider with two plans, and a key for one returns 401 against the other.
Claude
via the claude CLI — the only way to spend a Pro/Max subscription
Kimi
Code subscription or the metered Moonshot platform
OpenAI
ChatGPT Plus/Pro plan, or the API
Z.AI · GLM
GLM Coding Plan or the platform
DeepSeek · Groq · OpenRouter
metered
+ ~144 more
discovered from models.dev, not hand-written
Seven are verified end to end. The rest come from the models.dev catalog and have not been run — they are offered anyway, and if one fails there is an issue template that asks for the right things.
PacketSmith declares no tools of its own. It starts the MCP server, asks it what it can do, and its 61 tools arrive with their JSON Schema already attached. When the server adds a tool, it shows up on its own — nothing to sync.
Which also means: anything you can do here, you can do from Claude Code or Cursor. The difference is what you get to look at.