Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@py-unifi-mcp list the devices on my network"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small Python MCP server for local UniFi Network inspection. Built with the same FastMCP, httpx, and Pydantic structure as py-ynab-mcp.
The initial feature uses a local API key or UniFi OS session authentication and exposes read-only inventory. See the charter and steel thread spec.
For expansion choices, see the preserved feature landscape, official API catalog, and sanitized live capability evidence linked there. Health/device detail and rename/locate are the selected expansion; other groups remain deferred.
Requires Python 3.12+ and a UniFi OS console with local Network access. This initial version uses fixed legacy Network endpoints. Standalone Network controllers, cloud accounts and MFA login are not supported. API-key access to these legacy endpoints depends on the controller version and key permissions; this is not an Integration API implementation.
From this repository, using an external uv environment:
uv venv "$WORKSPACE_ROOT/scratch/.venvs/py-unifi-mcp" --python 3.12
uv pip install --python "$WORKSPACE_ROOT/scratch/.venvs/py-unifi-mcp/bin/python" -e . --group devSet UNIFI_URL to an HTTPS origin such as https://controller.example (no
trailing slash, path, query, or credentials). Supply either UNIFI_API_KEY or both
UNIFI_USERNAME and UNIFI_PASSWORD through your secret runner's environment
injection. Mixed credentials are rejected. The credential must have access to
the desired sites; prefer read-only privileges unless scoped writes are required.
Do not put passwords in source files or command arguments. Optional UNIFI_SITE
defaults to default. Optional UNIFI_CA_FILE is a PEM CA bundle for a private CA;
otherwise the normal system trust configuration is used. TLS verification is
mandatory. Redirects and environment HTTP proxies are disabled.
Configure your MCP client to execute the absolute path to
$WORKSPACE_ROOT/scratch/.venvs/py-unifi-mcp/bin/py-unifi-mcp with these environment
variables. The server uses stdio. API-key mode sends X-API-Key on requests, never
logs in, and never falls back to username/password. Session mode keeps cookies
only in memory, logs in lazily on the first inventory request, and can
reauthenticate once when a read encounters an expired session. Transport failures
and login are not retried.
Related MCP server: UniFi MCP Server
Tool | Inventory |
| Accessible sites and descriptions |
| Device identity, model, version, address and numeric state |
| Currently connected clients and connection identity |
| Network name, purpose, VLAN and subnet |
| Subsystem health and available device/client metrics |
| Exact |
| Preview or execute an exact-device rename with |
| Preview or execute LED locate start/stop with |
List tools and health accept offset (default 0) and limit (default 50, maximum 100).
Device, client and network tools also accept a validated optional site identifier.
Results contain items, total, offset, limit, returned, truncated,
has_more, and next_offset. truncated means this page omits some items in the
snapshot, including earlier pages. has_more indicates a following page.
Pagination bounds MCP output; the controller still returns its full inventory
snapshot, and ordering may change between requests.
Only explicitly modeled fields are returned. WLAN passwords, VPN material and arbitrary nested settings are discarded. Network addresses and client names are still private network data visible to the MCP consumer. Treat device names and other controller text as untrusted data. Unknown numeric device state codes are preserved without guessing their meanings. Missing telemetry remains null.
Rename and locate default to dry_run=True: resolve the exact adopted device ID
in the selected site and show the target and proposed change without mutating it.
Execution requires explicit dry_run=False, API-key authentication, and user intent
for that target/change. Session authentication supports reads/previews only.
Names must be nonblank, bounded, and free of control characters. No arbitrary
device settings, restart, or network changes are exposed.
Writes are never retried or replayed. Rename distinguishes controller acknowledgement
from name read-back verification; a failed read-back is unverified, not a reason to
repeat the mutation. Locate acknowledgement cannot verify the physical LED. Set
enabled=False to stop locating; a start is not automatically stopped. Transport
or invalid-response failures have an unknown outcome: inspect before acting again.
These legacy writes are based on community source contracts. Live rename read-back
and locate start/stop acknowledgement were tested on the development controller;
support still depends on controller version, key permissions and device model.
See the completed device operations spec.
Malformed responses, denied access, legacy API errors, and connection failures produce sanitized errors. Schema failures do not silently become empty inventory.
"$WORKSPACE_ROOT/scratch/.venvs/py-unifi-mcp/bin/ruff" check .
"$WORKSPACE_ROOT/scratch/.venvs/py-unifi-mcp/bin/ruff" format --check .
"$WORKSPACE_ROOT/scratch/.venvs/py-unifi-mcp/bin/mypy" src/
"$WORKSPACE_ROOT/scratch/.venvs/py-unifi-mcp/bin/pytest"
uv build --wheelTests use synthetic HTTP transports, including an MCP stdio subprocess test; they do not contact a controller. Live verification uses an external local runner with in-memory secret injection; controller details and verification evidence remain outside this repository.
Get allow-listed telemetry for one exact device ID in the selected site.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| device_id | Yes |
| Name | Required | Description |
|---|---|---|
| ip | No | |
| _id | Yes | |
| mac | Yes | |
| name | No | |
| type | No | |
| model | No | |
| state | No | |
| uplink | No | |
| uptime | No | |
| adopted | No | |
| version | No | |
| disabled | No | |
| upgradable | No | |
| system-stats | No | |
| upgrade_to_firmware | No |
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.
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.
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.
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.
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.
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.
Read subsystem health; missing metrics are unknown, not healthy.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| has_more | Yes | |
| returned | Yes | |
| truncated | Yes | |
| next_offset | Yes |
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.
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.
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.
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.
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.
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.
List currently connected clients; site defaults to UNIFI_SITE.
Offset/limit bound tool output, not the controller fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| has_more | Yes | |
| returned | Yes | |
| truncated | Yes | |
| next_offset | Yes |
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.
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.
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.
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.
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.
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.
List device inventory and raw state codes; site defaults to UNIFI_SITE.
Offset/limit bound tool output, not the controller fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| has_more | Yes | |
| returned | Yes | |
| truncated | Yes | |
| next_offset | Yes |
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.
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.
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.
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.
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.
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.
List network summaries without keys or VPN configuration; defaults to UNIFI_SITE.
Offset/limit bound tool output, not the controller fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| has_more | Yes | |
| returned | Yes | |
| truncated | Yes | |
| next_offset | Yes |
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.
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.
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.
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.
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.
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.
List accessible sites. Offset/limit bound tool output, not the controller fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| has_more | Yes | |
| returned | Yes | |
| truncated | Yes | |
| next_offset | Yes |
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.
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.
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.
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.
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.
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.
Preview LED locate start/stop. Execution requires user intent and API key.
Start is not auto-stopped; use enabled=False to stop. LED state is not verified.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| dry_run | No | ||
| enabled | Yes | ||
| device_id | Yes |
| Name | Required | Description |
|---|---|---|
| mac | Yes | |
| name | Yes | |
| site | Yes | |
| dry_run | Yes | |
| message | Yes | |
| verified | No | |
| device_id | Yes | |
| operation | Yes | |
| acknowledged | No | |
| proposed_value | Yes |
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.
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.
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.
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.
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.
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.
Preview a rename. Execute only with user intent and dry_run=False; requires API key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| site | No | ||
| dry_run | No | ||
| device_id | Yes |
| Name | Required | Description |
|---|---|---|
| mac | Yes | |
| name | Yes | |
| site | Yes | |
| dry_run | Yes | |
| message | Yes | |
| verified | No | |
| device_id | Yes | |
| operation | Yes | |
| acknowledged | No | |
| proposed_value | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0unifi_get_deviceunifi_get_healthunifi_list_clientsunifi_list_devicesunifi_list_networksunifi_list_sitesunifi_locate_deviceunifi_rename_deviceEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Tailscale device, route, DNS, key, user, and ACL management over MCP and CLI.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
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
