Skip to main content
Glama
mgcrea
by mgcrea

UniFi: List Firewall Policies

unifi_list_firewall_policies
Read-only

List zone-based firewall policies with actions, zones, and match criteria. Pass source and destination zone IDs to see the actual evaluation order, preventing risky changes that could lock you out.

Instructions

List the zone-based firewall policies on a site, with their action, source and destination zones, matching criteria and whether each is enabled. Policies are evaluated in order, so pass sourceZoneId and destinationZoneId to see the ordering that actually applies between one pair of zones. Read-only, deliberately: a wrong policy can lock you out of the console with no undo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteNoWhich site to act on. Accepts the site UUID, its `internalReference` (the legacy 8-character name, usually "default") or its display name ("Default") — all three are resolved for you, so a guess costs nothing. Defaults to UNIFI_SITE, or to the only site when this console has just one. `unifi_list_sites` shows all three for every site.
limitNoMaximum items to return (1-200; the console rejects more). Defaults to UNIFI_PAGE_LIMIT (50). Prefer narrowing with `filter` over raising this — the console filters server-side, so a filtered request is both smaller and faster than a large page read here.
filterNoRaw server-side filter expression, applied by the console before it answers — much cheaper than fetching pages and filtering here. Syntax: `property.function(value)`, combined with `and(...)`, `or(...)` and `not(...)`. Strings take single quotes (double an embedded quote to escape it); `*` is the wildcard in `like`. Functions: eq, ne, gt, ge, lt, le, like, in, notIn, isNull, isNotNull, contains, containsAny, containsAll. Examples: `state.eq('OFFLINE')`, `firmwareUpdatable.eq(true)`, `and(type.eq('WIRED'),name.like('*lab*'))`. The structured arguments on this tool build the common expressions for you — use this only for what they cannot express, and do not pass both.
sourceZoneIdNoZone `id` from `unifi_list_firewall_zones`. Pass with `destinationZoneId` to get the evaluation order between that pair rather than the flat list.
destinationZoneIdNoZone `id` from `unifi_list_firewall_zones`. Pass with `sourceZoneId`.
Behavior5/5

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

The annotations already declare readOnlyHint=true, and the description reinforces this with a behavioral warning: 'Read-only, deliberately: a wrong policy can lock you out of the console with no undo.' It also discloses the evaluation-order behavior, adding meaningful context beyond the annotation. No contradiction exists.

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

Conciseness5/5

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

Three sentences, front-loaded with the primary action and return contents, then the key ordering behavior and a safety caveat. Every sentence earns its place; there is no redundant 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?

With no output schema, the description compensates by listing what the response contains. It also explains evaluation ordering, the purpose of the two zone parameters, and the safety rationale for read-only use. Combined with the fully documented parameters, an agent has everything needed to call the tool correctly.

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 schema already fully documents each parameter. The description adds a brief behavioral note about ordering with sourceZoneId and destinationZoneId, but most parameter meaning is already carried by the schema. This meets the baseline for high schema coverage.

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?

The description states a specific verb and resource: 'List the zone-based firewall policies on a site', and enumerates the returned attributes (action, source/destination zones, matching criteria, enabled state). It clearly differentiates from siblings like unifi_list_firewall_zones by focusing on policies rather than zones.

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?

The description gives clear context on when to use the zone-pair parameters ('Policies are evaluated in order, so pass sourceZoneId and destinationZoneId to see the ordering') and signals a safe read-only usage context. It does not explicitly name alternative tools or exclusion conditions, but the usage context is strong enough for an agent to decide correctly.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mgcrea/mcp-unifi-network'

If you have feedback or need assistance with the MCP directory API, please join our Discord server