AI Network Labs 02 — The 18 Tools and the Build Loop
Every tool cisco-pt-mcp exposes, grouped by job, plus the plan → build → configure → verify → inspect loop and a prompt template that keeps you in charge.
cisco-pt-mcp exposes 18 small tools. None of them "builds a network" on its own — the AI composes them. Knowing the verbs lets you read a session like a transcript of what an engineer would have clicked.
The tool surface
| Group | Tool | What it does |
|---|---|---|
| Topology | addDevice | Adds a router, switch or PC to the canvas |
addModule | Installs an interface module into a device slot | |
addLink | Connects two devices with a cable | |
removeDevice, removeLink | Deletes devices or cables | |
renameDevice, moveDevice | Renames or repositions a device | |
| Device control | setPower | Powers a device on or off |
configurePcIp | Sets IP, mask, gateway, DNS — or DHCP — on a PC | |
configureIosDevice | Runs IOS CLI commands on a router or switch | |
| Inspection | getNetwork | Snapshot of devices, interfaces and cables |
getDeviceInfo | Detailed view of one device | |
getCommandLog | The IOS command history Packet Tracer recorded | |
| Simulation | setSimulationMode | Switches between realtime and simulation |
getSimulationStatus | Simulation state and frame count | |
stepSimulation | Steps forward or back, or resets | |
sendPdu | Adds an ICMP ping PDU between two devices | |
getPduResults | Reads PDU outcomes after stepping |
Notice there is no "makeItWork" tool. Verification is explicit: a topology is only done when sendPdu + getPduResults say a ping crossed it.
The build loop
Every lab in this course follows the same five beats. Put them in your prompt and the AI follows them too.
1. PLAN — write the addressing table and device list (you, before prompting)
2. BUILD — addDevice / addModule / addLink
3. CONFIGURE— configureIosDevice on routers & switches, configurePcIp on PCs
4. VERIFY — sendPdu → stepSimulation → getPduResults
5. INSPECT — on failure: getNetwork, getDeviceInfo, getCommandLog, then fixA prompt template that works
Goal: <one sentence>.
Devices: <models and names>.
Addressing: <table or rules>.
Rules:
- Show me the IOS commands before you run configureIosDevice.
- After configuring, prove reachability with sendPdu between <A> and <B>
and report getPduResults.
- If a ping fails, use getNetwork/getDeviceInfo to find the cause before changing anything.Three habits make the difference:
- Name every device. "R1", "SW-Sales" and "PC-A" are far easier to reason about than "Router0".
- Give the addressing, don't ask for it. Addressing is the part you are learning; let the AI do the typing.
- Ask for the commands first. Reviewing IOS before it runs turns every session into a revision exercise.
Reading the result
After a build, getCommandLog is your answer key. Copy it into your lab notes — it's the exact configuration the AI applied, line by line, and the closest thing to a show running-config diff you get for free.
Models occasionally use commands from the wrong platform (for example NX-OS syntax on IOS). Packet Tracer rejects them with % Invalid input detected. That's not a failure of the lab — it's a chance to explain why the command is wrong.
ExerciseKnowledge check
Which pair of tools proves a topology actually works?
Finished this one?
Progress is saved in this browser.
