cml-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CML_HOST | No | CML controller host (e.g., cml.example.com). Overrides config file if set. | |
| CML_PASSWORD | No | CML API password. Overrides config file if set. | |
| CML_USERNAME | No | CML API username. Overrides config file if set. | |
| CML_VERIFY_SSL | No | SSL verification setting. Accepts true/false or a path to a CA bundle. Defaults to false. | false |
| CML_CONFIG_PATH | No | Path to an explicit TOML config file. If not set, searches for cml-config.toml in project root, then ~/.config/cml-mcp-server/config.toml. |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_labsA | List CML labs. By default only labs owned by the authenticated user; set show_all=True for every lab on the controller (needs admin rights). |
| get_lab_topologyA | Get full topology detail for a lab: its nodes, links, and their state. |
| create_labB | Create a new, empty lab. Use add_node/add_link or build_topology to populate it. |
| delete_labC | Permanently delete a lab and everything in it. This cannot be undone. |
| start_labB | Start (boot) every node in a lab. |
| stop_labC | Stop every node in a lab. |
| wipe_labA | Wipe every node's disks back to initial state. Startup (day-0) configuration set via set_node_config is preserved; runtime/learned state is discarded. The lab must be stopped first. |
| list_node_definitionsA | List platform/node types available on this controller (e.g. iosv,
iosvl2, csr1000v, nxosv, asav, alpine, unmanaged_switch, external_connector).
Use the returned 'id' as |
| add_nodeA | Add a node to an existing lab. node_definition: a platform id from list_node_definitions(), e.g. 'iosv', 'iosvl2', 'alpine', 'unmanaged_switch'. configuration: day-0 startup config text (e.g. a full IOS config), applied on first boot. |
| remove_nodeA | Remove a node, and any links/interfaces attached to it, from a lab. |
| start_nodeC | Start (boot) a single node. |
| stop_nodeC | Stop a single node. |
| get_node_configA | Get the stored day-0 startup configuration text for a node. |
| set_node_configA | Set a node's day-0 startup configuration text. Takes effect the next time the node is (wiped and) started. To capture a running node's current config instead, use extract_node_config. |
| extract_node_configA | Pull the current running configuration off a booted, converged node and return it. Requires the node to be started. |
| get_node_console_logB | Get console output captured for a node (console_id 0 is the main
console on most platforms). Optionally limit to the last |
| add_linkA | Connect two nodes with a link. If iface_a/iface_b (interface labels, e.g. 'GigabitEthernet0/1') are omitted, the next free interface on each node is used, creating one if needed. |
| remove_linkC | Remove a link between two nodes. |
| build_topologyA | Create a whole lab - nodes, links, and configs - in one call. Use this when you already have a topology design in mind (e.g. from list_example_topologies, or one you designed yourself from the user's description) rather than calling create_lab/add_node/add_link repeatedly. nodes: [{id, label, node_definition, x?, y?, image_definition?,
configuration?, cpus?, ram?}, ...]
Returns the new lab's id plus a map from each local node id to its real CML node id, so you can immediately call add_node/add_link/set_node_config etc. against the result. |
| list_example_topologiesA | List built-in example network architectures (e.g. OSPF/BGP routing labs, a three-tier campus, a leaf-spine data center fabric, a zone-based firewall with a DMZ) that can be deployed directly with deploy_example_topology, or fetched with get_example_topology and customized before calling build_topology. |
| get_example_topologyA | Get the full node/link spec for a named example topology (from list_example_topologies), so it can be inspected or edited before building - e.g. to change addressing, swap node_definitions for platform-specific images, or add nodes - then passed to build_topology. |
| deploy_example_topologyA | Build one of the built-in example topologies (see list_example_topologies) as a new lab, unmodified. For customization, use get_example_topology + build_topology instead. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jonathanLynn/ciscocml-mcpserver'
If you have feedback or need assistance with the MCP directory API, please join our Discord server