The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Go Unifi MCP listing page.
A Model Context Protocol (MCP) server for UniFi Network Controller, written in Go.
go-unifi-mcp provides an MCP interface to UniFi Network Controller, enabling
AI assistants and other MCP clients to interact with your UniFi infrastructure.
I couldn’t find an MCP server that supported both v1 and v2 firewall rules and IPv6, so I built one. This wraps the go-unifi library (which I trust from my Terraform provider experience) and leans on its generated API surface. The server is generated from the controller’s own API definitions, which makes it much easier to keep tool coverage up to date as UniFi evolves.
This project generates tools against the same UniFi Controller version pinned by go-unifi. When go-unifi updates its supported controller version, we regenerate our field definitions and tool metadata to match. We support the same controller range; see their controller support range.
Download pre-built binaries from the Releases page. Binaries are available for macOS and Linux (amd64/arm64).
Available from the claytono/homebrew-tap tap:
Multi-architecture images (amd64/arm64) are published to GitHub Container Registry.
The server requires access to a UniFi Network Controller. Two authentication methods are supported:
API Key (preferred): Create an API key in your UniFi controller under
Settings > Control Plane > Integrations. Set UNIFI_HOST and
UNIFI_API_KEY.
Username/Password: Use a local admin account. Set UNIFI_HOST,
UNIFI_USERNAME, and UNIFI_PASSWORD.
Add to your claude_desktop_config.json:
Using the binary:
Using Docker:
Then set the required environment variables in your shell before running
claude.
| Variable | Required | Default | Description |
|---|---|---|---|
UNIFI_HOST | Yes | — | UniFi controller URL |
UNIFI_API_KEY | * | — | API key (preferred auth method) |
UNIFI_USERNAME | * | — | Username for password auth |
UNIFI_PASSWORD | * | — | Password for password auth |
UNIFI_SITE | No | default | UniFi site name |
UNIFI_VERIFY_SSL | No | true | Whether to verify SSL certs |
UNIFI_LOG_LEVEL | No | error | go-unifi client log level |
UNIFI_TOOL_MODE | No | lazy | Tool registration mode |
* Either UNIFI_API_KEY or both UNIFI_USERNAME and UNIFI_PASSWORD must be
set.
The UNIFI_LOG_LEVEL variable controls logging from the underlying go-unifi
client library. The default is error because the client otherwise emits INFO
messages to stderr, which can interfere with tools like mcp-cli that parse JSON
on stdout/stderr.
| Level | Description |
|---|---|
disabled | No logging |
trace | Most verbose, including wire details |
debug | Debug messages |
info | Informational messages |
warn | Warnings only |
error | Errors only (default) |
The server supports two tool registration modes, following the pattern established by unifi-network-mcp:
| Mode | Tools | Context Size | Description |
|---|---|---|---|
lazy | 3 | ~200 tokens | Meta-tools only (default, recommended for LLMs) |
eager | 252 | ~55K tokens | All tools registered directly |
Lazy mode (default) registers only 3 meta-tools that provide access to 252 UniFi operations (generated from the controller API):
tool_index - Search/filter the tool catalog by category or resourceexecute - Execute any tool by name with argumentsbatch - Execute multiple tools in parallelThis dramatically reduces context window usage while preserving full functionality. The LLM first queries the index to find relevant tools, then executes them via the dispatcher.
Eager mode registers all 252 tools directly, which may be useful for non-LLM clients or debugging but consumes significant context.
Update semantics: Updates use a read-modify-write flow against the controller API. We fetch the current resource, merge your fields, and submit the full object. This avoids clearing unspecified fields, but it is not atomic and concurrent updates can race (last write wins) because the UniFi API does not expose etags or revision IDs. In practice this is unlikely to be an issue, but it's something to be aware of.
Responses from the UniFi API contain opaque ID references (e.g. network_id,
usergroup_id, networkconf_id). By default, the server resolves these to
human-readable names by looking up the referenced resource and injecting a
sibling _name field:
Resolution uses a per-request cache, so listing 100 firewall rules that
reference networks only makes one additional ListNetwork API call. Typical
overhead is 10-40ms depending on how many distinct resource types are
referenced.
To disable resolution for a specific call, pass "resolve": false in the tool
arguments.
All list operations support optional post-processing parameters for filtering and projecting results.
filter — Match items by field values. Supports three operators:
search — Case-insensitive full-text search across all string field values:
fields — Project the response to include only specific keys:
Parameters can be combined. Execution order is filter → search → fields, so you can filter on fields that are excluded from the output:
The development environment includes mcp-cli for interactive testing of the MCP server.
Create .envrc.local with your UniFi credentials (not tracked in git):
Build the binary:
Test with mcp-cli:
The .mcp_servers.json config provides two server entries:
go-unifi-mcp - eager mode (252 tools)go-unifi-mcp-lazy - lazy mode (3 meta-tools)Eager mode (direct tool access):
Lazy mode (meta-tools):
This project builds upon:
MPL-2.0