unifi-console-mcp

Overview Schema Source Related Servers Discussions Admin

unifi_console_wifi

Destructive

Preview and apply changes to a UniFi Wi-Fi network (SSID), with a read-only diff first, then confirm to create, update, enable, disable, or delete it.

Instructions

Preview, then apply, a change to a Wi-Fi network (SSID). Tier C: changes drop the clients on it.

Two steps, always: confirm=false returns a read-only preview (before, after, diff, the clients connected now, warnings, errors, a fingerprint); then call again with the same fields plus confirm=true, that fingerprint and an approval_note. A new SSID is created disabled. The passphrase is never an argument: pass passphrase_env, the name of a UNIFI_WIFI_* environment variable in the server's environment; it is write-only and is not read back, previewed or journalled. Changes that force clients to reconnect, and deletes, are refused while clients are connected unless acknowledge_disconnect=true; open security needs acknowledge_open=true. There is no automatic restore. Applying also needs UNIFI_CONSOLE_ENABLE_WRITES=true and 'wifi' in UNIFI_CONSOLE_WRITE_ENTITIES. Every write is journalled.

Input Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructive/non-idempotent, but the description adds substantial context beyond them: no automatic restore, new SSIDs created disabled, passphrase is write-only via passphrase_env and never previewed/journalled, every change is journalled, and writes require UNIFI_CONSOLE_ENABLE_WRITES plus entity allow-listing.

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-loads the one-line purpose, then the 'Two steps, always' rule, then constraints. Dense but each sentence carries operational information; some clauses could be tightened but nothing is filler.

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 destructive, multi-step write tool with an output schema present, the description covers the workflow, fingerprint chaining, prerequisites, and irreversibility. Return-format details are unnecessary given the output schema, so nothing critical is missing.

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?

With reported 0% schema coverage, the description carries the burden and does so for the key semantic parameters: confirm, fingerprint, approval_note, passphrase_env, acknowledge_open and acknowledge_disconnect are all explained in prose. It is not exhaustive (e.g. bands, pmf_mode, l2_isolation are not explained), so a 4 rather than 5.

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 ('Preview, then apply, a change to a Wi-Fi network (SSID)') and the annotation title enumerates create/change/delete. It is clearly distinguishable from siblings like unifi_console_network or unifi_console_wan, which operate on other resources.

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?

Gives explicit when-to-use guidance for the two-step flow (confirm=false for preview, then confirm=true with fingerprint and approval_note) and names the conditions that gate the write (acknowledge_disconnect, acknowledge_open). It does not name or route away to any sibling tool, so it stops short of full alternatives coverage.

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