UniFi Network MCP Server

Overview Schema Source Related Servers Discussions Admin

List WiFi

unifi_list_wifi

Read-only

List all WiFi SSIDs at a UniFi site to inventory broadcasts, status, security type, and frequency bands; filter by enabled state and paginate results.

Instructions

List all WiFi broadcasts (SSIDs) at a site. Returns (sparse list view, live-verified on 11.0.83): id, name (SSID), type (STANDARD/IOT_OPTIMIZED), enabled, metadata.origin, network reference (absent on PPSK SSIDs), securityConfiguration.type, broadcastingFrequenciesGHz, hotspotConfiguration (empty object when set). Booleans such as hideName/bandSteeringEnabled/clientIsolationEnabled, the full security configuration and optional configs are only returned by unifi_get_wifi. Passphrases (securityConfiguration.passphrase, presharedKeys[].passphrase) are returned as "[REDACTED]" unless includeSecrets is true. Use for: SSID inventory. For per-AP radio state (channel, txPower), use unifi_get_device on the AP.

Input Schema

Name	Required	Description
`limit`	No	Number of records to return (API default: 25)
`filter`	No	Filter expression, e.g. enabled.eq(true)
`offset`	No	Number of records to skip
`siteId`	Yes	Site ID
`includeSecrets`	No	Return WiFi passphrases in plaintext instead of "[REDACTED]" (default: false). Only set this when the user explicitly needs the key.

Output Schema

Name	Required	Description	Default
`data`	Yes
`count`	No
`limit`	No
`offset`	No
`totalCount`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv2.15.0Oct 14, 2026

changedInput schema / properties / filter / description

Previous value: -"Filter expression"New value: +"Filter expression, e.g. enabled.eq(true)"

addedInput schema / properties / includeSecrets

Added value: +{
+  "description": "Return WiFi passphrases in plaintext instead of \"[REDACTED]\" (default: false). Only set this when the user explicitly needs the key.",
+  "type": "boolean"
+}

changedInput schema / properties / limit / description

Previous value: -"Number of records to return (default: 25, max: 200)"New value: +"Number of records to return (API default: 25)"

changedInput schema / properties / offset / description

Previous value: -"Number of records to skip (default: 0)"New value: +"Number of records to skip"

addedInput schema / properties / siteId / pattern
```
Added value: +"^[A-Za-z0-9_-]{1,64}$"
```
changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +{}
```
addedOutput schema / properties / data / items / properties / metadata / properties / configurable
```
Added value: +{
+  "type": "boolean"
+}
```

Changed1 schema field changedv2.13.0Sep 20, 2026
- changedInput schema / properties / limit / minimum
```
Previous value: -1New value: +0
```
Addedv2.10.0Jul 29, 2026
Removedv2.9.0Jul 23, 2026
First observedv2.8.0Jun 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial context beyond them: the sparse vs. full field set, version-verified behavior (11.0.83), fields absent on PPSK SSIDs, empty-object semantics for hotspotConfiguration, and passphrase redaction defaulting to "[REDACTED]" unless includeSecrets is true.

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?

Dense but front-loaded: purpose and alternative routing come first, then the field/redaction caveats. The return-field enumeration is lengthy and partly redundant given an output schema exists, but it carries conditional-presence and redaction information that earns most of its space.

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 filtered list tool with full schema coverage, annotations, and an output schema, the description covers everything an agent needs: what it returns, the sparse-vs-full distinction, secret handling, and where to go for adjacent data.

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

Parameters4/5

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

Schema coverage is 100%, so limit/offset/filter/siteId are already documented and the baseline is 3. The description adds genuine meaning for includeSecrets by explaining the redaction default and cautioning to set it only when the user explicitly needs the key — behavior not stated in the schema's own description.

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?

States a specific verb and resource: 'List all WiFi broadcasts (SSIDs) at a site.' It immediately distinguishes itself from unifi_get_wifi (the full/detailed view) and unifi_get_device (per-AP radio state), so an agent can route correctly without opening a schema.

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

Usage Guidelines5/5

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

Explicit 'Use for: SSID inventory' plus named alternatives for adjacent needs: unifi_get_wifi for full config, unifi_get_device on the AP for channel/txPower. This is real when-to-use/when-to-use-something-else routing, not implied guidance.

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

Deploy Server