automateyournetwork/cml-node-operations
workspace/skills/cml-node-operations/SKILL.md
CML node operations — start, stop, console access, CLI execution, config management, node details. Use when starting or stopping a CML node, running show commands on a lab router, setting startup configs, or reading console logs.
$ install --global
skillsauthnpx skillsauth add automateyournetwork/netclaw cml-node-operationsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 20, 2026, 3:29 AM4.4s1 file scanned
SKILL.md
- name:
- cml-node-operations
- description:
- CML node operations — start, stop, console access, CLI execution, config management, node details. Use when starting or stopping a CML node, running show commands on a lab router, setting startup configs, or reading console logs.
- version:
- 1.0.0
- license:
- Apache-2.0
- tags:
- [cml, nodes, console, cli, config]
CML Node Operations
MCP Server
- Command:
cml-mcp(pip-installed, stdio transport) - Requires:
CML_URL,CML_USERNAME,CML_PASSWORDenvironment variables - Optional:
cml-mcp[pyats]for CLI execution via pyATS
Available Tools
Node Lifecycle
| Tool | Parameters | What It Does |
|------|-----------|-------------|
| start_node | lab_id/lab_title, node_id/node_label | Start (boot) a single node |
| stop_node | lab_id/lab_title, node_id/node_label | Stop (shutdown) a single node |
| get_node | lab_id/lab_title, node_id/node_label | Get node details: state, CPU, RAM, interfaces, config |
| get_nodes | lab_id/lab_title | List all nodes with their current states |
| wipe_node | lab_id/lab_title, node_id/node_label | Wipe a node's configuration (reset to default) |
Configuration Management
| Tool | Parameters | What It Does |
|------|-----------|-------------|
| set_node_config | lab_id/lab_title, node_id/node_label, config | Set a node's startup configuration |
| get_node_config | lab_id/lab_title, node_id/node_label | Get a node's current configuration |
| download_lab_configs | lab_id/lab_title | Download all node configs from a running lab |
Console & CLI Access
| Tool | Parameters | What It Does |
|------|-----------|-------------|
| get_node_console | lab_id/lab_title, node_id/node_label | Get console connection details (URL, protocol) |
| get_node_console_log | lab_id/lab_title, node_id/node_label, lines? | Retrieve console log output from a running node |
| execute_command | lab_id/lab_title, node_id/node_label, command | Execute a CLI command on a running node (requires pyATS) |
Node States
| State | Meaning |
|-------|---------|
| DEFINED_ON_CORE | Node exists but is not running |
| BOOTING | Node is in the process of booting |
| BOOTED | Node has finished booting and is reachable |
| STOPPED | Node has been shut down |
Workflow: Configure and Boot a Node
When a user wants to configure a specific node:
- Check node state:
get_nodeto see current state - Set startup config:
set_node_configwith the full configuration - Start the node:
start_nodeto boot it - Wait for boot: Nodes take 30-120 seconds depending on type
- Verify:
execute_commandto runshow versionorshow ip int brief - Report: Tell the user the node is ready
Workflow: Collect Running Configs
When a user wants to back up or review configs:
- Ensure lab is running:
get_labto check state - Download all configs:
download_lab_configsgets everything at once - Or target specific nodes:
get_node_configfor individual nodes - Optionally commit to GitHub: Use github-ops skill to commit configs to a repo
Workflow: Console Log Troubleshooting
When a user needs to see what happened during boot or troubleshoot a node:
- Check node state:
get_node— node must be BOOTED or BOOTING - Get console log:
get_node_console_logto retrieve recent console output - Analyze output: Look for error messages, boot failures, config errors
- Common issues to spot:
%PARSER-4-BADCFG— invalid configuration commands%LINK-3-UPDOWN— interface state changes%OSPF-5-ADJCHG— OSPF adjacency changes%BGP-5-ADJCHANGE— BGP neighbor state changes%SYS-5-RESTART— system restart messages- Boot failures, license errors, memory allocation errors
- Report: Summarize the console log findings
Workflow: Execute CLI Commands
When a user wants to run show commands or make live changes:
- Verify node is BOOTED:
get_nodeto check state - Execute command:
execute_commandwith the CLI command - Parse output: Present the results in a readable format
- Multiple commands: Run them sequentially, one
execute_commandper command
Common commands to execute:
show ip interface brief
show ip ospf neighbor
show ip bgp summary
show running-config
show cdp neighbor
show version
show ip route
show interfaces status
Workflow: Reset and Reconfigure
When a user wants to start fresh with a node:
- Stop the node:
stop_node - Wipe the config:
wipe_noderesets to factory default - Set new config:
set_node_configwith the new startup configuration - Start the node:
start_node - Verify: Execute show commands to confirm the new config took effect
Startup Configuration Templates
IOSv Router (Basic OSPF)
hostname {HOSTNAME}
!
interface Loopback0
ip address {LOOPBACK_IP} 255.255.255.255
!
interface GigabitEthernet0/0
ip address {MGMT_IP} {MASK}
no shutdown
!
interface GigabitEthernet0/1
ip address {P2P_IP} {MASK}
no shutdown
!
router ospf 1
router-id {LOOPBACK_IP}
network {LOOPBACK_IP} 0.0.0.0 area 0
network {P2P_NETWORK} {WILDCARD} area 0
!
line con 0
logging synchronous
line vty 0 4
login local
transport input ssh
!
end
IOSv Router (Basic BGP)
hostname {HOSTNAME}
!
interface Loopback0
ip address {LOOPBACK_IP} 255.255.255.255
!
interface GigabitEthernet0/1
ip address {PEER_IP} {MASK}
no shutdown
!
router bgp {LOCAL_AS}
bgp router-id {LOOPBACK_IP}
bgp log-neighbor-changes
neighbor {NEIGHBOR_IP} remote-as {REMOTE_AS}
!
address-family ipv4
network {LOOPBACK_IP} mask 255.255.255.255
neighbor {NEIGHBOR_IP} activate
exit-address-family
!
end
NX-OS Switch (Basic VXLAN Leaf)
hostname {HOSTNAME}
!
feature ospf
feature bgp
feature nv overlay
feature vn-segment-vlan-based
!
interface loopback0
ip address {LOOPBACK_IP}/32
!
interface Ethernet1/1
description To-Spine1
no switchport
ip address {P2P_IP}/30
no shutdown
!
router ospf 1
router-id {LOOPBACK_IP}
!
router bgp {AS}
router-id {LOOPBACK_IP}
neighbor {SPINE_IP} remote-as {AS}
update-source loopback0
address-family l2vpn evpn
send-community extended
!
end
IOS-XR Router (Basic IS-IS)
hostname {HOSTNAME}
!
interface Loopback0
ipv4 address {LOOPBACK_IP} 255.255.255.255
!
interface GigabitEthernet0/0/0/0
ipv4 address {P2P_IP} {MASK}
no shutdown
!
router isis CORE
is-type level-2-only
net 49.0001.{SYSTEM_ID}.00
address-family ipv4 unicast
metric-style wide
!
interface Loopback0
passive
address-family ipv4 unicast
!
!
interface GigabitEthernet0/0/0/0
address-family ipv4 unicast
!
!
!
end
Important Rules
- Check node state before operations — don't start an already-booted node or stop an already-stopped one
- Wait for boot — IOSv takes ~60s, NX-OS ~90s, IOS-XR ~120s to boot
execute_commandrequires pyATS — thecml-mcp[pyats]extra must be installed- Set configs BEFORE starting —
set_node_configsets the startup config; apply it before boot - Use labels not IDs — labels like "R1" are more human-readable than UUIDs
- Record in GAIT — log all configuration changes and CLI commands for audit trail
Environment Variables
CML_URL— CML server URLCML_USERNAME— CML usernameCML_PASSWORD— CML passwordCML_VERIFY_SSL— Verify SSL certificate (true/false)
Related Skills
automateyournetwork/humanrail-escalation
testing
VerifiedTrustedCommunity
Human-in-the-loop escalation via HumanRail — route low-confidence agent decisions, pre-destructive operation approvals, and ambiguous incident tickets to real human engineers. Human answers are verified and returned as structured output. Workers are paid via Lightning Network. Use when the agent is uncertain, when a destructive change needs explicit human sign-off beyond a ServiceNow CR, or when an ambiguous ticket requires human triage before automated handling.
491SKILL.mdUpdated May 12, 2026
automateyournetwork/eve-ng-node-operations
testing
VerifiedTrustedCommunity
Manage EVE-NG node lifecycle. Use when listing nodes, checking runtime state, creating or deleting nodes, starting or stopping nodes or whole labs, verifying node details, or wiping node NVRAM back to factory defaults.
491SKILL.mdUpdated May 12, 2026
automateyournetwork/eve-ng-lab-management
development
VerifiedTrustedCommunity
Manage EVE-NG labs and platform inventory. Use when listing labs, checking lab metadata, creating or deleting labs, importing or exporting lab archives, checking EVE-NG health or auth, or verifying available node images before build work.
491SKILL.mdUpdated May 12, 2026
automateyournetwork/eve-ng-console-ops
tools
VerifiedTrustedCommunity
Execute live CLI commands on running EVE-NG nodes over telnet console. Use when running show commands, making live config changes, verifying protocol state, testing connectivity, checking console readiness, or interacting with IOS, Junos, VPCS, EOS, or NX-OS nodes.
491SKILL.mdUpdated May 12, 2026