beye.blog logo
AI

Building a secur Nexus Dashboard MCP Server

13 min read
#MCP Server#Network Automation#Claude AI#Open Source#Cisco Nexus#Python#Docker
Building a secur Nexus Dashboard MCP Server

As a network engineer who lives and breathes automation, I spend most of my time making infrastructure talk to itself. Ansible playbooks. Terraform configurations. GitLab CI/CD pipelines. But when I started working more with Cisco's Nexus Dashboard, I ran into a frustrating wall: every interaction required clicking through the web UI or crafting complex REST API calls. I wanted something better. I wanted to just ask for what I needed.

That's when I discovered Anthropic's Model Context Protocol (MCP) and realized I could build exactly that.

The Problem: Manual Operations Don't Scale

If you've worked with Cisco Nexus Dashboard, you know it's powerful. It consolidates management for ACI fabrics, provides deep analytics through Nexus Dashboard Insights, and offers infrastructure monitoring. But accessing all that power means either:

  • Clicking through dozens of web UI pages
  • Writing complex Python scripts with REST API calls
  • Memorizing hundreds of API endpoints across five different services
  • Manually handling authentication, sessions, and error handling

For someone who automates network changes daily, this felt wrong. I wanted to describe what I needed in natural language and have it happen. "Show me all fabrics." "Get me the health score for switch spine-1." "Create a VLAN on fabric-prod." Simple requests that shouldn't require opening a browser or writing 50 lines of Python.

Discovering the Model Context Protocol

I'd been using Claude Code for development work and noticed the MCP server integrations - tools that let Claude interact with external systems directly. The architecture was elegant: Claude sends structured requests to an MCP server, the server handles the API complexity, and Claude gets back clean results.

I realized this was exactly what I needed for Nexus Dashboard. If I could build an MCP server that understood the Nexus Dashboard APIs, Claude could become my network automation interface. No more context switching. No more manual API calls. Just natural language requests that get translated into real network operations.

What I Built: Architecture Overview

The Nexus Dashboard MCP Server is a comprehensive Python application that bridges Claude AI with Cisco Nexus Dashboard. Here's what's under the hood:

Core Components:

┌─────────────┐
│   Claude    │  ← Natural language queries
│     AI      │
└──────┬──────┘
       │
       │ MCP Protocol
       │
┌──────┴──────────────────────────────────┐
│    Nexus Dashboard MCP Server           │
│                                          │
│  ┌────────────┐      ┌────────────┐    │
│  │ MCP Server │◄────►│  Web API   │    │
│  │  (stdio)   │      │ (REST API) │    │
│  └──────┬─────┘      └─────┬──────┘    │
│         │                   │           │
│         │          ┌────────┴────────┐  │
│         │          │   PostgreSQL    │  │
│         │          │    Database     │  │
│         │          └─────────────────┘  │
│         │                               │
│  ┌──────┴──────────┐                   │
│  │   Web UI        │                   │
│  │  (Next.js)      │                   │
│  └─────────────────┘                   │
└─────────────────────────────────────────┘
       │
       │ Nexus Dashboard APIs
       │
┌──────┴──────────────────────────────────┐
│    Cisco Nexus Dashboard Clusters       │
│                                          │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │ Cluster │  │ Cluster │  │ Cluster │ │
│  │   #1    │  │   #2    │  │   #3    │ │
│  └─────────┘  └─────────┘  └─────────┘ │
└──────────────────────────────────────────┘
  • FastMCP Framework - Handles the Model Context Protocol communication with Claude
  • FastAPI Web API - Provides REST endpoints for management and monitoring
  • PostgreSQL Database - Stores encrypted credentials, audit logs, and configuration
  • Next.js Web UI - Management interface for clusters, security, and audit logs
  • Docker Compose - Orchestrates all services for easy deployment

API Coverage:

The server provides access to 638 operations across five Nexus Dashboard APIs:

  • Manage API (146 endpoints) - Fabrics, switches, VLANs, VRFs, networks, interfaces
  • Analyze API - Telemetry data, insights, anomalies, compliance reporting
  • Infrastructure API - System health, licensing, user management, backup/restore
  • OneManage API - Device inventory, topology discovery
  • Orchestration API - Workflows and automation orchestration
Building It: The Development Journey

I started with a simple prototype - just loading one OpenAPI spec and generating tools. That worked, but I quickly realized this needed to be production-ready. Network infrastructure isn't something you experiment with casually.

Security came first. I implemented:

  • Read-only by default - Write operations require explicit enablement
  • Fernet encryption - All credentials encrypted at rest in PostgreSQL
  • Complete audit logging - Every operation logged with timestamp, user, and details
  • Operation whitelisting - Granular control over which operations are allowed
  • Client IP tracking - Know exactly where requests originate

Then came the database integration. I didn't want credentials hardcoded in environment files. The system needed to:

  • Store multiple Nexus Dashboard clusters
  • Encrypt passwords with proper key management
  • Allow dynamic cluster selection without restarting
  • Track security configuration (edit mode, whitelists) in the database
  • Provide a complete audit trail for compliance

The Web UI was next. I built a Next.js interface that provides:

  • Dashboard - Real-time statistics and system health
  • Cluster Management - Add, edit, delete Nexus Dashboard connections
  • Security Configuration - Toggle edit mode, configure operation whitelists
  • Audit Logs - Complete operation history with filtering and CSV export
  • Health Monitoring - Service status and database connectivity
The Docker Architecture

Everything runs in containers for consistency and easy deployment:

yaml
services:
  postgres:
    image: postgres:15-alpine
    ports:
      - "15432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: nexus_mcp
      POSTGRES_USER: mcp_user
      POSTGRES_PASSWORD: ${DB_PASSWORD}
 
  mcp-server:
    build: .
    volumes:
      - ./src:/app/src
    depends_on:
      - postgres
    environment:
      DATABASE_URL: postgresql://mcp_user:${DB_PASSWORD}@postgres:5432/nexus_mcp
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      EDIT_MODE_ENABLED: false
 
  web-api:
    build: .
    command: uvicorn src.api.web_api:app --host 0.0.0.0 --port 8002
    ports:
      - "8002:8002"
    depends_on:
      - postgres
 
  web-ui:
    build: ./web-ui
    ports:
      - "7001:3000"
    environment:
      NEXT_PUBLIC_API_URL: http://localhost:8002

This setup provides:

  • PostgreSQL on port 15432 (avoiding conflicts with other databases)
  • MCP Server communicating via stdio with Claude Desktop
  • Web API on port 8002 for management operations
  • Web UI on port 7001 for browser access
Preparing for Open Source

Deciding to open-source this was easy. Network automation tools should be shared. But preparing for public release took careful work.

The sanitization process:

I had internal IP addresses, example passwords, and development notes scattered throughout documentation. I built two automation scripts:

  1. prepare_github_release.sh - Copies only project-related files, excludes sensitive data and build artifacts
  2. sanitize_docs.sh - Replaces internal IPs, credentials, and placeholder URLs with generic examples

These scripts ensured:

  • No .env files with real credentials
  • No internal IP addresses (192.168.x.x → nexus-dashboard.example.com)
  • No example passwords
  • No node_modules (saved 533MB)
  • No Python cache or build artifacts
  • Clean git history without development progress docs

The result: a clean 6.6MB repository with 83 essential files, down from 550MB of development artifacts.

Getting Started: Deploy Your Own

Want to try it? Here's how to get the Nexus Dashboard MCP server running in your environment.

Prerequisites:

  • Docker 20.10+ and Docker Compose 2.0+
  • Access to a Cisco Nexus Dashboard cluster
  • Python 3.11+ (for local development)
  • Claude Desktop (for MCP integration)

Step 1: Clone and Configure

bash
# Clone the repository
git clone https://github.com/beye91/nexus-dashboard-mcp.git
cd nexus-dashboard-mcp
 
# Create environment file
cp .env.example .env

Edit .env with your configuration:

bash
# Nexus Dashboard Configuration
NEXUS_CLUSTER_URL=https://your-nexus-dashboard.example.com
NEXUS_USERNAME=admin
NEXUS_PASSWORD=YourSecurePassword
NEXUS_VERIFY_SSL=true
 
# Security
EDIT_MODE_ENABLED=false  # Keep read-only by default
ENCRYPTION_KEY=generate-key-below
SESSION_SECRET=your-random-secret-key
 
# Database
DB_PASSWORD=your-secure-db-password

Step 2: Start Services

bash
# Start all services
docker-compose up -d
 
# View logs
docker-compose logs -f
 
# Check status
docker-compose ps

This starts:

  • PostgreSQL database on port 15432
  • Web API on port 8002
  • Web UI on port 7001
  • MCP server (stdio mode)

Step 3: Configure Your First Cluster

Open http://localhost:7001 in your browser:

  1. Navigate to Clusters page
  2. Click Add New Cluster
  3. Enter your Nexus Dashboard details:
  4. Click Test Connection to verify
  5. Click Create Cluster

Your credentials are now stored encrypted in PostgreSQL.

Step 4: Integrate with Claude Desktop

Add this to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):

json
{
  "mcpServers": {
    "nexus-dashboard": {
      "command": "docker",
      "args": [
        "exec",
        "-i",
        "nexus-mcp-server",
        "python",
        "src/main.py"
      ]
    }
  }
}

Restart Claude Desktop. You'll see the Nexus Dashboard tools appear in the available tools list.

Step 5: Start Using It

Try these natural language requests in Claude:

  • "Show me all fabrics in my Nexus Dashboard"
  • "What's the health status of fabric-prod?"
  • "List all switches in fabric-prod"
  • "Get me the inventory of switch spine-1"
  • "Show me all VLANs in fabric-prod"

Claude translates these into the appropriate API calls, handles authentication, and returns clean, formatted results.

Real-World Examples

Here's what it looks like in practice:

Example 1: Fabric Discovery

You: "What fabrics are available in my Nexus Dashboard?"

Claude: "I'll query the Nexus Dashboard Manage API to get a list of all fabrics."

Claude calls manage_listFabrics operation

Claude: "You have 3 fabrics configured:

  1. fabric-prod - Production ACI fabric, 8 switches, last health check: Green
  2. fabric-staging - Staging environment, 4 switches
  3. fabric-dev - Development fabric, 2 switches"

Example 2: Switch Health Check

You: "Give me the health score for switch spine-1 in fabric-prod"

Claude: "Let me check the health status for that switch."

Claude calls manage_getSwitchHealth with fabric and switch parameters

Claude: "spine-1 health report:

  • Overall Score: 95/100
  • CPU Usage: 23%
  • Memory Usage: 41%
  • Status: Healthy
  • Last Update: 2025-11-23 15:30:00"

Example 3: Audit Compliance

You: "Show me all operations performed in the last 24 hours"

Claude: "I'll query the audit log for recent activity."

Claude retrieves from PostgreSQL audit_log table

Claude: "Last 24 hours activity (15 operations):

  • 12 read operations (listFabrics, getSwitches, etc.)
  • 2 write operations (createVLAN, updateNetwork) - edit mode was enabled
  • 1 failed operation (403 error, edit mode disabled at time)
  • All operations from IP: 192.168.1.100"
The Security Model

Security was non-negotiable. Here's how it works:

Read-Only by Default:

All operations start as read-only. Write operations (POST, PUT, DELETE) require explicit enablement through the Web UI. This prevents accidental changes.

Encrypted Credentials:

When you add a cluster, the password is immediately encrypted using Fernet symmetric encryption:

python
from cryptography.fernet import Fernet
 
# Encryption key from environment
cipher = Fernet(os.getenv("ENCRYPTION_KEY").encode())
 
# Encrypt password before storing
encrypted_password = cipher.encrypt(password.encode())
 
# Store encrypted value in PostgreSQL
db.execute("INSERT INTO clusters (name, url, username, encrypted_password) VALUES (?, ?, ?, ?)",
           name, url, username, encrypted_password)

Complete Audit Trail:

Every operation is logged to PostgreSQL:

python
{
  "timestamp": "2025-11-23T15:30:00Z",
  "cluster": "production",
  "endpoint": "https://nexus-dashboard.example.com/api/v1/manage/fabrics",
  "method": "GET",
  "path": "/api/v1/manage/fabrics",
  "status_code": 200,
  "client_ip": "192.168.1.100",
  "request_body": null,
  "response_body": "{...}"
}

This provides:

  • Complete compliance trail
  • Troubleshooting history
  • Security incident investigation
  • CSV export for reporting

Operation Whitelisting:

You can restrict which operations are allowed:

python
# Allow only specific read operations
allowed_operations = [
    "manage_listFabrics",
    "manage_listSwitches",
    "analyze_getHealthScores"
]

Attempts to use non-whitelisted operations are blocked and logged.

Technical Lessons Learned

Building this taught me several important lessons:

1. OpenAPI Specs Are Gold

Cisco provides OpenAPI specifications for all Nexus Dashboard APIs. These specs contain everything: endpoints, parameters, schemas, authentication. I built a loader that:

  • Parses OpenAPI 3.0 specs
  • Generates MCP tool definitions automatically
  • Maps Nexus Dashboard operations to Claude-friendly descriptions
  • Handles 638 operations across 5 APIs without manual coding

2. Database-Driven Configuration Wins

Initially, I used environment variables for everything. Bad idea. The shift to PostgreSQL for configuration meant:

  • No server restarts for config changes
  • Multiple users can manage settings via Web UI
  • Complete history of configuration changes
  • Credentials never touch the filesystem

3. Async Python Is Required

The MCP server handles multiple operations concurrently. Using FastMCP's async support:

python
@mcp.tool()
async def manage_listFabrics():
    """List all fabrics in Nexus Dashboard"""
    async with aiohttp.ClientSession() as session:
        response = await session.get(f"{base_url}/api/v1/manage/fabrics",
                                     headers=headers)
        return await response.json()

This keeps Claude responsive even with slow API calls.

4. Docker Simplifies Deployment

Docker Compose was crucial. Users don't need to:

  • Install Python dependencies
  • Set up PostgreSQL manually
  • Configure CORS settings
  • Manage process orchestration

Just docker-compose up -d and everything works.

5. Audit Logging Is Non-Negotiable

For enterprise network infrastructure, you need to know:

  • Who made what change
  • When did it happen
  • What was the result
  • Where did the request come from

The PostgreSQL audit log provides all of this with millisecond precision.

What's Next: The Roadmap

This is version 1.0, but there's more to build:

Immediate Priorities:

  • CI/CD Pipeline - Automated testing and Docker image builds via GitHub Actions
  • Additional API Support - Load multiple APIs simultaneously
  • Advanced Audit Filtering - Search by date range, operation type, user
  • WebSocket Support - Real-time audit log streaming to Web UI

Future Features:

  • Multi-User Authentication - User login with JWT tokens
  • Role-Based Access Control - Different permission levels for different users
  • Prometheus Metrics - Export operational metrics for monitoring
  • Webhooks - Trigger external systems on specific events
  • GraphQL API - More efficient data fetching for Web UI

Community Contributions:

I'm particularly interested in:

  • Support for additional Cisco platforms (Catalyst Center, Meraki Dashboard)
  • Integration with other network vendors' APIs
  • Custom operation templates for common workflows
  • Performance optimization suggestions
Try It Yourself

The Nexus Dashboard MCP Server is available now on GitHub:

Repository: https://github.com/beye91/nexus-dashboard-mcp

What you get:

  • Complete source code (Apache 2.0 license)
  • Docker Compose setup for one-command deployment
  • Comprehensive documentation (25+ markdown guides)
  • Example configurations and usage patterns
  • Active development and issue tracking

Quick start:

bash
git clone https://github.com/beye91/nexus-dashboard-mcp.git
cd nexus-dashboard-mcp
cp .env.example .env
# Edit .env with your Nexus Dashboard details
docker-compose up -d
# Open http://localhost:7001 to configure

That's it. Five minutes from clone to working MCP server.

Final Thoughts

Building the Nexus Dashboard MCP Server taught me that the best automation tools are the ones that disappear. You shouldn't think about API endpoints, authentication flows, or error handling. You should think about what you want to accomplish and let the tools handle the rest.

That's what MCP enables. Natural language requests that become real network operations. Claude as your network automation interface. Infrastructure that responds to intent, not commands.

If you're managing Cisco Nexus Dashboard, ACI fabrics, or any network infrastructure that feels too manual, give this a try. Clone the repo, deploy the containers, and see what it's like to automate network operations by just asking.

The code is open-source. The documentation is comprehensive. The deployment is straightforward. And if you build something cool with it, I want to hear about it.

Let's make network automation more accessible, one natural language request at a time.


Resources:

Chris Beye

About the Author

Chris Beye

Network automation enthusiast and technology explorer sharing practical insights on Cisco technologies, infrastructure automation, and home lab experiments. Passionate about making complex networking concepts accessible and helping others build better systems.

Read More Like This