Cisco SD-WAN MCP Server
Provides tools for managing Cisco SD-WAN devices, templates, policies, monitoring, reports, and software upgrades through vManage APIs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Cisco SD-WAN MCP Servershow me the current alarms"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SD-WAN MCP Server
A FastMCP-based Model Context Protocol server for Cisco SD-WAN vManage automation
This package provides a modern FastMCP-based server for managing Cisco SD-WAN through vManage APIs, enabling AI assistants like Claude to automate SD-WAN operations through natural language.
β¨ Features
π₯οΈ Device Management
List all SD-WAN devices with status
Get detailed device information and statistics
Monitor interface statistics and health
View control connections, BFD sessions, and OMP peers
Track CPU, memory, and system status
π Template Management
List and browse device/feature templates
Create new feature and device templates
Update existing templates with validation
Deploy templates to single or multiple devices
Preview template configurations before deployment
Get template input requirements and variables
Detach templates from devices
π Monitoring & Health
Real-time alarms and events
System-wide and per-device statistics
Interface health and performance metrics
Device health monitoring (CPU, memory, connectivity)
BFD session status and control connections
DPI (Deep Packet Inspection) statistics
Application usage and threat reports
Network-wide connection statistics
π Policy Management
Centralized and localized policy management
Access control lists (ACLs) and prefix lists
QoS maps and class maps
Security policies and firewall rules
SLA class definitions
Route policies and redistribution
Application-aware policies
Site, VPN, and application lists
π¦ Software Management
List available software images
Schedule software upgrades
Track upgrade status and progress
Automated pre-upgrade validation
π Reports & Analytics
Comprehensive device reports (summary, detailed, health)
Interface utilization reports
Transport statistics and path analysis
Security threat reports
Application usage analytics
Custom time-based reporting
π‘οΈ Safety & Validation
Confirmation Required: All destructive operations require explicit confirmation
Pre-execution Validation: Checks device connectivity, template compatibility, dependencies
Rate Limiting: Prevents rapid-fire operations (configurable cooldowns)
Auto-backup: Optional automatic backups before deployments/upgrades
Operation Audit Log: Track all destructive operations with timestamps
SSL Verification: Configurable for self-signed certificates
π Performance & Architecture
FastMCP Framework: Modern, efficient MCP implementation
Async/Await: Non-blocking I/O for high performance
Connection Pooling: Reusable HTTP connections to vManage
Smart Caching: Optional caching for frequently accessed data
UV Package Manager: Fast, reliable dependency management
Related MCP server: Cisco Meraki MCP Server
π¦ Installation
Quick Start
# Clone the repository
git clone https://github.com/limtsi/sdwan_mcp.git
cd sdwan_mcp
# Install UV (if not already installed)
curl -LsSf https://astral.sh/uv/install.sh | sh
# Install dependencies and create .venv automatically
uv sync
# Configure credentials
cp config.yaml.example config.yaml
# Edit config.yaml with your vManage details
# Run the server
python sdwan_fastmcp.pyDetailed Installation
For comprehensive installation instructions, including troubleshooting and Claude Desktop integration, see:
About UV
This project uses UV for fast, modern Python package management:
uv syncautomatically creates.venvand installs all dependencies frompyproject.toml10-100x faster than pip for dependency resolution
Automatic virtual environment management (no manual activation needed)
PEP 621 compliant with
pyproject.toml
Running the server:
Simple:
python sdwan_fastmcp.py(UV manages .venv automatically)Alternative:
uv run python sdwan_fastmcp.py(explicit UV environment)
Both methods work equally well!
βοΈ Configuration
Configure vManage access using either:
1. Environment Variables:
export VMANAGE_URL=https://10.78.54.101
export VMANAGE_USER=admin
export VMANAGE_PASS=your_password2. Configuration File (config.yaml):
vmanage:
url: https://10.78.54.101
username: admin
password: your_password
verify_ssl: falseπ Usage
1. Run as FastMCP server (recommended)
Simply run from the project directory:
python3 sdwan_fastmcp.pyOr use the virtual environment directly:
.venv/bin/python sdwan_fastmcp.pyNote: The .venv environment is managed by UV (via uv sync), but you run the server with standard Python commands.
2. Integrate with Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
macOS/Linux (Recommended):
{
"mcpServers": {
"sdwan": {
"command": "/Applications/MCP/sdwan/.venv/bin/python",
"args": ["/Applications/MCP/sdwan/sdwan_fastmcp.py"],
"env": {
"VMANAGE_URL": "https://10.78.54.101",
"VMANAGE_USER": "admin",
"VMANAGE_PASS": "your_password"
}
}
}
}Windows:
{
"mcpServers": {
"sdwan": {
"command": "C:/path/to/sdwan/.venv/Scripts/python.exe",
"args": ["C:/path/to/sdwan/sdwan_fastmcp.py"],
"env": {
"VMANAGE_URL": "https://10.78.54.101",
"VMANAGE_USER": "admin",
"VMANAGE_PASS": "your_password"
}
}
}
}Important: Use the direct path to .venv/bin/python (or .venv/Scripts/python.exe on Windows) for the most reliable configuration. Replace paths with your actual installation directory.
3. Use from Code
from sdwan_tools import SDWANTools
# Initialize tools
tools = SDWANTools()
# Get all devices
devices = await tools.handle_call("sdwan_get_devices", {})
# Deploy a template (with confirmation)
result = await tools.handle_call("sdwan_deploy_template", {
"template_id": "template-123",
"device_ids": ["device-456"],
"confirm": True
})π οΈ Available Tools
The server provides 50+ tools organized by category:
Device Management
sdwan_get_devices- List all devicessdwan_get_device_status- Get device statussdwan_get_device_stats- Get device statisticssdwan_get_device_health- Comprehensive health metricssdwan_get_device_bfd_sessions- BFD session infosdwan_get_device_control_connections- Control connectionssdwan_get_device_omp_peers- OMP peer informationsdwan_get_device_cpu_usage- CPU utilizationsdwan_get_device_memory_usage- Memory utilizationsdwan_get_device_system_status- Overall system status
Template Management
sdwan_get_templates- List all templatessdwan_get_template_details- Template detailssdwan_create_feature_template- Create feature template β οΈsdwan_create_device_template- Create device template β οΈsdwan_update_feature_template- Update feature template β οΈsdwan_update_device_template- Update device template β οΈsdwan_delete_feature_template- Delete feature template β οΈsdwan_delete_device_template- Delete device template β οΈsdwan_deploy_template- Deploy to devices β οΈsdwan_detach_template- Detach from devices β οΈsdwan_get_template_preview- Preview configurationsdwan_get_template_inputs- Get required inputs
Monitoring & Alarms
sdwan_get_alarms- Get active alarmssdwan_get_events- Get system eventssdwan_get_interface_stats- Interface statisticssdwan_get_network_stats- Network-wide statisticssdwan_get_dpi_statistics- DPI statisticssdwan_get_connection_statistics- Connection stats
Reports
sdwan_get_device_report- Comprehensive device reportsdwan_get_interface_report- Interface reportsdwan_get_transport_report- Transport statisticssdwan_get_security_report- Security reportsdwan_get_app_usage_report- Application usagesdwan_get_threat_report- Threat analysis
Software Management
sdwan_get_software_images- List available imagessdwan_schedule_upgrade- Schedule upgrade β οΈsdwan_get_upgrade_status- Upgrade status
Policy Management
sdwan_get_centralized_policies- List centralized policiessdwan_get_localized_policies- List localized policiessdwan_create_centralized_policy- Create policy β οΈsdwan_update_centralized_policy- Update policy β οΈsdwan_delete_centralized_policy- Delete policy β οΈsdwan_activate_centralized_policy- Activate policy β οΈsdwan_deactivate_centralized_policy- Deactivate policy β οΈAnd 20+ more policy-related tools...
Generic API
sdwan_api_call- Make custom vManage API calls
β οΈ = Requires confirmation (confirm: true)
π Example Usage
Get All Devices
{
"name": "call_sdwan_tool",
"arguments": {
"tool_name": "sdwan_get_devices",
"arguments": {}
}
}Deploy Template to Devices
{
"name": "call_sdwan_tool",
"arguments": {
"tool_name": "sdwan_deploy_template",
"arguments": {
"template_id": "abc-123",
"device_ids": ["device-1", "device-2"],
"parameters": {
"system_ip": "10.1.1.1",
"hostname": "edge-router-01"
},
"confirm": true
}
}
}Get Device Health
{
"name": "call_sdwan_tool",
"arguments": {
"tool_name": "sdwan_get_device_health",
"arguments": {
"device_id": "device-123"
}
}
}Schedule Software Upgrade
{
"name": "call_sdwan_tool",
"arguments": {
"tool_name": "sdwan_schedule_upgrade",
"arguments": {
"upgrade_data": {
"deviceIds": ["device-1", "device-2"],
"imageId": "image-xyz",
"reboot": true
},
"confirm": true
}
}
}Natural Language with Claude
Once integrated with Claude Desktop, you can use natural language:
"Show me all SD-WAN devices that are currently down"
"Deploy the branch-template to all devices in the Seattle site"
"What are the current alarms in the network?"
"Schedule a software upgrade for all edge routers to version 20.9.2"
π‘οΈ Safety Features
Confirmation Requirements
All destructive operations require explicit confirmation:
# This will return a confirmation prompt
result = await tools.handle_call("sdwan_deploy_template", {
"template_id": "abc-123",
"device_ids": ["device-1"],
"confirm": False # or omit this field
})
# Response:
{
"requires_confirmation": true,
"operation": "deploy_template",
"template_id": "abc-123",
"device_count": 1,
"message": "Set confirm=true to deploy template"
}
# Actually deploy
result = await tools.handle_call("sdwan_deploy_template", {
"template_id": "abc-123",
"device_ids": ["device-1"],
"confirm": True # Explicit confirmation
})Pre-execution Validation
The server validates operations before execution:
Device connectivity checks
Template compatibility verification
Dependency validation
Maintenance window awareness (configurable)
Rate Limiting
Prevents rapid operations that could impact the network:
Template deployments: 5 minutes between operations
Software upgrades: 1 hour between operations
Delete operations: 2 minutes between operations
Configure in config.yaml:
safety:
rate_limits:
template_deploy: 300 # seconds
software_upgrade: 3600
delete_operations: 120Audit Logging
All destructive operations are logged:
2025-10-15 10:30:45 - sdwan_safety - INFO - Operation: sdwan_deploy_template
2025-10-15 10:30:45 - sdwan_safety - INFO - User: admin
2025-10-15 10:30:45 - sdwan_safety - INFO - Details: {"template_id": "abc-123", "device_ids": ["device-1"]}
2025-10-15 10:30:45 - sdwan_safety - INFO - Status: SUCCESSπ§ Configuration Options
Basic Configuration
vmanage:
url: https://10.78.54.101
username: admin
password: your_password
verify_ssl: false
timeout: 30
max_retries: 3Safety Configuration
safety:
enabled: true
require_confirmation: true
validation:
check_device_connectivity: true
check_template_compatibility: true
check_dependencies: true
rate_limits:
template_deploy: 300
software_upgrade: 3600
backup:
auto_backup_before_deploy: true
backup_retention_days: 30Logging Configuration
logging:
level: INFO # DEBUG, INFO, WARNING, ERROR
audit_operations: true
audit_file: "sdwan_audit.log"π€ Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (
git checkout -b feature/AmazingFeature)Commit your changes (
git commit -m 'Add some AmazingFeature')Push to the branch (
git push origin feature/AmazingFeature)Open a Pull Request
π License
This project is licensed under the MIT License - see the LICENSE file for details.
π Acknowledgments
FastMCP - Modern MCP framework
UV - Fast Python package manager
Cisco SD-WAN - SD-WAN solution
Model Context Protocol - MCP specification
π Support
Issues: GitHub Issues
Documentation: Installation Guide
MCP Docs: Model Context Protocol
πΊοΈ Roadmap
Add support for SD-WAN fabric discovery
Implement advanced policy templates
Add real-time event streaming
Support for multi-tenant vManage
Enhanced error recovery and retry logic
CLI tool for standalone operations
Web UI for configuration and monitoring
Built with β€οΈ for SD-WAN automation
Available Tools
2 toolscall_sdwan_toolCall Sdwan ToolC
Universal tool caller for SD-WAN operations. Args: tool_name: Name of the tool to call (e.g., 'sdwan_get_devices') arguments: Dictionary of arguments for the tool Returns: Tool execution result as a dictionary
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | ||
| tool_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Because no annotations are provided, the description carries the full burden of behavioral disclosure. It says the tool executes a named tool and returns a dictionary, but it does not warn that calling arbitrary SD-WAN tools may have side effects, require permissions, or fail if the tool name or arguments are invalid. The behavior is only superficially described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and organized into Args/Returns sections. It avoids unnecessary filler and is easy to scan. It could be more informative without being longer if it added relationship to list_all_tools, but as written it is reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a dynamic dispatcher tool, the description omits key contextual information: how to discover valid tool_name values, what happens when the target tool fails, and whether execution can be destructive. The presence of list_all_tools as a sibling makes this gap especially notable, since the two tools form a natural workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does explain tool_name with an example and identifies arguments as a dictionary. However, it does not clarify how arguments should correspond to the selected tool's expected schema, which would be valuable for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a universal caller for SD-WAN operations, which is clear and specific enough about the verb and resource. It also names an example tool ('sdwan_get_devices') to illustrate what can be called. It does not explicitly contrast itself with the sibling list_all_tools, but the purpose is still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. Since there is a sibling tool list_all_tools, the description should at least hint that list_all_tools can be used to discover valid tool names before invoking this caller. That context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_all_toolsList All ToolsB
List all available SD-WAN tools
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it lists tools, but does not explicitly state that it is read-only, has no side effects, or what 'available' means in terms of permissions or context. The description is minimal and adds no behavioral nuance beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the exact scope of the operation efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema present, the description is fully adequate. It names the resource and action, and the output schema covers return details. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%. There is nothing for the description to add about parameters, so the baseline of 4 for no-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available SD-WAN tools' clearly identifies the verb (list) and resource (SD-WAN tools). It is specific enough to be understood, though it does not explicitly differentiate itself from the sibling call_sdwan_tool, which is implied by 'list' vs 'call'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus call_sdwan_tool. The description does not mention that this should be used for discovery before invoking a tool, nor does it state any exclusions or prerequisites. The agent is left to infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
call_sdwan_tool - First observed
list_all_tools
TDQS
Scored across 2 tools
The two tools are clearly distinct: list_all_tools is for discovery and call_sdwan_tool is for invoking a named operation. There is no overlap in purpose.
Both names follow an imperative verb_object pattern with snake_case, but 'all_tools' and 'sdwan_tool' are not perfectly parallel. Minor inconsistency only.
Cisco SD-WAN is a broad domain, yet only two meta-tools are exposed. The actual operations are hidden behind a generic dispatcher, making the count feel too thin for the apparent scope.
The tool surface contains no concrete SD-WAN operations; it only offers a listing helper and a universal caller. This leaves a significant gap in direct, typed tool coverage and requires agents to rely on an untyped dynamic dispatch mechanism.
Maintenance
Related MCP Connectors
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
AI-native Day 0 modernization platform for PRDs, architecture, work orders, and code transformation.
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI-powered network automation through natural language interactions with Cisco NSO, providing access to device management, configuration retrieval, sync operations, and service orchestration via the RESTCONF API.94MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to manage Cisco Meraki networks through natural language, including organizations, networks, devices, switches, wireless, and appliances.1GPL 3.0
- AlicenseNot gradedqualityDmaintenanceEnables intelligent troubleshooting, monitoring, and configuration of Cisco Meraki networks through natural language, with agentic workflows for automated diagnostics and health checks.MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to interact with Cisco Modeling Labs (CML) using natural language, allowing creation, management, and automation of network labs.295 PyPI71BSD 2-Clause "Simplified"