Cisco SD-WAN MCP Server

Cisco SD-WAN MCP Server

cisco-sdwan-mcp is an MCP server for Cisco Catalyst SD-WAN Manager (vManage), built with FastMCP.

It gives an LLM client a working view of your SD-WAN fabric — inventory, device health, control and data plane state, alarms, path quality, templates and policies — so you can ask "why is the Frankfurt branch down?" and get an answer backed by real controller data instead of a guess.

Read-only by default. The configuration-changing tools are not registered unless you explicitly enable them, and even then every call requires a human to approve it.

Contents

• What you get
• Quickstart
• Configuration
• Write protection
• Tool reference
• Prompts
• Resources
• Connecting an MCP client
• Transports
• Authenticating MCP clients
• Docker
• Deploying
• Adding your own tools
• Testing
• Troubleshooting
• Project structure

What you get

Plus four workflow prompts and three resources.

Three design decisions are worth knowing up front, because they shape every tool:

• Responses are projected, not dumped. A vManage device record carries 60+ fields; a 200-device fabric would bury a model's context. Each tool returns the fields that answer the question and accepts detailed=true when you want everything.
• Counts always accompany results. Every list reports count (what matched) alongside returned (what you got), so "3 devices are down" is never confused with "3 devices are down in the first 100 I looked at".
• Failures come back as answers. A wrong password, an unreachable controller or an unknown hostname returns a readable message — often with the valid options — rather than raising. The model can then correct itself or tell you exactly what to fix.

Quickstart

Prerequisites

• Python 3.11+
• uv (recommended) or pip
• A reachable Cisco Catalyst SD-WAN Manager (vManage) and an account on it

Make a dedicated vManage account. Give it a read-only role to start.

The account's privileges are the real security boundary — see

Write protection.

Install

From PyPI, if you only want to run it:

uvx cisco-sdwan-mcp        # no install, run it straight

pip install cisco-sdwan-mcp

From a checkout, if you want to change it:

git clone https://github.com/pcDamasceno/cisco-sdwan-mcp.git

cd cisco-sdwan-mcp

with uv (recommended)

uv sync --extra dev

with pip

pip install -e ".[dev]"

Configure

cp .env.example .env

The three settings you must fill in:

SDWAN_VMANAGE_URL=https://vmanage.example.com:8443

SDWAN_USERNAME=automation-readonly SDWAN_PASSWORD=...

The server reads .env from the repository root at startup — set SDWAN_ENV_FILE to load a different file. Variables already present in the environment (compose env_file, Kubernetes secrets) are never overwritten by it, and the startup log names the file it used.

Run

uv run python -m cisco_sdwan_mcp.server        # or: python -m cisco_sdwan_mcp.server

The server starts over HTTP on 0.0.0.0:8000. The MCP endpoint is at http://localhost:8000/mcp, a health probe at http://localhost:8000/healthz, and this README at http://localhost:8000/.

Startup logs confirm what it will talk to before any client connects:

INFO  cisco_sdwan_mcp.server: vManage controller: vmanage.example.com:8443 (user automation-readonly, TLS verify: True)

INFO cisco_sdwan_mcp.server: Write tools: disabled (read-only)

First call

Point an MCP client at it (see Connecting an MCP client) and ask for get_fabric_summary. It is one round trip and exercises authentication, TLS and reachability at once:

{

"total_devices": 42, "by_type": {"vedge": 38, "vsmart": 2, "vbond": 1, "vmanage": 1}, "by_reachability": {"reachable": 40, "unreachable": 2}, "unreachable_count": 2, "unreachable_devices": [{"host-name": "BR2-EDGE1", "system-ip": "10.0.0.12", "site-id": "1002"}] }

Configuration

Everything is environment-driven; .env.example is the annotated reference.

vManage connection

Server

SDWAN_USERNAME/SDWAN_PASSWORD authenticate this server to vManage.

MCP_AUTH governs how clients authenticate to this server. They are

unrelated, and you generally want both.

TLS

vManage very often presents a self-signed or private-CA certificate. In descending order of preference:

1. Point SDWAN_CA_BUNDLE at the controller's CA — verification stays on.
2. Add the CA to certificates/, which the Docker build installs into the container trust store automatically.
3. Only as a last resort, on a lab you control, set SDWAN_VERIFY_SSL=false. The server logs a warning naming the host each time it does this, because it means anything on the path can read the credentials.

Write protection

The tools that change configuration are gated twice.

Gate 1 — registration. With SDWAN_ENABLE_WRITES unset or false, the module holding them is never imported. They do not appear in the tool list, so a model cannot call them by mistake, misinterpretation or prompt injection. The server is read-only by construction, not by policy.

Gate 2 — confirmation. With writes enabled, each call still asks the user through MCP elicitation, naming the template or policy and the devices affected, before anything reaches vManage. Clients that do not implement elicitation cannot silently proceed — the call is refused unless the caller passes confirm=true, which puts the decision in a human's hands either way.

SDWAN_ENABLE_WRITES=true uv run python -m cisco_sdwan_mcp.server

WARNING cisco_sdwan_mcp.tools: SDWAN_ENABLE_WRITES=true — configuration-changing tools are registered.

Each one still requires explicit user confirmation before it runs.

The vManage account is the real boundary. SDWAN_ENABLE_WRITES controls

which tools exist in *this* server; it does nothing about what the account

can do through any other path. If a change must be impossible, use a

read-only vManage role — do not rely on this flag alone.

vManage applies configuration asynchronously: a write returns a task_id, meaning *accepted*, not *applied*. Poll get_task_status(task_id) until it reports done.

The intended flow for a template push, with a review step in the middle:

list_device_templates          → find the template

get_device_template → see what it configures and who has it get_template_input_variables → the exact per-device values (read-only preview) check_device_health → never push to an already-broken device attach_device_template → asks for approval, returns a task_id get_task_status → confirm it actually landed

And for a config-group fabric, where edits and deploys are separate steps:

get_device_config_group          → which group owns the device

get_feature_profile / get_parcel → find the parcel and its current values get_parcel_schema → which parcel a setting lives in, and its shape update_parcel → asks for approval; changes intent only get_device_running_config → snapshot before the push deploy_config_group → asks for approval, returns a task_id get_task_status → confirm it landed, then re-diff the running config

Tool reference

Every tool takes limit (cap on records) and most take detailed (return all vManage fields instead of the summary set).

Inventory

Device health

| get_interfaces(device, vpn_id, interface_name) | Interface status, addressing and e