Aruba Central MCP

io.github.shigechikaPublished by GitHub account shigechikav0.10.2Updated Nov 3, 2026

MCP server for Aruba Central: expose AP, switch, and client status to AI assistants

VerifiedSTDIODesktop onlyCloud & InfrastructureSecurity & Monitoring

Overview

AI-generated overview

Read-only MCP server that lets an assistant query Aruba Central for access point, switch, client, WLAN and firmware status.

What you can do
  • Inspect access points, radios, BSSIDs, WLANs, swarms and per-AP status or throughput
  • List switches and connected wireless clients, look up a client by MAC, and trace its roaming history
  • Review usage and capacity trends: top APs and clients by bandwidth, client count over time
  • Check firmware per swarm, including Classic Central upgrade state and offered versions
  • Run a health check of the server and authentication, or a daily brief flagging sites with too many offline APs
When to use it
Useful when you administer Aruba Central wireless networks and want an assistant to answer inventory, RF troubleshooting, client roaming, capacity and firmware questions without opening the dashboard. All tools read only, so it suits monitoring and diagnosis rather than configuration.
Requirements
Local Python 3.10+ process, typically launched with uvx (uv must be on PATH). An Aruba Central account with GreenLake New Central API access and OAuth2 client credentials, supplied via ARUBA_CENTRAL_BASE_URL, ARUBA_CENTRAL_CLIENT_ID and ARUBA_CENTRAL_CLIENT_SECRET. Optional Classic Central firmware details need the four ARUBA_CLASSIC_* variables, including a token file the server rewrites.
Before you install
Requires an OAuth2 client secret (ARUBA_CENTRAL_CLIENT_SECRET) and, for Classic Central, a client secret plus a token file holding access and refresh tokens; the server rewrites that file and rotates the refresh token, so only one process should own it. Network inventory, client MAC addresses and site names are sent to Aruba Central's API. All tools are read-only; nothing is configured or upgraded.

Installation

In SourceWeft

  1. Open Aruba Central MCP in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

aruba-central-mcp

English | 日本語

MCP server for Aruba Central (GreenLake New Central API).

Exposes access point, switch, and wireless client status to MCP-compatible AI assistants (Claude Code, Claude Desktop, OpenAI Codex, etc.) via STDIO transport.

Documentation: https://shigechika.github.io/aruba-central-mcp/

Features

Access Points

ToolDescription
list_apsList all access points (with optional site/status filter)
list_radiosList AP radios (channel, utilization, noise floor, TX power)
list_bssidsList all BSSIDs
list_wlansList WLANs (SSID, security, VLAN)
list_swarmsList AP swarms/clusters
get_ap_statusGet detailed status of a specific AP
get_ap_throughputGet AP throughput trend (TX/RX over time)
get_top_apsTop APs by bandwidth usage (wireless/wired/total)

Clients

ToolDescription
list_clientsList connected wireless clients (with optional SSID/band filter)
find_client_by_macFind a client by MAC address (direct API lookup)
get_clients_trendClient count trend over time
get_top_clients_by_usageTop clients by bandwidth usage
get_client_mobility_trailClient roaming history

Infrastructure

ToolDescription
list_switchesList all switches
get_site_summaryAggregated site-level summary (AP counts, client counts)
health_checkReport server version and verify Aruba Central authentication (no data fetch)
daily_briefOne-shot morning AP health check: sites whose offline-AP ratio exceeds a threshold

Firmware

ToolDescription
firmware_statusPer swarm: group, site, running versions, recommended version, upgrade status; filter by group, site and/or swarm. With Classic Central configured, also the Classic group, the group's compliance version (what Central upgrades the swarm to next) with its scheduled time, Classic's upgrade state and reason, and Classic-only (stale) swarms
firmware_versionsFirmware versions Classic Central offers for a device type or one swarm (registered only when Classic Central is configured)

Every tool reads; nothing is configured or upgraded. See docs/firmware-api-notes.md for which API reports what.

Highlights

  • Server-side OData filtering for efficient queries
  • OAuth2 Client Credentials authentication (GreenLake SSO)
  • Automatic pagination for large result sets
  • Token auto-refresh before expiration
  • Lightweight: only mcp SDK + httpx (no pandas)

Prerequisites

  • Python 3.10+
  • Aruba Central account with API access (GreenLake New Central API)
  • OAuth2 client credentials (client ID and secret)

Setup

bash
# uvuv pip install aruba-central-mcp
# pippip install aruba-central-mcp

Or run without installing:

bash
uvx aruba-central-mcp

From source:

bash
git clone https://github.com/shigechika/aruba-central-mcp.gitcd aruba-central-mcp
# uvuv sync
# pippip install -e .

Configuration

Set the following environment variables:

VariableDescriptionExample
ARUBA_CENTRAL_BASE_URLAPI gateway URLapigw-uswest4.central.arubanetworks.com
ARUBA_CENTRAL_CLIENT_IDOAuth2 client IDxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ARUBA_CENTRAL_CLIENT_SECRETOAuth2 client secretxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Optional: Classic Central (firmware details)

AOS-8 Instant APs in Classic Central groups are upgraded from Classic Central, and only its API reports why a swarm's upgrade failed, the group compliance version and the versions on offer. Set all four to enable that:

VariableDescription
ARUBA_CLASSIC_BASE_URLClassic API gateway host, apigw-<region>.central.arubanetworks.com
ARUBA_CLASSIC_CLIENT_IDClient id of the API-gateway application
ARUBA_CLASSIC_CLIENT_SECRETIts client secret
ARUBA_CLASSIC_TOKEN_FILEJSON file holding the token pair; this server rewrites it on every refresh

Bootstrap the token file once with the access and refresh token Classic Central's API Gateway issues for that application, readable only by the user the server runs as:

bash
umask 077printf '{"access_token": "%s", "refresh_token": "%s"}\n' "$ACCESS" "$REFRESH" > /path/to/classic-token.json

The refresh token is replaced on every refresh (the old one stops working), so let only this server refresh it, and point every process that runs it at the same file: refreshes are serialised with a lock file next to it. When the refresh token is rejected, health_check reports classic: error and asks for a new pair; when only some ARUBA_CLASSIC_* variables are set it reports classic: misconfigured and names the missing ones. The directory holding the file must be writable by that user (the new pair is written next to it, then renamed); without that, the server refuses to refresh rather than lose the rotated token. Windows has no cross-process lock here, so run one process there.

How to obtain API credentials

  1. Log in to HPE GreenLake Platform
  2. Go to Manage Workspace > Personal API clients
  3. Click Create Personal API client
  4. Enter a nickname and select Aruba Central as the service
  5. Copy the client_id and client_secret — the secret is shown only once

For details, see:

Usage

Claude Code (plugin)

This repository doubles as a single-plugin marketplace, so Claude Code can install the server for you:

/plugin marketplace add shigechika/aruba-central-mcp/plugin install aruba-central-mcp@aruba-central-mcp

The plugin launches uvx aruba-central-mcp and reads the same three environment variables described in Configuration; export them before starting Claude Code. It also passes the four optional ARUBA_CLASSIC_* variables through, so firmware_status gets its Classic details and firmware_versions is offered when they are exported; left unset they arrive empty and Classic stays off.

uvx must be on the PATH of the process that runs Claude Code — a login shell usually has it, but a GUI-launched app may not; install uv system-wide if the plugin fails to start.

Claude Code (manual)

bash
claude mcp add aruba-central \  -e ARUBA_CENTRAL_BASE_URL=apigw-uswest4.central.arubanetworks.com \  -e ARUBA_CENTRAL_CLIENT_ID=your-client-id \  -e ARUBA_CENTRAL_CLIENT_SECRET=your-client-secret \  -- uvx aruba-central-mcp

Or add to .mcp.json:

json
{  "mcpServers": {    "aruba-central": {      "command": "uvx",      "args": ["aruba-central-mcp"],      "env": {        "ARUBA_CENTRAL_BASE_URL": "apigw-uswest4.central.arubanetworks.com",        "ARUBA_CENTRAL_CLIENT_ID": "your-client-id",        "ARUBA_CENTRAL_CLIENT_SECRET": "your-client-secret"      }    }  }}

Claude Desktop

Add to claude_desktop_config.json:

json
{  "mcpServers": {    "aruba-central": {      "command": "uvx",      "args": ["aruba-central-mcp"],      "env": {        "ARUBA_CENTRAL_BASE_URL": "apigw-uswest4.central.arubanetworks.com",        "ARUBA_CENTRAL_CLIENT_ID": "your-client-id",        "ARUBA_CENTRAL_CLIENT_SECRET": "your-client-secret"      }    }  }}

Codex

bash
codex mcp add aruba-central \  --env ARUBA_CENTRAL_BASE_URL=apigw-uswest4.central.arubanetworks.com \  --env ARUBA_CENTRAL_CLIENT_ID=your-client-id \  --env ARUBA_CENTRAL_CLIENT_SECRET=your-client-secret \  -- uvx aruba-central-mcp

Any other MCP client that launches stdio servers works the same way: give it uvx aruba-central-mcp as the command and set the three ARUBA_CENTRAL_* variables in its environment.

Direct execution

bash
export ARUBA_CENTRAL_BASE_URL="apigw-uswest4.central.arubanetworks.com"export ARUBA_CENTRAL_CLIENT_ID="your-client-id"export ARUBA_CENTRAL_CLIENT_SECRET="your-client-secret"python3 -m aruba_central_mcp

CLI Options

bash
aruba-central-mcp --version   # Print version and exitaruba-central-mcp --help      # Show usage and required environment variablesaruba-central-mcp --check     # Verify environment variables and OAuth2 authentication, then exitaruba-central-mcp             # Start MCP server (STDIO, default)

With no options, the process runs as an MCP STDIO server (the mode used by MCP clients).

--check exit codes: 0 success, 1 config error, 2 auth error.

Development

bash
git clone https://github.com/shigechika/aruba-central-mcp.gitcd aruba-central-mcp
# uvuv sync --devuv run pytest -v
# pippython3 -m venv .venv.venv/bin/pip install -e ".[test]".venv/bin/pytest -v

Live smoke test

The unit suite mocks Central at the transport layer, which is what makes it fast — and also what makes it blind to a tool that has stopped returning real data. scripts/smoke_test.py runs every registered tool against the configured tenant and fails on empty, malformed or error answers:

bash
# needs the same ARUBA_CENTRAL_* environment variables as the serveruv run python scripts/smoke_test.pyuv run python scripts/smoke_test.py --only radios --traceback
  • Read-only. Every tool here reads; nothing in Central is configured. A future tool that writes must be listed as state-changing and skipped, and a test enforces that.
  • No payloads in the report. Tool names, statuses and row counts only; error text is redacted too, since an error routinely quotes the device, client MAC or site it was asked about.
  • Nothing network-specific in the specs. The AP, the serial number and the client MAC that the per-device tools need are discovered at run time from the listings, and skipped when the network has none to offer. Two tests keep it that way: one refuses those parameters as literals, the other bans anything address-shaped anywhere in the file, because this repository is public.
  • Empty answers pass for the listings and the time-series tools — a site with no swarms configured is a real deployment — but a lookup handed a name discovered seconds earlier must not come back empty, and those probes say so.
  • CI enforces the cheap half: a tool registered without a probe spec fails the build (tests/test_smoke_probes.py), so adding a tool forces the question "how would we know it works?".
  • scripts/smoke_harness.py is the engine and holds no Central knowledge: it is kept identical across the servers that share it, so fix engine bugs once and sync the file rather than patching this copy.

Its first run found a real one: get_client_mobility_trail was requesting a page size the endpoint rejects, so the tool had been failing for every client.

API Reference

This server uses the GreenLake New Central API:

  • /network-monitoring/v1/aps — Access points
  • /network-monitoring/v1/radios — AP radios
  • /network-monitoring/v1/bssids — BSSIDs
  • /network-monitoring/v1/wlans — WLANs
  • /network-monitoring/v1/swarms — AP swarms/clusters
  • /network-monitoring/v1/switches — Switches
  • /network-monitoring/v1/clients — Clients
  • /network-monitoring/v1/clients-trend — Client count trends
  • /network-monitoring/v1/clients-topn-usage — Top clients by usage
  • /network-monitoring/v1/top-aps-by-usage — Top APs by usage

License

MIT

Source: README.md at commit f5c6931

Tools

18

health_check

Report server version and Aruba Central backend authentication. Call this at session start (or after a tool-call timeout) to confirm the MCP is up, see which version is running, and verify the Aruba Central backend can be authenticated. Lightweight: it builds the client and obtains an OAuth2 access token (GreenLake SSO, reusing the cached token) — it does NOT fetch APs, switches, clients, or any other data endpoint. Always returns the same keys: ``status`` (healthy / degraded / error), ``service``, ``version``, ``base_url`` (the configured ARUBA_CENTRAL_BASE_URL, empty string if unset), ``auth`` (ok / error / missing-env) and ``classic`` (not-configured / ok / error / misconfigured: the optional Classic Central token used by the firmware tools; ``misconfigured`` means some ARUBA_CLASSIC_* variables are set and others are not). ``error`` and ``misconfigured`` make the status degraded and add ``classic_detail``. On a degraded or error result, ``detail`` carries the reason (the New Central one first when both fail).

Takes no parameters.

list_aps

List access points with device-level overview. Use this for AP inventory and availability checks. For RF details (channel, utilization, noise floor), use list_radios instead. Args: site: Filter by site name (exact match, server-side). Empty for all. status: Filter by status (e.g. "ONLINE", "OFFLINE"). Empty for all.

Parameterssitestatus

list_switches

List all switches from Aruba Central. Returns switch name, status, model, type, IP, firmware, and MAC address.

Takes no parameters.

list_clients

List connected wireless clients with connection details. Returns client name, MAC, IP, SSID, band, SNR, connected AP, and auth type. For a single client's full details, use find_client_by_mac instead. Args: ssid: Filter by SSID name (exact match, server-side). Empty for all. band: Filter by wireless band (exact match, server-side). Empty for all.

Parametersbandssid

find_client_by_mac

Look up a single client by MAC address (wireless or wired). Returns detailed info including OS, manufacturer, VLAN, and connection status. Uses direct API lookup (no full-list scan). Args: mac_address: Client MAC address (e.g. "aa:bb:cc:dd:ee:ff").

Parametersmac_addressrequired

get_ap_status

Get detailed status of a specific access point by name. Args: ap_name: AP device name (case-insensitive).

Parametersap_namerequired

get_site_summary

Get a summary of all sites with AP and client counts. Aggregates data across all APs and clients, grouped by site name. Shows total APs, online/offline counts, and client count per site.

Takes no parameters.

list_radios

List AP radios with RF details. Use this for RF troubleshooting: channel assignment, channel utilization, noise floor, and TX power. Each AP typically has 2-3 radios (one per band). Args: site: Filter by site name (exact match, server-side). Empty for all. band: Filter by band (e.g. "2.4 GHz", "5 GHz"). Empty for all.

Parametersbandsite

list_bssids

List all BSSIDs (per-radio, per-SSID broadcast identifiers). Useful for identifying which radio on which AP is broadcasting a specific SSID. Each AP radio broadcasts one BSSID per WLAN. Args: site: Filter by site name (exact match, server-side). Empty for all.

Parameterssite

list_wlans

List configured WLANs (SSIDs) with security and VLAN settings. Shows each WLAN's name, band, operational status, security level, and VLAN assignment. Args: site_id: Filter by site ID. Empty for all. serial_number: Filter by AP serial number. Empty for all.

Parameterssite_idserial_number

list_swarms

List all AP swarms (clusters) from Aruba Central. Returns cluster name, conductor AP, site, IP, and firmware version. Args: site: Filter by site name (exact match, server-side). Empty for all.

Parameterssite

firmware_status

Firmware of every AP swarm (cluster): running versions, upgrade status, group and site. Use this to see which swarms still need a firmware upgrade and what Central will do next. Read-only. The whole call is bounded (about 48 s); what could not be read in time is named under Notes. One line per swarm with its group(s) and site(s), AP count and how many are online, the running versions with AP counts, the recommended version and New Central's per-AP upgrade status (/network-services/v1/firmware-details). APs that belong to no swarm are listed per group and site. When Classic Central is configured (ARUBA_CLASSIC_*), each swarm also gets its Classic group, the group's compliance version (the version Central keeps the group's swarms on: an upgrade of a Classic IAP group happens when the compliance version changes, and ``scheduled`` is when that is set to run; a site-level upgrade in the UI does not change it), marked "matches running" or "pending", and "older than ..." when it is lower than the running or recommended version, plus Classic's upgrade ``state``, ``reason`` and ``upgrade_required``. New Central reports no group for AOS-8 APs, so the group comes from Classic; Classic data is cached per group for a few minutes. Swarms Classic knows but New Central does not (e.g. 0 APs, Down) are listed at the end when no site or swarm filter is given. A Classic failure is reported under Notes; the New Central data is still shown. Filters combine (all must match); each is an exact name, case-insensitive. Empty means no filter. ``group`` uses the Classic group when New Central has none. Args: group: Central group name. site: Site name. swarm_name: Swarm (cluster) name.

Parameterssitegroupswarm_name

get_top_aps

Get top access points ranked by bandwidth usage over a time range. Returns a ranked list of APs sorted by descending bandwidth consumption. Args: usage_type: "wireless" (Wi-Fi traffic), "wired" (uplink traffic), or "total" (wireless + wired combined). Default: "total". site_id: Filter by site ID. Empty for all sites. limit: Maximum number of APs to return (1-25, default 10). start_at: Start time in RFC 3339 format (e.g. "2025-01-01T00:00:00Z"). Max 30 days range. Defaults to 24 hours ago if omitted. end_at: End time in RFC 3339 format. Defaults to current time if omitted.

Parameterslimitend_atsite_idstart_atusage_type

get_ap_throughput

Get throughput trend for a specific AP as a time-series table. Returns timestamped TX/RX throughput in bps. Defaults to last 3 hours. Args: serial_number: AP serial number (use list_aps or get_ap_status to find it). interface_type: "WIRELESS" (Wi-Fi), "WIRED" (Ethernet uplink), or "LTE". start_at: Start time in RFC 3339 format. Defaults to 3 hours ago. end_at: End time in RFC 3339 format. Defaults to current time.

Parametersend_atstart_atserial_numberrequiredinterface_type

get_clients_trend

Get client count trend over time, grouped by a chosen dimension. Useful for capacity planning and usage pattern analysis. Args: site_id: Filter by site ID. Empty for all. site_name: Filter by site name. Empty for all. start_at: Start time in RFC 3339 format (max 1 month range). Must not be in the future. end_at: End time in RFC 3339 format. Must not be in the future. group_by: Dimension to group by. Supported values: - Any client_type: TYPE, ROLE, VLAN - WIRELESS only: WLAN, RADIO, SECURITY, PROTOCOL Default is TYPE. client_type: Client category: ALL, WIRELESS, or WIRED. Default is ALL. Must be WIRELESS when group_by is WLAN, RADIO, SECURITY, or PROTOCOL (the API returns 400 otherwise).

Parametersend_atsite_idgroup_bystart_atsite_nameclient_type

get_top_clients_by_usage

Get top clients ranked by bandwidth usage. Args: site_id: Filter by site ID. Empty for all. site_name: Filter by site name. Empty for all. start_at: Start time in RFC 3339 format (max 1 month range). end_at: End time in RFC 3339 format. limit: Maximum number of clients to return (1-100, default 5).

Parameterslimitend_atsite_idstart_atsite_name

get_client_mobility_trail

Get roaming history for a wireless client as a time-series table. Shows which APs the client connected to, when, and on which SSID. Useful for troubleshooting connectivity issues or tracking movement. Defaults to last 3 hours. Args: mac_address: Client MAC address (e.g. "aa:bb:cc:dd:ee:ff"). start_at: Start time in RFC 3339 format. Defaults to 3 hours ago. end_at: End time in RFC 3339 format. Defaults to current time.

Parametersend_atstart_atmac_addressrequired

daily_brief

Run a morning AP health check across all sites. Fetches all access points and aggregates their online/offline status by site. Sites whose offline AP ratio is *strictly greater than* ``offline_threshold`` percent are flagged as WARNING (uses ``>``, so a site with exactly ``offline_threshold`` % offline is still OK). Args: offline_threshold: Percentage of offline APs that triggers a WARNING (default 10.0). Sites at or below this threshold appear in the OK section. Pass 0.0 to flag any site with at least one offline AP. Output tiers: - CRITICAL — API connection failure - WARNING — offline AP ratio strictly above threshold - OK — offline ratio at or below threshold Returns a Markdown summary with site-level AP counts and anomaly details.

Parametersoffline_threshold

Version history

4
  1. v0.10.2LatestOct 29, 2026
  2. v0.10.1Oct 24, 2026
  3. v0.9.0Sep 29, 2026
  4. v0.8.0Sep 16, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts