Skip to main content
Glama
shigechika

io.github.shigechika/aruba-central-mcp

by shigechika

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ARUBA_CENTRAL_BASE_URLYesAPI gateway URL
ARUBA_CENTRAL_CLIENT_IDYesOAuth2 client ID
ARUBA_CENTRAL_CLIENT_SECRETYesOAuth2 client secret

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
health_checkA

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

list_apsA

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.

list_switchesB

List all switches from Aruba Central.

Returns switch name, status, model, type, IP, firmware, and MAC address.

list_clientsA

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.

find_client_by_macA

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").

get_ap_statusB

Get detailed status of a specific access point by name.

Args: ap_name: AP device name (case-insensitive).

get_site_summaryA

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.

list_radiosA

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.

list_bssidsA

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.

list_wlansA

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.

list_swarmsA

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.

firmware_statusA

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.

get_top_apsA

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.

get_ap_throughputA

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.

get_clients_trendA

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

get_top_clients_by_usageA

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

get_client_mobility_trailA

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.

daily_briefA

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 18 tools

Disambiguation4/5

Most tools have clearly distinct resource/action targets, and several descriptions explicitly cross-reference alternatives such as list_aps vs list_radios. A few pairs still have soft boundaries: list_aps vs get_ap_status, and get_site_summary vs daily_brief.

Naming Consistency4/5

Names are consistently snake_case and mostly follow list_/get_/find_ verb_noun patterns. The report-style names health_check, firmware_status, and daily_brief are minor deviations but remain readable and clear.

Tool Count4/5

At 18 tools the server is above the typical 3-15 sweet spot, but the broad Aruba Central monitoring domain justifies a fairly wide surface. Most tools cover a distinct resource or analytical view, so the count does not feel bloated.

Completeness4/5

The toolset covers core read-only monitoring well: AP/client/switch/WLAN inventory, RF details, throughput and client trends, firmware status, health checks, and site summaries. Minor gaps remain around alerts/events, per-switch port detail, and configuration-changing operations if those are in scope.

Maintenance

ActivityActive
ResponsivenessUnresponsive