mcp-unifi-network

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation4/5
Most tools are clearly distinct: unifi_list_devices vs unifi_get_device vs unifi_get_device_stats are well separated, as are unifi_list_clients vs unifi_get_client. The main overlap is unifi_auth_status and unifi_get_console_info, which both report console version and capability information, so an agent could select the wrong one in that situation.
Naming Consistency5/5
Every tool uses the unifi_ prefix and follows a predictable verb_noun pattern: list_* for collections, get_* for single resources or status, with auth_status and request as understandable deviations. The naming is highly consistent and makes the tool surface easy to navigate.
Tool Count5/5
Fourteen tools is well within the ideal range for a domain-specific server. The count feels scoped to the UniFi Network domain without bloat, and unifi_request prevents the need to wrap every possible endpoint in a dedicated tool.
Completeness4/5
The read-only surface covers the main network observability needs: devices, clients, networks, WLANs, vouchers, firewall zones and policies, sites, and console status. The unifi_request escape hatch fills gaps for unmodeled GET endpoints, but write operations are deliberately absent, and there is no event or alarm listing, so it is not fully comprehensive for every UniFi workflow.
Average 4.4/5 across 14 of 14 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering the safety profile, the description adds genuine behavioral value: it discloses that expired vouchers are not deleted automatically and will still appear in results, which an agent would not otherwise assume. It also previews the return content, giving the agent expectations for what a successful call yields without an output schema.
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?
Two sentences with zero waste. The first sentence front-loads the purpose and return fields; the second delivers the expiry gotcha and the corrective filter. Both sentences earn their place, and information density is high without becoming a wall of text.
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 read-only list operation with zero required parameters, a complete schema, and a safety annotation, the description covers the essentials: what is returned, the key behavioral caveat (expired vouchers persist), and the filter that addresses it. Minor gaps — no explicit ordering, pagination hint beyond what the limit param already states — are negligible given the schema richness.
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 coverage is 100% and the schema's own parameter descriptions are exceptionally rich (site resolution across three forms, full filter-expression syntax, limit defaults and rejection behavior). The main description adds only the `expired: false` hint, which largely restates the schema's 'false for still-valid ones.' The schema carries the weight here, so baseline 3 is appropriate.
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 opens with a specific verb and resource — "List the hotspot guest vouchers on a site" — and enumerates the returned fields (code, name, time/data limits, guest usage count, activation/expiration). This clearly distinguishes it from sibling list tools like unifi_list_clients, unifi_list_devices, and unifi_list_sites, all of which target different resources.
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 gives conditional filtering guidance ('filter with `expired: false` for the ones still usable') and explains why the filter is needed, which is useful context for when to apply it. However, it never names alternatives or states when NOT to use this tool versus a sibling list tool or unifi_request, leaving tool-selection reasoning mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is reinforced and enriched by the explanation that 'a bad SSID change takes every wireless client offline at once,' which gives the agent a concrete consequence justifying the safety profile. It also discloses the shape of the result (fields returned), which the annotations and output schema do not provide.
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?
Two sentences, zero waste: the first front-loads the action and return fields, the second justifies the safety posture. Every clause earns its place, and the read-only rationale is placed after the purpose rather than obscuring it.
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 simple read-only list tool, the package is complete: annotations cover the safety profile, parameter docs cover invocation details, and the description enumerates the return fields in the absence of an output schema. Only a minor gap exists around the exact response shape/pagination behavior, which the limit parameter largely covers.
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% and each parameter is richly documented (site name resolution, limit bounds with server rejection, full filter syntax with examples). The main description adds no parameter information, so the baseline of 3 applies — the schema does the heavy lifting and there is no gap to compensate for.
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 WiFi broadcasts (SSIDs) on a site' — and enumerates the distinguishing return fields (bridged network, security mode, band, enabled state). This clearly separates it from sibling list tools like unifi_list_networks and unifi_list_clients without needing to open 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The domain of use is implied ('this is the tool for SSIDs'), and the phrase 'same reason as networks' obliquely connects it to a sibling tool's rationale. However, it never explicitly states when to choose this over unifi_list_networks or other list tools, and offers no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as read-only, and the description adds meaningful context: this server intentionally cannot modify networks because a wrong subnet or VLAN id would disconnect every client with no undo. This explains why the tool is constrained and reinforces safe behavior beyond the annotation.
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?
The description is compact and front-loaded: the first sentence defines purpose and output, and the second justifies the read-only constraint. No sentence is wasted, and the safety rationale earns its place.
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 read-only list tool with no output schema, the description provides enough return-value context by naming the key fields, and the schema fully documents all three parameters. There is no missing information an agent needs to select and invoke this 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 coverage is 100%, and each parameter has a rich description covering accepted formats, defaults, bounds, and filter syntax. The tool description itself adds no additional parameter semantics, so the schema carries the full burden, matching 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 action ('List') on a specific resource ('networks (VLANs) configured on a site') and enumerates the returned fields: name, VLAN id, subnet, DHCP settings, and purpose. This clearly distinguishes the tool from siblings like unifi_list_wlans by scoping it to wired/VLAN networks.
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 gives useful context by calling the operation read-only and directing modifications to the UniFi UI, but it does not explicitly name sibling tools or state when to prefer this tool over alternatives such as unifi_list_sites or unifi_list_wlans. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds useful behavioral context: this is a live snapshot, not history, and filtering is performed on the console for cost efficiency. It does not cover rate limits or auth, but the annotation plus the cost-oriented note are sufficient for this read-only listing tool.
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 dense sentences with no filler. The core scoping is front-loaded, the output fields are summarized, and the filtering cost behavior is stated in one efficient sentence. Every sentence earns its place.
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?
With no output schema, the description partially covers the return shape by listing the fields each entry carries. The rich parameter schema handles invocation details, and the filtering behavior is explained. Exact pagination or response envelope details are not stated, but for an optional-parameter list tool this is nearly complete.
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 documents every parameter well. The description adds general context about server-side filtering and mention of the client id being reused by other tools, but it does not need to repeat per-parameter semantics. Baseline 3 is appropriate.
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 uses a specific verb and resource: 'List the clients currently connected to a site', and adds a clear distinction from the historical list. It also identifies what each entry contains, making the tool's purpose unambiguous and distinct from unifi_get_client and unifi_list_devices.
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 clearly frames when this tool is appropriate: for current network clients, not historical records, and it notes that server-side filtering is cheaper than fetching pages and discarding data. It does not explicitly name sibling alternatives and when to prefer them, but the context is strong enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint already present, the description adds useful behavioral context by explaining what the call returns: the full session detail, including uplink device and guest-access state. It does not cover stale-ID error behavior, but that is a minor gap for a simple read operation.
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?
The description is two sentences with no filler. It front-loads the action and identifier source, then adds a compact but valuable summary of the return payload.
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 simple read-only get-by-id tool with thorough schema documentation and a readOnlyHint annotation, the description is complete. It explains what it returns and the provenance of the required id, and no output schema is needed because the return behavior is summarized clearly.
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%, and both parameters are already fully documented in the schema, including the UUID-not-MAC caveat and site alias resolution. The tool description adds little beyond reinforcing the id-from-list relationship, so the baseline of 3 is appropriate.
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 ('Get'), a precise resource ('one connected client'), and the key identifier source ('from unifi_list_clients'). It clearly distinguishes this single-item lookup from the list-oriented sibling tools like unifi_list_clients.
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 and clientId parameter make the intended workflow clear: first call unifi_list_clients, then pass the returned id to this tool. It does not explicitly name alternatives or exclusions, but the 'list first' guidance and read-only nature provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation, and the description builds on that by clarifying the depth of data returned and its relationship to the list variant. It does not disclose behavior for missing devices, but for a read-only get-by-id tool the annotation plus the detail is adequate.
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?
One well-structured sentence front-loads the core action and resource, then adds specific differentiators and the sibling comparison. Every clause earns its place with no filler or redundancy.
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 simple read-only fetch tool with only one required parameter, the description plus the rich schema and readOnlyHint fully covers what an agent needs: which id to pass, which site semantics apply, and what richness to expect in the response.
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% and each parameter already has a rich description: site resolution rules and the deviceId's origin and format. The tool description adds no parameter-level meaning, but it does not need to because the schema carries the full burden.
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: 'Get one adopted device in full.' It also distinguishes itself from unifi_list_devices by naming the exact fields it adds (features, interfaces, uplink, adoption timestamps), making the purpose unmistakable.
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 clearly implies when to use this tool: when you need the full single-device payload that unifi_list_devices trims away. It names the alternative tool and what differentiates them, though it stops short of explicitly stating excluded cases such as 'use unifi_list_devices for summary lists.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses a non-obvious behavioral trait: the returned data is the console's current snapshot and no history endpoint exists. This tells the agent the result will not be a time series and the API cannot fulfill historical requests. This is exactly the kind of extra context that helps invocation.
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?
Two sentences with no filler. The first sentence front-loads the tool's purpose and payload; the second adds a crucial caveat about snapshot-only semantics. Every sentence earns its place and the scope is instantly clear.
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 simple read-only telemetry tool, the combination is complete: schema explains both parameters, annotations mark it read-only, and the description states what data is returned and that it is snapshot-only. Without an output schema, the description still gives the agent enough understanding of the returned fields to invoke 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 explains deviceId (UUID from unifi_list_devices, not MAC/name) and site (three accepted forms, defaulting behavior, and unifi_list_sites reference). The description adds no parameter information, but with full schema coverage, baseline 3 is appropriate.
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 uses a specific verb and resource: 'Get a device's latest telemetry', and enumerates exactly which metrics are included (uptime, CPU/memory utilization, load averages, uplink throughput, per-radio retry rates). It also distinguishes the tool from history/time-series endpoints and from generic device retrieval siblings like unifi_get_device.
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?
'This is the current snapshot the console holds, not a time series — there is no history endpoint in this API' clearly tells the agent when this tool is not appropriate (when historical data is needed), while the 'latest telemetry' wording implies its intended use. It stops short of naming explicit alternative tools for historical queries, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms it reports/checks rather than mutates. It adds valuable context beyond the flag: it describes what is probed (reachability, transport, site, Network version) and that it returns settings guidance when something is missing. No hidden side effects or auth requirements are disclosed, but read-only is already covered.
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?
Two sentences, each serving a distinct purpose: the first enumerates the report content, the second gives an actionable usage directive. The most important usage hint is placed at the start of the second sentence, with minimal waste.
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 zero-parameter, read-only diagnostic with no output schema, the description fully covers what the tool does, when to use it, and what it reports. It even includes edge-case interpretation (absent tool = older console/missing config), so an agent has enough to invoke it correctly.
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 zero parameters and vacuous 100% schema coverage, there are no parameter semantics for the description to add. The baseline for a no-parameter tool is 4.
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 ('Report') and resource (connectivity/auth status to a UniFi console), and enumerates the exact facts it returns: transport, site, Network version, and remediation. This distinguishes it from sibling data-fetching tools like unifi_list_clients and from unifi_request.
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?
Explicitly directs the agent to 'Call this FIRST whenever a tool you expected is not in the list,' and explains the reason (endpoints depend on console version). This gives a clear decision rule for when to use this tool instead of assuming an API bug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is established. The description adds meaningful behavioral context beyond the annotation: it explains the API version dependency, that older consoles will have missing tools, and that this tool names required versions and gated capabilities. This helps the agent anticipate failures in related tools.
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?
The description is three sentences with no filler. The core purpose is front-loaded, the version-context sentence explains why the tool exists, and the final sentence provides a clear call-to-action. Every sentence earns its place.
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 zero-parameter, read-only diagnostic tool with no output schema, the description is complete. It states what the tool reports, why the information matters, and exactly when an agent should invoke it. There are no missing inputs, side effects, or complex output expectations to clarify.
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?
The tool has zero parameters, and the schema is empty, so the description carries no parameter burden. The baseline for zero-parameter tools is 4, and the description appropriately explains the tool's purpose without inventing unnecessary parameter details.
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 clearly states the tool reports the console's UniFi Network version and its supported tool set, using a specific verb and resource. It is immediately distinguishable from sibling tools that operate on clients, devices, sites, or networks, as this is a meta-tool about the console's capabilities.
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?
The description gives explicit usage conditions: call when a tool is missing or returns 404, and explains why (older consoles lack endpoints introduced in Network 10.0). This is direct, actionable guidance for an agent to decide when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile; the description adds the behavioral disclosure that nested features/interfaces blocks are omitted and points to unifi_get_device for the full object. It does not contradict the annotation and provides useful response-shape context beyond it.
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, each earning its place: the core function, two high-value use cases, and the important omission/alternative note. The core purpose is front-loaded and there is no repetition of schema content.
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 still tells the agent what fields come back and what is deliberately omitted. The 100%-documented schema covers all six parameters and the annotations cover read-only safety, so nothing an agent needs to invoke this correctly 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?
Schema coverage is 100% with unusually rich per-parameter descriptions, so the baseline is 3. The description adds practical task-to-parameter mappings (firmwareUpdatable for upgrade hunting, state OFFLINE for downtime triage) that go slightly beyond the schema's own text.
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 names a specific verb and resource — "List the UniFi devices adopted by a site" — and enumerates the device types (access points, switches, gateways) and returned fields (state, model, IP, MAC, firmware). It also distinguishes itself from unifi_get_device by noting the omitted nested blocks, so an agent can tell the two apart without opening schemas.
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?
It gives task-oriented guidance — "Use firmwareUpdatable: true to find what needs upgrading, or state: 'OFFLINE' to find what is down" — and explicitly routes the complete-object case to unifi_get_device. The alternative and the condition that selects it are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although readOnlyHint is already true, the description adds meaningful behavioral context: it clarifies the tool's read-only relationship to firewall configuration, tells the agent to make changes elsewhere, and explains why (mistakes can be undone before locking you out). This goes well beyond the annotation and helps the agent reason about safety and workflow.
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 accomplish a lot: definition, workflow relationship to a sibling tool, and a safety-oriented usage exclusion. The most important information is front-loaded, and every sentence earns its place with no filler or repetition.
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 simple list tool with zero required parameters, 100% schema coverage, and a read-only annotation, the description is complete. It explains what the tool returns conceptually (zones with ids), how those ids feed into unifi_list_firewall_policies, and where modifications should happen. No material gap remains for an agent to call it 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 input schema already fully documents site, limit, and filter with detailed descriptions. The main tool description adds no parameter-level information, which is acceptable given the schema's thoroughness. Baseline 3 applies because the schema carries the burden.
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 opens with a specific verb and resource: 'List the firewall zones on a site.' It further defines what these zones are ('named groups of networks') and distinguishes this tool from the related unifi_list_firewall_policies by explaining that zones are referenced by id in policies. This makes the tool's purpose immediately distinguishable from its siblings.
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?
The description gives explicit usage guidance: 'Read these first' before reading policies, since the zone ids are needed to make unifi_list_firewall_policies readable. It also states a clear exclusion — this server never creates or modifies firewall configuration and such changes should be made in the UniFi UI — so an agent knows when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the safe read-only nature. The description adds meaningful context beyond that by explaining what the returned identifiers are used for (API paths vs legacy tools), which helps the agent interpret results correctly. No contradiction with annotations.
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?
The description is two sentences with no fluff. The main action and purpose appear first, followed by precise identifier semantics and usage guidance. Every sentence earns its place.
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 zero-parameter, read-only list tool with no output schema, the description fully covers what will be returned and why it matters. It gives the agent enough to know when to invoke this tool and how to use the results.
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?
The tool has no parameters, so there is nothing to document. The description appropriately focuses on the return values instead, which is the most useful semantic information an agent needs here.
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 ('List') and resource ('sites on this console') plus the key output detail: all three identifiers. It clearly distinguishes this from sibling list tools that target clients, devices, networks, etc.
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?
The description explicitly explains when this tool is needed: when a site cannot be resolved or when the legacy internalReference name is required. It also clarifies that every other tool accepts any of the three identifiers, so the agent can decide when listing sites is actually necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds concrete behavior beyond that: only GET is permitted, site names are not resolved, and UNIFI_ALLOW_WRITES=1 changes the behavior and registers purpose-built write tools. There is no contradiction.
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 dense sentences deliver purpose, scope, path rules, UUID requirements, and write behavior without filler. The escape-hatch concept is front-loaded, and every sentence contributes meaningful guidance.
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 an intentionally open-ended raw API tool with no output schema, the description gives all invocation-critical information: scope, relative path format, UUID prerequisite, method restriction, and the environment-variable switch for writes. No obvious required detail 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?
Schema coverage is 100%, so the baseline is already strong. The description adds one crucial parameter-level insight beyond the schema: paths are API-root-relative, not full URLs, and the site must be a real UUID because name resolution is not performed. This is above baseline but not exhaustive across all parameters.
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: 'call any Integration API endpoint directly,' and scopes it to 'the parts of the API this server does not wrap.' This cleanly distinguishes the tool from the sibling wrapper tools without requiring the agent to inspect them.
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?
It explicitly says when to use the escape hatch — for unwrapped endpoints — and provides examples. It also warns that site names are not resolved and directs the agent to `unifi_list_sites` first, plus it explains the write-disabled default and how to enable mutations while pointing to purpose-built write tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-unifi-network MCP server](https://glama.ai/mcp/servers/mgcrea/mcp-unifi-network/badges/card.svg)](https://glama.ai/mcp/servers/mgcrea/mcp-unifi-network)

Score Badge

Copy to your README.md:

[![mcp-unifi-network MCP server](https://glama.ai/mcp/servers/mgcrea/mcp-unifi-network/badges/score.svg)](https://glama.ai/mcp/servers/mgcrea/mcp-unifi-network)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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