unifi-console-mcp

Overview Schema Source Related Servers Discussions Admin

unifi_console_qos_rule

Destructive

Preview and apply changes to UniFi console QoS rules: set bandwidth limits or prioritization, toggle rules, and delete them with fingerprint verification and rollback.

Instructions

Preview, then apply, a change to the console's QoS rules (the dashboard's QoS widget; Traffic Management objects use unifi_console_traffic_object instead).

Two steps, always: call with confirm=false to get a read-only preview (before, after, diff, warnings, a fingerprint); call again with the same fields plus confirm=true and that fingerprint to apply. The rule is re-read first, so a stale preview is refused. A rule names a WAN or VPN link (wan_network), the clients it covers (source_clients, MAC addresses), the applications it matches (destination_apps, application ids), and an objective: LIMIT (download_limit / upload_limit in kbit/s, 10000 = 10 Mbit/s, with download_burst / upload_burst OFF, SHORT or LONG) or PRIORITIZE (no limits). Other source and destination types and schedules other than ALWAYS have not been captured and are not edited. A new rule starts switched off unless enabled=true; once enabled it takes effect at once. Use action enable or disable to switch one. Applying also needs UNIFI_CONSOLE_ENABLE_WRITES=true and 'qos_rule' in UNIFI_CONSOLE_WRITE_ENTITIES. The console only accepts the whole rule, so updates send all of it. After applying, the rule is read back and the result reports verified true/false, the diff, and the exact rollback call. Every write is journalled. Delete uses the console's batch-delete call.

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.9/5.0

Behavior5/5

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

Annotations only give coarse hints (destructive, non-idempotent, non-readonly). The description adds substantial context: the rule is re-read so a stale preview is refused, a new rule starts switched off unless enabled=true, the console requires the whole rule so updates resend everything, verification returns verified true/false plus a rollback call, and every write is journalled. This is exactly the kind of behavior an agent cannot infer from annotations.

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 two-step workflow and the sibling disambiguation before the field-level detail, and essentially every sentence carries operational weight. It is dense and long, but the density is justified by the tool's complexity; a slight trim of the enumeration would not lose meaning.

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?

With an output schema present, return values need not be restated, and the description nonetheless clarifies that the result reports verified status, diff, and rollback call. Combined with the write prerequisites, staleness handling, and delete behavior, an agent has everything needed to invoke this correctly.

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 description coverage is reported at 0%, so the description must carry the load, and it does: it explains wan_network (WAN or VPN link), source_clients (MAC addresses), destination_apps (application ids), units for download_limit/upload_limit (kbit/s, 10000 = 10 Mbit/s), burst semantics (OFF/SHORT/LONG), and objective behavior (LIMIT caps, PRIORITIZE has no limits). It also flags which raw fields are replay-only.

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 the console's QoS rules') and immediately disambiguates from the nearest sibling by naming unifi_console_traffic_object for Traffic Management objects. An agent can tell this apart from the other unifi_console_* tools without opening any 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?

Spells out the mandatory two-step flow (confirm=false preview, then confirm=true with the same fingerprint) and when to use each action (create, update, enable/disable, delete). It also names the prerequisite toggles (UNIFI_CONSOLE_ENABLE_WRITES, 'qos_rule' in UNIFI_CONSOLE_WRITE_ENTITIES) so the agent knows the conditions under which a write will even be accepted.

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