io.github.shigechika/aruba-central-mcp

firmware_status

Check AP swarm firmware status by group or site to see running versions, recommended upgrades, and which clusters still need a firmware upgrade.

Instructions

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.

Input Schema

Name	Required	Description	Default
`site`	No
`group`	No
`swarm_name`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.10.1Oct 25, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the whole burden and does: it declares read-only, a ~48s bounded call with partial data surfaced under Notes, per-group caching of Classic data, and graceful degradation when Classic fails. It also discloses ordering behavior (Classic-only swarms appended when unfiltered) — behavior an agent could not infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose and a usage sentence, then detail. It runs long across several paragraphs and repeats the Classic/group interaction (in prose and again under Args), so a little tightening is possible, but no sentence is truly idle.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-filter, no-required-param reporting tool with an output schema, this covers purpose, filters, degraded-mode behavior, caching, and cross-system (Classic vs New Central) semantics. An agent has everything needed to call it and interpret gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description fully compensates: exact-name, case-insensitive matching, AND-combination across filters, empty-string meaning no filter, and the non-obvious rule that group resolves via Classic when New Central reports none. This is meaning an agent cannot get from the bare string properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: firmware of every AP swarm, with running versions, upgrade status, group and site. This is clearly differentiated from siblings like list_swarms (which enumerates swarms rather than firmware posture) and get_ap_status (per-AP rather than per-swarm).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this to see which swarms still need a firmware upgrade and what Central will do next' gives the selecting condition explicitly. It does not name an alternative tool or state exclusions, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server