{ "SchemaVersion": "1", "Kind": "DirectoryEntry", "SubjectType": "mcp-server", "Slug": "unifi-mcp-server", "Name": "unifi-mcp-server", "Title": "unifi-mcp-server MCP Server | Pod", "Description": "An MCP server that leverages official UniFi API", "CanonicalUrl": "https://askpod.ai/mcp/unifi-mcp-server", "MarkdownUrl": "https://askpod.ai/mcp/unifi-mcp-server.md", "JsonUrl": "https://askpod.ai/mcp/unifi-mcp-server.json", "DatePublished": "2026-08-31T23:50:54.202Z", "DateModified": "2026-08-31T23:50:54.202Z", "RegistryName": "io.github.enuno/unifi-mcp-server", "RepositoryUrl": "https://github.com/enuno/unifi-mcp-server", "VerificationStatus": "unverified", "Identities": [], "Sources": [ { "Source": "github_issues", "LastSeenAt": "2026-08-31T23:50:54.202Z" }, { "Source": "official_mcp_registry", "ExternalId": "io.github.enuno/unifi-mcp-server", "LastSeenAt": "2026-08-31T23:50:54.202Z" } ], "Categories": [], "FirstParty": false, "Deployments": [ { "Kind": "package", "PackageRegistry": "npm", "PackageIdentifier": "unifi-mcp-server", "ConfigSnippet": "{\n \"mcpServers\": {\n \"unifi-mcp-server\": {\n \"command\": \"npx\",\n \"args\": [\n \"-y\",\n \"unifi-mcp-server\"\n ]\n }\n }\n}" } ], "Tools": { "Claimed": [], "ClaimedCount": 0, "Observed": null, "ObservedCount": null, "Verified": false, "Mismatch": null }, "Measured": null, "Usage": null, "Issues": [ { "Title": "[Bug] Unifi MCP SSL Issue", "Excerpt": "\n\n

Bug Description

The MCP tool list_active_clients (and by extension, any tool that calls UniFiClient.authenticate()) failed against a UDM Pro Local environment because SSL certificate verification could not be disabled. The .env variable documented for this purpose (UNIFI_LOCAL_VERIFY_SSL) is silently dropped by the provided docker-compose.yml, w", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/161", "PublishedAt": "2026-08-25T21:12:42.000Z", "State": "open", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "MCP_SERVER_TRANSPORT=streamable_http crashes with FastMCP: Unknown transport", "Excerpt": "## Summary\n\nStarting the server with the transport value currently recommended by the documentation:\n\n```text\nMCP_SERVER_TRANSPORT=streamable_http\n```\n\ncauses the process to exit during FastMCP startup:\n\n```text\nValueError: Unknown transport: streamable_http\n```\n\nFastMCP's server-side name for the Streamable HTTP transport is `http`.\n\n## Environment\n\n- Deployment: Docker\n- API mode: `local`\n- Python: 3.13\n- Configured transport: `streamable_http`\n- Server port: 3000\n- Repository: current `main`\n", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/159", "PublishedAt": "2026-08-23T15:15:56.000Z", "State": "open", "Comments": 3, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "CI is unreachable for fork PRs: workflow runs stuck at action_required + Mermaid check erroring, blocking all 9 open PRs", "Excerpt": "Opening this as a process/CI issue rather than a code bug: all 9 open PRs are currently unmergeable for the same reason, and it isn't anything the contributors can fix from their side.\n\n## Summary\n\nFork PRs never run CI, so the only check that reports a conclusion is `Mermaid Diagram Sync Assistant` — which has been erroring on every fork PR since late June. The automated daily review then reads that as a failing required check and posts `CHANGES_REQUESTED`, every day, forever.\n\n## 1. Fork PR wo", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/112", "PublishedAt": "2026-08-06T17:01:38.000Z", "State": "open", "Comments": 3, "Reporter": "Contributor", "Rank": "top", "Extractor": "github_issue" }, { "Title": "[Bug] Integration v1 sweep: 3 more models reject real controller responses, 5 tools call non-existent endpoints", "Excerpt": "## Summary\n\nFollow-up to #100 / #103. While fixing `list_wan_connections` I promised the reviewer a sweep of the other Integration v1 code paths for the same defect class. This is that sweep.\n\nTwo distinct defect classes turned up, both making tools unusable in `UNIFI_API_TYPE=local` mode:\n\n- **Class A — model requires fields the Integration v1 API never sends.** Same root cause as #100. `ValidationError` after a successful `200`, so the data is fetched and then thrown away.\n- **Class B — the to", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/108", "PublishedAt": "2026-08-03T05:54:20.000Z", "State": "closed", "Comments": 3, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Bug] ValidationError: FirewallPolicy.destination.matching_target missing 'WEB' enum value", "Excerpt": "## Description\n\n`list_firewall_policies` (and by extension `get_firewall_policy`) fails with a \nPydantic validation error when any firewall policy on the site has \n`destination.matching_target` set to `\"WEB\"`. Since Pydantic validates the full \nresponse list, a single policy with this value causes the *entire* tool call to \nfail — there's no way to retrieve any firewall policies for the site until the \noffending policy is removed or changed.\n\nThis looks like the same class of issue fixed for `AP", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/106", "PublishedAt": "2026-08-02T12:20:43.000Z", "State": "closed", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Bug] get_network_topology returns no device-to-device links — reads an `uplink` field the devices endpoint does not return", "Excerpt": "## Bug Description\n\n`get_network_topology` builds device uplinks from `device.get(\"uplink\", {})`,\nbut `GET /integration/v1/sites/{site_id}/devices` does not include an `uplink`\nkey at all. `uplink_device_id` is therefore always `None`, no uplink connections\nare ever created, and `max_depth` is always `0`.\n\nThe result is a topology graph containing only client-to-device edges. The\ndevice hierarchy — the actual point of a topology tool — is missing.\n\n## Environment Details\n\nunifi-mcp-server versio", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/102", "PublishedAt": "2026-07-30T12:01:36.000Z", "State": "closed", "Comments": 2, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Bug] list_pending_devices hits a non-existent endpoint — 'pending' parsed as a deviceId", "Excerpt": "## Bug Description\n\n`list_pending_devices` requests\n`/integration/v1/sites/{site_id}/devices/pending`. The Integration v1 API has no\nsuch route; it matches the `/devices/{deviceId}` pattern instead, so the\ncontroller tries to parse the literal string `pending` as a device ID and\nrejects the request.\n\nThe tool cannot succeed on any site — this is not environment-specific.\n\n## Error Message\n\n```\nError calling tool 'list_pending_devices': API request failed: {\"statusCode\":400,\n\"statusName\":\"BAD_REQ", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/101", "PublishedAt": "2026-07-30T12:01:35.000Z", "State": "closed", "Comments": 3, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Bug] list_wan_connections raises ValidationError — WANConnection requires fields the Integration API never returns", "Excerpt": "## Bug Description\n\n`WANConnection` marks `site_id`, `wan_type`, `interface` and `status` as\nrequired, but `GET /integration/v1/sites/{site_id}/wans` returns only `id` and\n`name`. Every response therefore fails validation and the tool is unusable in\nlocal Integration API mode.\n\nSame failure shape as #72 / #75 / #89 — a model stricter than the API it parses.\n\n## Error Message\n\n```\nError calling tool 'list_wan_connections': 4 validation errors for WANConnection\nsite_id\n Field required [type=missi", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/100", "PublishedAt": "2026-07-30T11:59:26.000Z", "State": "closed", "Comments": 2, "Reporter": "Contributor", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Bug] All v2 traffic-flow tools fail with \"Site does not exist\" when passed a site UUID", "Excerpt": "## Bug Description\n\n`get_v2_api_path()` interpolates the caller-supplied `site_id` straight into\n`/proxy/network/v2/api/site/{site_id}`. The UUID → site-short-name translation\nthat `UniFiClient._translate_endpoint()` performs only fires for `/ea/sites/...`\nendpoints; paths that already start with `/proxy/network/` are passed through\nuntouched. So every v2 traffic-flow tool sends a UUID where the v2 API requires\nthe short name, and the controller rejects it.\n\nThis matters because `list_sites` ret", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/99", "PublishedAt": "2026-07-30T11:59:25.000Z", "State": "closed", "Comments": 5, "Reporter": "Contributor", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Requests to Legacy REST endpoints failing", "Excerpt": "I am trying to use unifi-mcp-server with Claude and it is failing. I requested Claude to document the error and its conditions. It provided detailed data and suggested fixes\n## Bug Description\n\n\n\nRequests to legacy REST endpoints (list_port_forwards, get_device_connections) hang for ~4 minutes instead of failing fast, due to stacked retry/backoff on authenticate() + data call\n\n## Error Message\n\n```\n[Paste the exact error message here]\n``", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/97", "PublishedAt": "2026-07-27T15:11:58.000Z", "State": "closed", "Comments": 3, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Error: Received request before initialization was complete", "Excerpt": "## Title\nSSE transport: tool calls fail with \"Tool execution failed\" despite valid connectivity and auth — likely session-init race condition\n\n## Environment\n\n- Image: `ghcr.io/enuno/unifi-mcp-server:latest`\n- Transport: SSE (`MCP_SERVER_TRANSPORT=sse`, port 3000)\n- Deployment: Docker Compose, container name `smarthome-unifi-mcp-1`, host `nuc`\n- UniFi API type: local (self-hosted UDM/console, not cloud)\n\n### Full compose config (keys redacted)\n\n```yaml\nunifi-mcp:\n image: ghcr.io/enuno/unifi-mcp", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/96", "PublishedAt": "2026-07-18T22:34:47.000Z", "State": "open", "Comments": 3, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Bug] Component already exists\" warning logged continuously", "Excerpt": "## \"Component already exists\" warning logged continuously (~every 65s) regardless of client connections\n\nThe server continuously logs WARNING Component already exists: local_provider.py:192 at a steady rate of roughly 110 occurrences/hour (~every 60-65 seconds), confirmed via Loki log aggregation over a sustained period. This happens regardless of whether an MCP client is actively connected — the rate is flat even with no active session, ruling out reconnect-driven re-registration.\n\n### Example ", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/91", "PublishedAt": "2026-06-13T08:08:24.000Z", "State": "closed", "Comments": 3, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Bug] list_traffic_routes fails with ValidationError when static routes exist on site", "Excerpt": "## Bug Description\n\nThe MCP tool `list_traffic_routes` failed when tested against the **UDM SE Local** environment.\n\nWhen invoked, the tool successfully reaches the UniFi controller and retrieves data from the\n`/proxy/network/api/s/default/rest/routing` endpoint. However, the response contains **static route\nobjects** (identified by the `static-route_nexthop` key) in addition to policy-based traffic routes.\nThe `TrafficRoute` Pydantic model treats `action` and `match_criteria` as required fields", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/89", "PublishedAt": "2026-06-10T14:31:29.000Z", "State": "closed", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "update_network: dry_run=False always returns dry-run response; DNS fields missing from would_update (v0.2.5)", "Excerpt": "## Summary\n\nTwo related bugs in `update_network` (`src/tools/network_config.py`) cause it to **always behave as if `dry_run=True`** and to **silently drop DNS parameters** from both the preview output and the live update.\n\n## Bug 1 — `dry_run` string coercion not applied before the branch check\n\n### Root cause\n\nThe function signature accepts `dry_run: bool | str = False`, and a `coerce_bool()` helper already exists in `src/utils/validators.py` to handle the MCP JSON-RPC quirk where booleans arri", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/86", "PublishedAt": "2026-05-22T21:44:36.000Z", "State": "closed", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "[Bug] create_wlan dry-run succeeds but confirmed 6 GHz WPA3 SSID creation fails with InvalidPayload", "Excerpt": "## Bug Description\n\nThe MCP tool `create_wlan` failed when tested against the **UDR7 Local** environment.\n\nThe specific failure was creating a 6 GHz-only WPA3 PSK SSID. `dry_run=true` succeeded and returned a valid-looking payload preview, but the confirmed call failed with `api.err.InvalidPayload` / `api.err.InvalidValue`.\n\n## Error Message\n\n```\nError calling tool 'create_wlan': API request failed: {\"meta\":{\"rc\":\"error\",\"msg\":\"api.err.InvalidPayload\"},\"data\":[{\"validationError\":{},\"rc\":\"error\",", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/77", "PublishedAt": "2026-05-12T16:53:02.000Z", "State": "closed", "Comments": 4, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Bug - list_vlans fails when the site contains a network with an empty vlan", "Excerpt": "## Bug Description\n\nThe MCP tool `list_vlans` fails when the site contains a network whose `vlan` field is returned as an empty string by the UniFi API (observed on WAN networks, which have no VLAN ID). The Pydantic `Network` model requires `vlan` to be a valid integer, causing validation to throw and the entire tool call to fail rather than returning the other networks successfully.\n\n## Error Message\n\n```\n1 validation error for Network vlan\nInput should be a valid integer, unable to parse strin", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/75", "PublishedAt": "2026-05-03T23:40:14.000Z", "State": "closed", "Comments": 2, "Reporter": "External", "Rank": "recent", "Extractor": "github_issue" }, { "Title": "Request - SKILL.md / cli mode", "Excerpt": "I wonder if you could package these tools as a cli with an associated SKILL.md file (or set of files)? That would make them easier to use because they wouldn't take up space in the context for conversations that don't involve Unifi. Users could leave the Unifi skill enabled all the time, vs having to enable/disable the Unifi MCP server.\n\nThere are tools that try to automatically wrap MCP servers into CLI tools and/or SKILLs. but an official version would be nice.", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/70", "PublishedAt": "2026-05-01T05:07:49.000Z", "State": "closed", "Comments": 7, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Request - some way to reduce the tools to under 50.", "Excerpt": "FWIW the current mcp server has well over a hundred tools. That's too many for some agents like Google Antigravity, which has a limit of 50 MCP tools, summed over all enabled MCP servers.\n\nI guess I could rebuild the unifi-mcp-server after editing it to remove some tools, but it would be nice to have an out-of-the-box solution for this.\n\nNote that while Antigravity allows you to enable/disable individual tools, it refuses to do so if the total number of tools is greater than 50.\n\n(Antigravity ha", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/69", "PublishedAt": "2026-05-01T05:03:03.000Z", "State": "closed", "Comments": 4, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "[Bug] Local Gateway authentication fails - all tools return 401 Unauthorized", "Excerpt": "## Bug Description\nThe MCP server fails to authenticate with the Local Gateway API, causing all tools to fail with 401 Unauthorized errors.\n\n## Affected Tools\nAll tested tools failed with the same authentication error:\n- `list_sites`\n- `list_wlans`\n- `list_active_clients`\n- `search_devices`\n\n## Error Details\n```\nFailed to authenticate with UniFi API: Authentication failed: {\"error\":{\"code\":401,\"message\":\"Unauthorized\"}}\n```\n\n## API Details\n- **Environment:** Local Gateway (Local API mode)\n- **AP", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/14", "PublishedAt": "2026-01-23T01:21:16.000Z", "State": "closed", "Comments": 5, "Reporter": "External", "Rank": "top", "Extractor": "github_issue" }, { "Title": "Proposal: Major contribution - comprehensive test suite, new tools, and API audit", "Excerpt": "Hi @enuno,\n\nI've been using unifi-mcp-server for a project and ended up making significant enhancements that I'd like to contribute back upstream. Before opening PRs, I wanted to discuss the scope and preferred approach with you.\n\n## Summary of Changes\n\nOver the past few weeks, I've added:\n\n### 1. Comprehensive Test Suite\n- **Before:** Limited test coverage\n- **After:** 213 unit tests across all major modules\n- Includes tests for: devices, clients, networks, sites, config, audit, helpers, conten", "SourceUrl": "https://github.com/enuno/unifi-mcp-server/issues/11", "PublishedAt": "2026-01-06T04:12:14.000Z", "State": "closed", "Comments": 4, "Reporter": "Contributor", "Rank": "top", "Extractor": "github_issue" } ], "Observations": [], "ObservationCount": 0, "Related": [], "Indexable": true, "ContentMarkdown": "# unifi-mcp-server MCP Server\n\nAn MCP server that leverages official UniFi API\n\n**Publisher claimed.** No tool list reported, and Pod has not connected to this server.\n\n## Status\n\nPod has not dialled unifi-mcp-server yet, so everything on this page is what its publisher reported rather than what we observed. Registries describe servers; they do not connect to them. Until a check runs, treat the tool list below as a claim.\n\n## Connect\n\nPublished as `unifi-mcp-server` on npm. Runs locally.\n\n## Known issues\n\n**30 problems reported by people outside the maintainer team.** Issues filed by the project's own owners, members and collaborators are excluded — those are release checklists and internal refactors, not things that will go wrong for you. Showing 12.\n\n### Most discussed\n\n### MCP_SERVER_TRANSPORT=streamable_http crashes with FastMCP: Unknown transport\n\n## Summary\n\nStarting the server with the transport value currently recommended by the documentation:\n\n```text\nMCP_SERVER_TRANSPORT=streamable_http\n```\n\ncauses the process to exit during FastMCP startup:\n\n```text\nValueError: Unknown transport: streamable_http\n```\n\nFastMCP's server-side name for the Streamable HTTP transport is `http`.\n\n## Environment\n\n- Deployment: Docker\n- API mode: `local`\n- Python: 3.13\n- Configured transport: `streamable_http`\n- Server port: 3000\n- Repository: current `main`\n\n[Read the thread](https://github.com/enuno/unifi-mcp-server/issues/159) · 2026-08-23 · open · external user · 3 comments\n\n### CI is unreachable for fork PRs: workflow runs stuck at action_required + Mermaid check erroring, blocking all 9 open PRs\n\nOpening this as a process/CI issue rather than a code bug: all 9 open PRs are currently unmergeable for the same reason, and it isn't anything the contributors can fix from their side.\n\n## Summary\n\nFork PRs never run CI, so the only check that reports a conclusion is `Mermaid Diagram Sync Assistant` — which has been erroring on every fork PR since late June. The automated daily review then reads that as a failing required check and posts `CHANGES_REQUESTED`, every day, forever.\n\n## 1. Fork PR wo\n\n[Read the thread](https://github.com/enuno/unifi-mcp-server/issues/112) · 2026-08-06 · open · outside contributor · 3 comments\n\n### [Bug] All v2 traffic-flow tools fail with \"Site does not exist\" when passed a site UUID\n\n## Bug Description\n\n`get_v2_api_path()` interpolates the caller-supplied `site_id` straight into\n`/proxy/network/v2/api/site/{site_id}`. The UUID → site-short-name translation\nthat `UniFiClient._translate_endpoint()` performs only fires for `/ea/sites/...`\nendpoints; paths that already start with `/proxy/network/` are passed through\nuntouched. So every v2 traffic-flow tool sends a UUID where the v2 API requires\nthe short name, and the controller rejects it.\n\nThis matters because `list_sites` ret\n\n[Read the thread](https://github.com/enuno/unifi-mcp-server/issues/99) · 2026-07-30 · closed · outside contributor · 5 comments\n\n### [Bug] create_wlan dry-run succeeds but confirmed 6 GHz WPA3 SSID creation fails with InvalidPayload\n\n## Bug Description\n\nThe MCP tool `create_wlan` failed when tested against the **UDR7 Local** environment.\n\nThe specific failure was creating a 6 GHz-only WPA3 PSK SSID. `dry_run=true` succeeded and returned a valid-looking payload preview, but the confirmed call failed with `api.err.InvalidPayload` / `api.err.InvalidValue`.\n\n## Error Message\n\n```\nError calling tool 'create_wlan': API request failed: {\"meta\":{\"rc\":\"error\",\"msg\":\"api.err.InvalidPayload\"},\"data\":[{\"validationError\":{},\"rc\":\"error\",\n\n[Read the thread](https://github.com/enuno/unifi-mcp-server/issues/77) · 2026-05-12 · closed · external user · 4 comments\n\n### Request - SKILL.md / cli mode\n\nI wonder if you could package these tools as a cli with an associated SKILL.md file (or set of files)? That would make them easier to use because they wouldn't take up space in the context for conversations that don't involve Unifi. Users could leave the Unifi skill enabled all the time, vs having to enable/disable the Unifi MCP server.\n\nThere are tools that try to automatically wrap MCP servers into CLI tools and/or SKILLs. but an official version would be nice.\n\n[Read the thread](https://github.com/enuno/unifi-mcp-server/issues/70) · 2026-05-01 · closed · external user · 7 comments\n\n### Most recent\n\n### [Bug] Unifi MCP SSL Issue\n\n\n\n