UniFi Network MCP Server

Overview Schema Source Related Servers Discussions Admin

List firewall policies

unifi_list_firewall_policies

Read-only

List zone-based firewall policies for a UniFi site, returning rule details, actions, zones, protocols, and metadata to audit or manage traffic filtering.

Instructions

List firewall policies (zone-based rules) at a site. Returns: id, name, enabled, action (object with type field), source/destination (zone reference + trafficFilter), ipProtocolScope, connectionStateFilter, ipsecFilter, schedule, loggingEnabled, reportFlowEnabled (Insights Flows reporting; false on the predefined Allow Return Traffic and Block policies), index, description, metadata (origin SYSTEM_DEFINED/USER_DEFINED/DERIVED, configurable on system policies). action is {type: ALLOW|BLOCK, allowReturnTraffic on ALLOW}. The protocol lives in ipProtocolScope.protocolFilter (NAMED_PROTOCOL or PRESET); ports and addresses live in source/destination.trafficFilter, which is omitted when a side matches the whole zone. Unset optional fields (ipsecFilter, schedule, connectionStateFilter) are omitted, not null. Evaluation order within a zone pair comes from unifi_get_firewall_policy_ordering.

Input Schema

Name	Required	Description
`limit`	No	Number of records to return (API default: 25)
`filter`	No	Filter expression, e.g. metadata.origin.eq('USER_DEFINED') or name.eq('Allow Return Traffic'). Boolean fields (enabled, loggingEnabled, reportFlowEnabled) are not filterable
`offset`	No	Number of records to skip
`siteId`	Yes	Site ID

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. metadata.origin.eq('USER_DEFINED') or name.eq('Allow Return Traffic'). Boolean fields (enabled, loggingEnabled, reportFlowEnabled) are not filterable"

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"
+}
```
addedOutput schema / properties / data / items / properties / reportFlowEnabled
```
Added value: +{
+  "type": "boolean"
+}
```

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

TDQS

A4.1/5.0

Behavior5/5

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

With annotations already covering read-only safety, the description adds substantial behavioral context: return field structure, action shape, where protocol and ports live, that trafficFilter is omitted for whole-zone matches, that unset optional fields are omitted rather than null, and that reportFlowEnabled is false on predefined policies.

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?

The description is front-loaded with the purpose and then spends most of its length on return-shape details. It is dense but mostly earns its place by clarifying nested and omission semantics, though some of that may duplicate the output schema.

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

Completeness4/5

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

For a list tool with full schema coverage, annotations, and an output schema, the definition is largely complete. The main gap is explicit usage guidance relative to unifi_get_firewall_policy and pagination behavior, though those are partly covered by the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the four parameters are already documented in the schema. The description does not add parameter-level meaning beyond what the schema provides, which is the baseline-3 case when structured data does the heavy lifting.

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, resource, and scope: 'List firewall policies (zone-based rules) at a site.' It also distinguishes itself from the ordering sibling by noting that evaluation order comes from unifi_get_firewall_policy_ordering, so an agent can route between list, get, and ordering tools.

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

Usage Guidelines3/5

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

The description implies usage through 'List firewall policies ... at a site,' but never explicitly says when to use this versus unifi_get_firewall_policy or unifi_get_firewall_policy_ordering. It references the ordering tool only for a related concern, not as a direct usage alternative.

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

Deploy Server