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. |
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
| 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