py-unifi-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: networks, sites, devices, clients, health, device telemetry, device rename, and device locate. There is no meaningful overlap or confusion between tool purposes.
Naming Consistency5/5
All tools use the unifi_ prefix followed by a clear verb_noun pattern such as list_networks, get_health, rename_device, and locate_device. The naming is uniform and predictable across the entire set.
Tool Count5/5
Eight tools is well-scoped for a UniFi controller MCP server covering inventory lookup, status checks, and common device actions. Each tool serves a clear purpose without unnecessary bloat.
Completeness4/5
The tool set covers core UniFi operations well: listing sites, networks, devices, clients, checking health, and retrieving device details. Minor gaps exist, such as no network configuration or additional device management actions, but the main workflows are represented.
Average 4/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
The description adds a meaningful behavioral nuance beyond the annotations: 'missing metrics are unknown, not healthy.' This prevents an agent from falsely treating absent data as a positive health signal, which is valuable interpretive context that the readOnly/idempotent annotations do not convey.
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 a single front-loaded sentence with no wasted words: it names the operation first and then delivers the key caveat. It is succinct without losing substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the tool's purpose and the most important interpretive caveat, and an output schema exists to document return values. However, it leaves parameter semantics entirely undocumented, especially 'site' and pagination behavior, so the definition is not fully complete on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the burden of explaining the three parameters (site, limit, offset), but it does not mention any of them. The parameter names and constraints offer some clue, yet the description adds no meaning beyond what is already visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Read') and a specific resource ('subsystem health'), making the tool's purpose unambiguous and distinct from the sibling list/get/resource tools. It doesn't explicitly name a sibling alternative, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to prefer this tool over alternatives, nor any preconditions or context such as which site it applies to or how the health data should be interpreted operationally. The only signal is the verb 'Read', leaving usage entirely to inference.
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 description adds valuable behavioral facts beyond the annotations: the locate is not auto-stopped, stopping requires enabled=False, LED state is not verified afterward, and execution requires explicit user intent and an API key. These are precisely the kind of caveats an agent needs and are not present in the 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 short and front-loaded with the main action, followed by a prerequisite and the critical behavioral caveats. Each sentence contributes meaningful information, and the paragraph break separates the core summary from operational warnings effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the behavioral caveats are strong, the description is incomplete for the tool's four parameters, especially dry_run and site. With zero schema description coverage, an agent cannot confidently know how to set dry_run or whether site is required in practice. The output schema existing reduces return-value concerns, but parameter guidance remains insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies the semantics of enabled ('use enabled=False to stop') and implicitly that true starts locating. It says nothing about device_id, site, or dry_run, leaving most parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: LED locate start/stop. It is clearly distinct from the sibling list/get/rename tools. The word 'Preview' adds some ambiguity about whether the tool actually executes or only simulates, but the overall purpose is identifiable.
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 operational guidance by saying 'use enabled=False to stop', which tells the agent how to stop a locate session. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it. The prerequisite about user intent and API key is useful context but not a usage-scoping guideline.
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, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: site defaults to UNIFI_SITE, and offset/limit only bound the returned tool output rather than the controller fetch. This clarifies pagination expectations and helps an agent understand the tool's non-destructive, read-only nature.
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 extremely lean and front-loaded: the first sentence states the core purpose, and the second adds concise behaviorally relevant detail. There is no repetition of schema metadata and no filler, so 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?
For a simple read-only list tool with only three optional parameters, safety annotations, and an output schema, the description provides enough invocation context: tool purpose, default site, and pagination semantics. The main omission is guidance for choosing among sibling tools, but the output schema covers return-value details and annotations cover read-only behavior, so the definition is still reasonably 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?
With 0% schema description coverage, the description must compensate for parameter meaning. It partially does so by stating the site default and clarifying that offset/limit constrain tool output, not the controller fetch. However, it does not explain the semantics of a null site, what values are appropriate for site, or the practical meaning of limit/offset beyond the schema's numeric constraints.
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 verb 'List' and the resource 'device inventory,' with the extra detail 'raw state codes' distinguishing this as an inventory-oriented list tool. The resource name differentiates it from sibling tools like unifi_list_networks, unifi_list_sites, and unifi_list_clients. Minor vagueness in 'raw state codes' does not obscure the overall purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as unifi_get_device for a single device or unifi_list_clients for client inventories. The notes about site defaults and offset/limit describe invocation behavior, not selection criteria, so an agent receives little help choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive behavior, so the description is not required to repeat those. It adds value by revealing that only 'allow-listed' telemetry is returned, and that the operation is scoped to a site. It does not go into error handling or data completeness, but that is acceptable given the annotation coverage.
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 entire description is one concise sentence with no filler or redundant restatement of the tool name. It opens with the action verb and places the key qualifier ('one exact device ID') immediately after the object.
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?
The tool is a simple single-device read operation, and the output schema plus annotations cover return values and safety. The description provides the essential selection criteria and scope. It could improve by clarifying 'allow-listed' or referencing a prior list step, but these are not blockers.
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 0%, so the description must carry meaning for parameters. It adds that device_id must be an exact ID (not a name or partial match) and that site refers to the selected site. It does not explain the optionality/null behavior of site, but the schema's pattern fields already provide technical constraints.
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 ('Get') and identifies the resource ('telemetry for one exact device ID'), making the action unmistakable. The singular 'one exact device ID' clearly separates it from sibling listing tools like unifi_list_devices. The 'allow-listed' qualifier is slightly jargon-heavy but does not obscure the core purpose.
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 states the precise condition for use: the caller must have an exact device ID. This implies it is the wrong choice for listing or bulk operations, though it does not name alternatives or when-not-to-use cases. The mention of 'selected site' also signals that site scope is relevant, but it stops short of explicit routing.
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 destructiveHint=true, and the description reinforces and extends this by disclosing the dual preview/execute mode (dry_run defaults to True), the requirement for explicit user consent before executing, and API key authentication. This adds meaningful behavioral context beyond the structured annotations without contradicting them.
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 short sentences with zero wasted words. The core behavior (preview/rename) is front-loaded, followed by the execution gate and prerequisite. Every clause 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?
The output schema covers return values, and the description carries the essential operational facts: default preview mode, explicit consent required to execute, and API key requirement. Potential side effects of an actual rename are not mentioned, but for correct tool invocation the described information is largely sufficient.
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?
With 0% schema description coverage, the description must compensate, and it does explain the critical dry_run parameter's role in preview vs. execution. However, it does not add meaning for device_id, name, or site; these are left to their self-evident names and schema constraints, which is adequate but not a full compensation for zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation ('Preview a rename... Execute only with user intent and dry_run=False') with a specific verb and resource tied to the tool name. It clearly distinguishes this as the only mutation tool among read-only list/get/locate siblings, though 'Preview a rename' is slightly indirect phrasing for what is fundamentally a rename operation.
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 explicit conditions for execution: user intent must be present and dry_run must be False, plus the API key prerequisite. It doesn't name alternatives or exclusion conditions, but no genuine alternative exists among siblings (all are read-only), so the preview-versus-execute guidance is the key usage decision and it is stated clearly.
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 establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: summaries exclude keys/VPN configuration, the site defaults to UNIFI_SITE, and offset/limit affect only tool output rather than the controller fetch. This helps the agent understand response scope and pagination semantics.
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 only two sentences and wastes no words. The primary purpose is front-loaded, and the second sentence adds a meaningful behavioral nuance about offset/limit without repeating schema information.
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 with an output schema, this description covers purpose, default site behavior, scoping of returned summaries, and pagination semantics. The main gap is that it does not explicitly discuss sibling-tool alternatives, but the resource names make the intended context reasonably discoverable.
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 description coverage is 0%, so the description carries the burden of explaining parameters. It clarifies that 'site' defaults to UNIFI_SITE and that offset/limit bound tool output rather than the underlying fetch, which adds real meaning beyond the raw schema types and defaults. It does not fully detail all parameter interactions, but it compensates well given the simplicity of the 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 names a specific verb and resource: 'List network summaries'. It also adds scope by excluding keys and VPN configuration, which immediately differentiates this from a full network-detail tool. The sibling tools target other resources (sites, devices, clients), so the resource focus makes its purpose unambiguous.
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 when to use the tool—when a summary list of networks is needed—and notes the UNIFI_SITE default, but it does not explicitly name alternatives or state when not to use it. There is no direct comparison to sibling tools, so an agent must infer routing from the resource name.
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, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: offset/limit are applied to tool output, not the controller fetch, clarifying pagination semantics beyond the annotation metadata.
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 extremely concise: two short sentences, front-loaded with the core purpose and followed by one precise behavioral clarification. Every word contributes value.
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?
Given the low complexity, read-only/idempotent annotations, and presence of an output schema, the description covers the essential aspects: purpose, scope, and pagination behavior. No critical information for calling this tool 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 description coverage is 0%, but the description names offset/limit and clarifies their semantic role: they bound the output, not the controller fetch. This adds meaning beyond the schema's min/max/default values, though it stops short of per-parameter detail.
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 accessible sites.' This clearly distinguishes the tool from sibling list tools (networks, devices, clients) by resource, and the qualifier 'accessible' adds a scope boundary.
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 when to use the tool: when the agent needs to obtain accessible sites. However, it does not explicitly mention alternatives or exclusion conditions, so the guidance is inferred from the resource-specific wording rather than stated.
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, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavior beyond that: site defaults to UNIFI_SITE, and offset/limit bound tool output rather than the controller fetch—this prevents a common misconception and meaningfully clarifies runtime behavior.
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 short sentences with no filler. The main purpose is front-loaded, followed by the critical site default and the non-obvious pagination caveat. 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 an output schema present and read-only/idempotent annotations, the description is largely complete for a simple list tool. It explains the key non-obvious behaviors, though it could have explicitly addressed when to choose this over sibling list tools.
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 description coverage is 0%, so the description must compensate. It does by clarifying that site defaults to UNIFI_SITE and that offset/limit affect only the returned page, not the underlying fetch. This adds real semantic value beyond the bare schema, though individual parameter meanings are not fully spelled out.
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 'List currently connected clients' with a specific verb and resource, and the 'currently connected' qualifier distinguishes it from historical or device lists. Siblings cover networks, sites, and devices, so the resource scope is unambiguous.
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 when to use the tool—when the agent needs currently connected clients—but it does not explicitly state when not to use it or name alternative tools. The site default hint adds context but no direct comparison with sibling list 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:

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

Score Badge

Copy to your README.md:

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

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/duganth/py-unifi-mcp'

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