cv-cue-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CVCUE_CID | No | Customer ID. Only needed when the key can reach more than one customer. | |
| CVCUE_KEY_ID | No | API key ID from Launchpad → Admin → Keys (cloud). | |
| CVCUE_BASE_URL | No | API base URL, e.g. https://awmXXXXX-c4.srv.wifi.arista.com/wifi/api. In CV-CUE: System → Advanced Settings → Base URLs for APIs. Optional with an API key (found through Launchpad). | |
| CVCUE_ENV_FILE | No | Path to the .env file to load. Defaults to ./.env, then the project root. | |
| CVCUE_PASSWORD | No | Local password (on-prem alternative to an API key; local mode only). | |
| CVCUE_USERNAME | No | Local username (on-prem alternative to an API key; local mode only). | |
| CVCUE_KEY_VALUE | No | API key value from Launchpad → Admin → Keys (cloud). | |
| CVCUE_VERIFY_SSL | No | false for on-prem servers with self-signed certificates. | |
| CVCUE_OPENAPI_SPEC | No | Use a different OpenAPI spec instead of the bundled one. | |
| CVCUE_ENABLE_WRITES | No | true allows mutating calls. Default false. | false |
| CVCUE_REDACT_SECRETS | No | false shows secrets in tool output. Default true. | true |
| CVCUE_CREDENTIALS_FILE | No | INI file with a [cvcue] section. | ~/.cvcue/credentials |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cvcue_session_infoA | Show the current CV-CUE API session: logged-in key/user, role, customer, timezone and allowed locations, plus the server base URL and version. Good first call to confirm connectivity. |
| cvcue_server_infoA | CV-CUE server version, supported API module versions and server health. Use to check whether an endpoint/version is available on this server. |
| cvcue_list_locationsA | List the CV-CUE location hierarchy (folders and floors) as a flat list with
id, type, parentId and full path. Location ids scope most other tools via
|
| cvcue_get_locationA | Get one location with its path and direct children. |
| cvcue_create_locationA | Create a folder or floor location under a parent. Requires CVCUE_ENABLE_WRITES=true. |
| cvcue_delete_locationA | Delete a location AND all of its child locations. Irreversible. Requires CVCUE_ENABLE_WRITES=true and confirm=true. |
| cvcue_list_apsA | List managed Arista APs (GET /manageddevices/aps) with status, model, firmware, IP, location and client count. Use cvcue_ap_health_summary for fleet-wide rollups and cvcue_get_ap for one AP. |
| cvcue_get_apA | Get full details for one managed AP (radios, wired interfaces, mesh, health) by MAC or name. |
| cvcue_ap_health_summaryA | Fleet health rollup for managed APs: online/offline counts, breakdown by model, firmware, upgrade/config-push status, plus lists of offline APs and APs with problems (crashes, low power, tunnels down, config errors). |
| cvcue_list_radiosA | List Wi-Fi radios across managed APs (channel, width, tx power, noise, RF utilization, client count) — the RF view for channel/power analysis. |
| cvcue_reboot_apsA | Reboot one or more managed APs (clients will be disconnected). Requires CVCUE_ENABLE_WRITES=true and confirm=true. |
| cvcue_list_clientsB | List Wi-Fi clients (GET /clients) with SSID, AP, signal, protocol, data rates, IP, username and OS. Defaults to currently connected clients. |
| cvcue_find_clientA | Find a client by MAC, IP, username or device name (active or recently seen). Tries the most specific field first and returns all matches. |
| cvcue_client_health_summaryA | Rollup of currently connected clients: totals by SSID, AP, protocol/band, OS, vendor and signal-quality bucket, plus clients with poor performance. |
| cvcue_client_association_historyB | Recent associations for a client (which APs/SSIDs it joined and when). |
| cvcue_disconnect_clientA | Force-disconnect (deauthenticate) a wireless client. The client may reconnect. Requires CVCUE_ENABLE_WRITES=true and confirm=true. |
| cvcue_list_ssidsA | List SSID profiles (WLANs): SSID name, enabled, VLAN, security mode, guest, client isolation and where the profile was created. Use cvcue_get_ssid for the full configuration. |
| cvcue_get_ssidA | Full configuration of one SSID profile (security, network, QoS, firewall, portal...). |
| cvcue_ssid_usageA | Live monitoring data per SSID/WLAN (GET /manageddevices/aps/wlans): which SSIDs are broadcast, on which bands, and how many APs/clients use them. |
| cvcue_delete_ssidA | Delete an SSID profile. Fails if the profile is still referenced by a device template (check GET /deviceconfiguration/ssidprofiles/{templateid}/references). Requires CVCUE_ENABLE_WRITES=true and confirm=true. |
| cvcue_query_eventsB | Recent CV-CUE events/alerts (WIPS, performance, connectivity, system), newest first, with severity, category, type, summary and timestamps. |
| cvcue_event_summaryA | Summarize events in a time window: totals by severity, category and type, the most frequent summaries, and the latest high-severity events. |
| cvcue_list_rogue_apsA | List APs detected by CV-CUE WIPS sensors by classification (rogue, external neighbor, uncategorized, authorized) with SSIDs, vendor, signal and clients. |
| cvcue_rogue_ap_summaryB | WIPS overview: number of detected (non-managed) APs per classification, rogue APs with associated clients, top vendors and top SSIDs among rogues. |
| cvcue_network_healthB | Key network health metrics for a location and each child location: connectivity success (association/auth/DHCP/DNS failures), performance (latency, retries, coverage, data rate), application experience and infrastructure health — the CV-CUE "Network Health" dashboard. |
| cvcue_client_eventsA | Client connection event logs reported by APs (association, authentication, DHCP, DNS, roaming...) — defaults to failures in the last 24h. |
| cvcue_device_logsB | Consolidated AP/device event logs (reboots, crashes, config, upgrades), newest first. |
| cvcue_troubleshoot_clientA | One-shot client troubleshooting: current client record, recent associations, connection logs, failure events and CV-CUE inferences (root-cause hints) for a client MAC. Sections that fail (e.g. permissions) are reported inline. |
| cvcue_list_switchesA | List switches discovered via AP uplinks (LLDP): name, vendor, chassis id, number of APs/clients behind each, AP distribution by PoE and link speed. |
| cvcue_list_wired_clientsA | List wired hosts seen on AP LAN ports (MAC, IP, VLAN, port, auth status, traffic). |
| cvcue_api_modulesA | List the CV-CUE API modules with operation counts (step 1 of API discovery). Modules group related resources: session, locations, manageddevices (your APs),
aps (all detected APs incl. rogues), clients, configuration (policies),
deviceconfiguration (SSID/role/RADIUS profiles, device templates), events,
troubleshooting, system, reports, analytics, switches, users, ...
Pass a module name as |
| cvcue_api_searchA | Search CV-CUE API endpoints (step 2 of API discovery). Matches every word of |
| cvcue_api_schemaA | Get parameters, request body and response schema for one endpoint (step 3 of API discovery). Component $refs are inlined up to ref_depth. |
| cvcue_api_executeA | Execute ANY CV-CUE API call (step 4 of API discovery). Paths are relative to the API base URL (…/wifi/api). Most list endpoints page with startindex (0-based offset) + pagesize, and accept locationid to scope results to a location subtree (see cvcue_list_locations). Examples: GET /system/version GET /manageddevices/aps query_params={"pagesize": 20, "active": true} GET /clients/{macaddress}/associationhistory path_params={"macaddress": "AA:BB:CC:DD:EE:FF"} GET /troubleshooting/clientevents query_params={"fromtime": , "pagesize": 50} Large responses: many GETs accept fields=[...] for a selective fetch (a field that doesn't support it fails with SELECTIVE_FETCH_OR_UPDATE_NOT_SUPPORTED_FOR_FIELD — drop that field and retry). /deviceconfiguration/devicetemplates is huge unless you pass modelspecific=false. Oversized results are refused with a shape preview. Secret values (passphrases, RADIUS secrets...) come back as REDACTED. Never send that placeholder back in a write body — omit the field or supply the real value. Non-GET calls require writes to be enabled for this connection. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 34 tools
Most tools target a clear resource+action (list_aps vs get_ap vs ap_health_summary are explicitly cross-referenced in their descriptions), and the summary/list/detail split is well signposted. Some boundaries are fuzzier: query_events vs event_summary vs device_logs vs client_events all return event-ish data, and session_info vs server_info are close cousins. cvcue_api_execute intentionally overlaps everything, but it is framed as the escape hatch after the discovery trio.
Every tool carries the cvcue_ prefix in snake_case, which makes the set highly predictable. Most follow verb_noun (list_aps, get_ssid, delete_location, disconnect_client), with a minority using noun_phrase summaries (ap_health_summary, rogue_ap_summary, network_health, client_association_history) — readable but not a strict single pattern.
At 34 tools this is heavy, sitting above the comfortable range, and several of them are summary variants of the same underlying list endpoints. The domain is genuinely broad (APs, clients, SSIDs, locations, WIPS, switches, events, plus a 4-tool API discovery ladder), so the size is defensible but leans toward redundancy rather than minimalism.
Read coverage is strong — health rollups, events, WIPS, wired/switch views, troubleshooting, and location hierarchy all have dedicated tools. Write coverage is asymmetric: reboot, disconnect, delete SSID/location exist, but there is no create_ssid or update_ssid profile tool; agents can fall back to cvcue_api_execute, which is a workable but secondary path.