The UniFi Network MCP Server - free, local, built for MSPs
Independent, open source, inspectable. Every line of code is on GitHub under Apache-2.0 - built for the MSP community, vendor-neutral by design. Not affiliated with, endorsed by, or sponsored by Ubiquiti Inc..
Passes all 4 mechanical gates (build · command-surface · claims · install). Awaiting its first MSP receipt - be the first, 60 seconds →.
Yes - there is an MCP server for UniFi Network. It’s free, open source, and runs on your own machine, so your client data never leaves your network. It connects UniFi Network to Claude, ChatGPT, Copilot, or any MCP-capable agent, and installs in about 60 seconds.
UniFi Network plus your AI answers the gateway questions the console makes you reconstruct by hand: what actually changed in this site’s config since you last looked, what hardware joined the network this week, and whether there is PoE and port headroom before you hang another AP. It syncs the gateway to a local SQLite mirror, so change-over-time questions the integration API cannot answer become one offline command.
New to the term? An MCP server is the same thing ChatGPT calls an app or connector, Claude on the web calls a connector, and Claude Code calls a Skill. One thing, many names →
Install in 60s → View on GitHub →
Instead of clicking through UniFi Network, just ask
Instead of Clicking through Settings screen by screen trying to remember what the firewall and VLAN config looked like last week, because the integration API exposes no config history
just ask: “What changed on this UniFi site since my last check?”
Your agent runs: unifi-network-cli drift --site default --json
Instead of Scrolling the client list looking for hardware you do not recognise, with no way to tell what is new versus what has always been there
just ask: “What devices and clients joined this network in the last week?”
Your agent runs: unifi-network-cli newcomer --since 7d --json
Instead of Opening each switch in turn and counting free ports and checking which ones already energize PoE across a stack before adding a camera or an AP
just ask: “Do I have port and PoE headroom on this site?”
Your agent runs: unifi-network-cli port-audit --site default --json
See it in 30 seconds
Demo data is simulated. Every command shown exists in the real CLI.
What it does
| Question your MSP keeps asking | Command your agent runs |
|---|---|
| What changed in this site’s config since my last check? | unifi-network-cli drift --site default --json |
| What devices and clients joined the network this week? | unifi-network-cli newcomer --since 7d --json |
| Do I have switch port and PoE headroom before adding hardware? | unifi-network-cli port-audit --site default --json |
| Which firewall policy would match traffic from this host? | unifi-network-cli rule-predict --src 10.0.3.50 --dst 10.0.0.1 |
| Which clients are sitting behind which device? | unifi-network-cli topology --site default |
| What firewall policies are configured on this site? | unifi-network-cli sites firewall get-policies <siteId> --all |
| Who is on the guest network, and which vouchers are live? | unifi-network-cli guest report --site default |
| List every adopted device on the site | unifi-network-cli sites devices get-adopted-overview-page <siteId> --all |
Full command reference at github.com/servosity/msp-skills/blob/main/skills/unifi-network/guide.md.
What makes this one different
Most UniFi integrations proxy each question straight into a live API call. That works for reading one record and falls apart for anything historical, because the integration API has no config-versioning or audit-trail endpoint to proxy to - the data simply is not there to ask for. This skill syncs the gateway into a local SQLite mirror and keeps its own snapshots, so drift can diff this site’s config against the last time you looked and newcomer can hold a first-seen record per device and client. Those answers are computed locally from state the API never returns twice.
The UniFi console stays the system of record and the place you make changes. This skill adds what the console does not: a terminal-and-agent surface where config drift, first-seen hardware, port and PoE headroom, and firewall-match prediction are single commands an AI can run, and where the answer arrives as JSON instead of a screen you have to read.
The pain this closes
- The UniFi Network integration API exposes no config-versioning or audit-trail endpoint, so ‘what changed on this site, and when?’ has no answer you can pull - a gap the Ubiquiti Community has open feature requests for under titles like ‘UniFi Change Logs or Change Control options?’ and ‘Audit log of recent changes’.
- Spotting new hardware means eyeballing a list with no baseline: clients have no first-seen record at all (only a current-session connectedAt), and a device’s adoptedAt exists only on the per-device detail fetch, never in the list you scan.
- Port and PoE status lives one device-detail screen at a time; the list endpoints do not return per-port interface data at all, so checking free ports before planning a new AP or camera means opening every switch by hand.
Install
Works in any of these agents - pick yours:
| Agent | Quick install |
|---|---|
| Claude Desktop | Step-by-step → |
| ChatGPT (Plus/Pro+) | Step-by-step → |
| Claude Code | Step-by-step → |
| Codex CLI | Step-by-step → |
| Cursor, Windsurf, Cline, Continue, Zed, Copilot, Gemini, Hermes, OpenClaw | Which agent? → |
Quickest path for everyone else (terminal):
macOS / Linux:
bash <(curl -fsSL https://raw.githubusercontent.com/servosity/msp-skills/main/skills/unifi-network/install.sh)
Windows (PowerShell):
iwr -useb https://raw.githubusercontent.com/servosity/msp-skills/main/skills/unifi-network/install.ps1 | iex
After install, authenticate once with your UniFi Network credentials, then verify with unifi-network-cli --version.
Safety model
| Tier | Examples | Recommended agent policy |
|---|---|---|
| Read | drift, newcomer, topology, port-audit, rule-predict, sites devices get-adopted-overview-page, sites firewall get-policies (non-mutating reads except the secret-bearing ones below; drift and newcomer advance their own local baseline each run) | Allow |
| Credential (incl. secret-returning reads) | auth set-token, auth logout, and every command whose output can carry a live secret (the CLI redacts nothing): sites wifi get-broadcast-details, sites hotspot get-voucher / get-vouchers, guest report, search, analytics –group-by code | Human-in-the-loop only - never in a blanket allow-all-reads policy. Three writes (sites hotspot create-vouchers, sites wifi create-broadcast / update-broadcast) also return secrets in their response body; treat their output the same way |
| Write (routine) | sites firewall create-policy, sites firewall update-policy, sites acl-rules create, sites networks create, sites wifi update-broadcast, sites dns create-policy, sites hotspot create-vouchers | Preview with –dry-run, then a reviewed write |
| Device / port control | sites devices adopt, sites devices execute-adopted-action, sites devices execute-port-action, sites clients execute-connected-action | Human-in-the-loop only - these take physical effect on the network |
| Destructive / config | sites devices remove (factory-resets an online device), sites firewall delete-zone, sites networks delete, sites acl-rules delete, sites dns delete-policy, sites wifi delete-broadcast | Human-in-the-loop only, explicit confirmation |
Most read commands - the local-mirror views, reports, and the non-mutating site endpoints - change nothing on the gateway and are safe to let an agent run. Two exceptions matter. Several reads return live secrets (the WiFi detail read includes that SSID’s cleartext passphrase; guest report, search, and the hotspot reads return usable voucher codes) and the CLI does not redact output, so those belong in the credential tier rather than a blanket allow-all-reads policy. Three writes also return secrets in their response body (the voucher-creation and WiFi-broadcast writes), so their output is credential-grade too. Writes are grouped by blast radius: routine config writes should be previewed with –dry-run and approved. Two tiers should never run unattended: device and port control, where one command can power-cycle a PoE port or kick a client off the network, and destructive commands, where sites devices remove factory-resets an online device. Full details in governance.md.
Frequently asked questions
Is there an MCP server for UniFi Network?
Yes - this one. A free, open source MCP server and Claude Code Skill for UniFi Network, built for MSPs. It runs locally on your machine, works with Claude, ChatGPT, Copilot, and any MCP-capable agent, and installs in about 60 seconds.
Is the UniFi Network MCP server safe for client data?
Yes, by design. The CLI, the MCP server, and any local data mirror run on your own machine - nothing is sent to MSP Skills or any third party. Credentials stay in your environment, and every command is safety-tiered (read, write, destructive) so your agent only gets the permissions you grant. Full policy in the safety model on this page.
Does this work with ChatGPT?
Yes, on paid ChatGPT plans. ChatGPT connects to remote MCP servers over HTTPS, so you expose the local UniFi MCP server via a secure bridge. Step-by-step in the install guide.
Do I need to know how to code?
No. Paste one sentence into Claude Code or Codex and your agent does the install, or run a one-line installer. You enter your credentials once.
Is my UniFi data safe?
Your data stays on your machine. The CLI, MCP server, and the local mirror are all local, and the gateway itself is on your own network - nothing routes through a vendor cloud. The AI sees query results, not raw bulk data, and credentials are never bundled or transmitted by MSP Skills.
What does it cost?
Free. Apache-2.0 licensed. You pay only for whichever AI agent you already use.
Does this use the UniFi Site Manager cloud API?
No. This skill talks to the local Network integration API on a self-hosted UniFi OS gateway, reached at https://
Why do the drift and newcomer commands report nothing on the first run?
Both maintain their own baseline because the API offers no history to read. The first run for a site captures the current state as the baseline and reports no changes - that is expected, not an error. From the second run on, they report what moved since the previous run. Run unifi-network-cli sync before each check so the mirror is current.
Can I trust rule-predict before making a firewall change?
Treat it as a local simulation, not a live trace. It walks the last synced firewall policies in the same ascending-index, first-match-wins order the gateway uses, and matches on source and destination IP only - --port is echoed for reference and is not used for matching. Pass host IPs rather than CIDRs: a CIDR’s mask is ignored and only the address you typed is tested, so --src 10.0.3.0/24 predicts for the single address 10.0.3.0 and tells you nothing about 10.0.3.50. It does not evaluate the range. Zone-wide policies and traffic-matching-list references it cannot resolve are flagged as uncertain rather than silently assumed. Sync first, and confirm the real change in the console.
More Network Monitoring connectors
Run more than one Network Monitoring tool, or comparing options? These connectors work the same way: Domotz
Status
Beta. Validated against the UniFi Network API surface and being validated with MSPs running it live against their own production tenants in our weekly Build Sessions.
Build Sessions are free and stay free - The Build Room is where the deep work happens.
Standards. Conforms to the open Agent Skills spec (Anthropic, Dec 2025; 40+ agents). MCP-compatible - works with any MCP-capable agent including Hermes. OpenClaw-ready (frontmatter pre-wired, awaiting OpenClaw launch).
Maintained by Servosity for the MSP community. Apache-2.0 licensed. Built with CLI Printing Press.