arista-cvp

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

## Failure Behavior

- If a tool call fails with an authentication or connection error, check that `CVP`, `CVPTOKEN` are set and valid before assuming a data or device problem.
- On a tool error (timeout, unreachable host, malformed response), report the failure and its error message directly to the user rather than fabricating or guessing at results.
- Do not automatically retry a write/mutating operation after a failure — surface the error and get explicit confirmation before retrying, since a blind retry on a partially-applied change can leave state inconsistent.