arista-cvp
$
npx mdskill add automateyournetwork/netclaw/arista-cvpAutomates Arista CloudVision Portal tasks using REST API for device and network management
- Manages Arista device inventory, events, connectivity, and tagging
- Uses CloudVision REST API and service account tokens for authentication
- Executes commands based on user input and API responses
- Returns structured data and status updates via JSON output
SKILL.md
.github/skills/arista-cvpView on GitHub ↗
---
name: arista-cvp
description: "Arista CloudVision Portal (CVP) automation via REST API — device inventory, events, connectivity monitoring, tag management (4 tools). Use when managing Arista devices, checking CloudVision events, monitoring network connectivity probes, or tagging devices in CVP."
license: Apache-2.0
user-invocable: true
metadata:
{ "openclaw": { "requires": { "bins": ["uv"], "env": ["CVP", "CVPTOKEN"] } } }
---
# Arista CloudVision Portal (CVP) Automation
## MCP Server
| Field | Value |
|-------|-------|
| **Repository** | [noredistribution/mcp-cvp-fun](https://github.com/noredistribution/mcp-cvp-fun) |
| **Transport** | stdio (FastMCP) |
| **Python** | 3.12+ |
| **Protocol** | HTTPS REST → CloudVision Resource API |
| **Dependencies** | `fastmcp`, `httpx`, `python-dotenv` |
| **Install** | `git clone` + `uv run` (dependencies resolved at runtime) |
| **Entry Point** | `uv run --with fastmcp fastmcp run /path/to/mcp_server_rest.py` |
| **Status** | Community demo — not officially supported by Arista |
## Authentication
CloudVision uses service account tokens passed as HTTP cookies:
1. Log in to CloudVision Portal
2. Navigate to **Settings → Service Accounts**
3. Create a service account and generate a token
4. Store the token in the `.env` file as `CVPTOKEN`
The token is sent as an `access_token` cookie with every API request (not a Bearer header).
## Environment Variables
| Variable | Required | Purpose |
|----------|----------|---------|
| `CVP` | Yes | CloudVision instance hostname (e.g., `www.arista.io` or `cvp.example.com`) |
| `CVPTOKEN` | Yes | Service account token for API authentication |
---
## Tools (4)
### Device Inventory (1 tool)
| Tool | Parameters | Description |
|------|-----------|-------------|
| `get_inventory` | — | Get inventory of all devices from CloudVision (hostname, model, serial, version, MAC, IP, streaming status) |
### Event Monitoring (1 tool)
| Tool | Parameters | Description |
|------|-----------|-------------|
| `get_events` | — | Get all events from CloudVision (alerts, warnings, informational events with severity, timestamps, device associations) |
### Connectivity Monitoring (1 tool)
| Tool | Parameters | Description |
|------|-----------|-------------|
| `get_connectivity_monitor` | — | Get Connectivity Monitor probe statistics (jitter, latency, packet loss, HTTP response time across all probes) |
### Tag Management (1 tool)
| Tool | Parameters | Description |
|------|-----------|-------------|
| `create_tag` | `tag_name`, `tag_value` | Create a device-level tag in CloudVision via workspace workflow (create workspace → create tag → build → submit) |
### `create_tag` Workflow Detail
The `create_tag` tool follows CloudVision's workspace model — a 5-step process:
1. **Create Workspace** — POST to `/api/resources/workspace/v1/WorkspaceConfig` with a UUID-based workspace
2. **Create Tag** — POST to `/api/resources/tag/v2/TagConfig` with `ELEMENT_TYPE_DEVICE`, workspace ID, tag name/value
3. **Build Workspace** — POST with `REQUEST_START_BUILD` to validate changes
4. **Wait for Build** — 10-second wait for build completion
5. **Submit Workspace** — POST with `REQUEST_SUBMIT` to apply the tag
---
## CloudVision Resource API Endpoints
| Method | Endpoint | Tool |
|--------|----------|------|
| GET | `/api/resources/inventory/v1/Device/all` | `get_inventory` |
| GET | `/api/resources/event/v1/Event/all` | `get_events` |
| GET | `/api/resources/connectivitymonitor/v1/ProbeStats/all` | `get_connectivity_monitor` |
| POST | `/api/resources/workspace/v1/WorkspaceConfig` | `create_tag` (workspace create/build/submit) |
| POST | `/api/resources/tag/v2/TagConfig` | `create_tag` (tag creation) |
Responses use newline-delimited JSON (NDJSON) format, consistent with CloudVision's streaming resource API.
---
## Workflows
### 1. Arista Device Discovery
```
get_inventory → list all Arista devices (hostname, model, serial, version, MAC, IP)
→ Cross-reference with NetBox/Nautobot → flag discrepancies
→ GAIT
```
### 2. Arista Event Monitoring
```
get_events → retrieve all CloudVision events
→ Filter by severity (critical, warning, info)
→ Correlate events with device inventory
→ Severity-sort findings → GAIT
```
### 3. Arista Network Health Check
```
get_inventory → identify all managed devices
→ get_events → check for active alarms and warnings
→ get_connectivity_monitor → analyze jitter, latency, packet loss
→ Correlate connectivity issues with events → severity-sort → GAIT
```
### 4. Arista Device Tagging
```
ServiceNow CR must be in Implement state
→ get_inventory → verify target devices exist
→ create_tag(tag_name, tag_value) → apply device-level tag via workspace workflow
→ get_inventory → verify tag applied
→ GAIT
```
### 5. Arista Connectivity Baseline
```
get_connectivity_monitor → capture current probe statistics
→ Record jitter, latency, packet loss baselines per probe
→ Compare against thresholds → flag degradation
→ GAIT
```
---
## Integration with Other Skills
| Skill | Integration |
|-------|-------------|
| **pyats-network** | CVP MCP for Arista fleet visibility, pyATS MCP for Cisco devices — unified multi-vendor monitoring |
| **junos-network** | CVP MCP for Arista, JunOS MCP for Juniper — multi-vendor device inventory and health |
| **netbox-reconcile** | Cross-reference CVP device inventory (model, serial, version) against NetBox source of truth |
| **nautobot-sot** | Same as NetBox — validate Arista device IPAM data in Nautobot |
| **infrahub-sot** | Cross-reference Infrahub node data with Arista device inventory from CVP |
| **servicenow-change-workflow** | Gate all `create_tag` operations behind ServiceNow Change Requests |
| **gait-session-tracking** | Every CVP inventory query, event pull, and tag creation logged in GAIT |
| **te-network-monitoring** | Correlate ThousandEyes path data with CVP connectivity monitor probes |
| **nvd-cve** | Scan EOS versions from `get_inventory` against NVD vulnerability database |
| **markmap-viz** | Generate topology mind maps from CVP device inventory data |
---
## CVP MCP vs pyATS MCP vs JunOS MCP
| Capability | CVP MCP | pyATS MCP | JunOS MCP |
|-----------|---------|-----------|-----------|
| **Vendor** | Arista (via CVP) | Cisco (IOS-XE, NX-OS, IOS-XR) | Juniper |
| **Protocol** | HTTPS REST → CVP Resource API | SSH + Genie parsers | NETCONF → PyEZ |
| **Device Inventory** | `get_inventory` (fleet-wide) | `pyats_learn("platform")` per device | `gather_device_facts` per device |
| **Event Monitoring** | `get_events` (fleet-wide) | Per-device show commands | Per-device show commands |
| **Connectivity Metrics** | `get_connectivity_monitor` (probes) | Per-device show commands | Per-device show commands |
| **Config Push** | Via CVP Change Control (not in MCP) | `pyats_configure_device` | `load_and_commit_config` |
| **Tag/Label Mgmt** | `create_tag` (workspace workflow) | N/A | N/A |
| **Batch Operations** | All tools are fleet-wide by default | `pyats_pcall` (parallel pCall) | `execute_junos_command_batch` |
| **MCP Tools** | 4 | 8 | 10 |
---
## Guardrails
- **Always call `get_inventory` first** — verify CloudVision is reachable and devices are streaming before deeper queries
- **Check events before changes** — call `get_events` to identify active issues before any tag operations
- **Gate tag creation** — all `create_tag` calls must have a ServiceNow CR in `Implement` state
- **Validate tag names** — ensure tag names follow organizational naming conventions before creation
- **Monitor connectivity baselines** — use `get_connectivity_monitor` to establish baselines before and after network changes
- **Cross-reference inventory** — compare CVP device data with NetBox/Nautobot to detect SoT drift
- **Record in GAIT** — every inventory query, event pull, connectivity check, and tag creation must be logged
- **Community project** — this is an unofficial demo; evaluate security implications (TLS verification disabled in source) before production use
More from automateyournetwork/netclaw
- aap-automationRed Hat Ansible Automation Platform — inventory management, job template execution, project SCM sync, ad-hoc commands, host management, Galaxy content discovery. Use when automating infrastructure with Ansible, running playbooks, managing inventories, or searching for Ansible collections and roles.
- aap-edaEvent-Driven Ansible (EDA) — activation lifecycle, rulebook management, decision environments, event stream monitoring. Use when managing event-driven automation triggers, enabling/disabling activations, or reviewing EDA rulebooks.
- aap-lintansible-lint playbook and role validation — syntax checking, best practice enforcement, project-wide analysis, rule filtering. Use when validating Ansible playbooks, checking code quality, or enforcing automation best practices before deployment.
- aci-change-deploySafe ACI policy change deployment - ServiceNow CR lifecycle, pre/post-change fault baselines, APIC policy application, automatic rollback on fault delta, and GAIT audit trail. Use when deploying ACI policy changes, creating tenants or EPGs, pushing config to APIC, or running a change window with rollback protection.
- aci-fabric-auditComprehensive Cisco ACI fabric health audit - node status, tenant/VRF/BD/EPG policy review, contract analysis, fault triage, and endpoint learning verification. Use when auditing ACI fabric health, checking for faults, reviewing tenant policies, or running pre/post-change baselines on APIC.
- aruba-cx-configView and manage Aruba CX switch configurations, perform ISSU upgrades, and firmware operations
- aruba-cx-interfacesMonitor Aruba CX switch interface status, LLDP neighbors, and optical transceiver health
- aruba-cx-switchingView and manage Aruba CX switch VLANs and MAC address tables for Layer 2 operations
- aruba-cx-systemDiscover Aruba CX switch system information, firmware versions, and VSF topology
- atlassian-itsmIT Service Management workflows using Jira for issue tracking and Confluence for documentation