UniFi Gateway

io.github.pete-builds由 GitHub 帳號 pete-builds 發布v0.27.0更新於 Oct 27, 2026

Safe-by-default UniFi MCP: Network + Protect + Access, multi-site, dry-run, audit log.

概覽

AI 產生的概覽

以安全優先為前提、針對自架 UniFi 的 MCP 伺服器,讓助理在預演與稽核日誌保護下檢視與修改 Network、Protect 與 Access 設定。

可以做什麼
  • 檢視與設定 UniFi Network:裝置、AP 無線電調校、VLAN、WLAN、防火牆規則與區域策略、交換器連接埠、連接埠轉送、DHCP 保留、AP 群組、IDS/IPS、蜜罐與 Teleport VPN
  • 以 dry-run 預演變更,並用組合式開通工具在部分失敗時回滾
  • 啟用 Protect 模組後可檢視攝影機、移動事件、智慧偵測與錄影設定
  • 啟用 Access 模組後可讀取門禁、憑證、訪客、刷卡事件、集線器與讀卡機
  • 透過 controller 參數與 YAML 控制器檔案,在單一實例中管理多個站點
  • 將每次呼叫寫入已去識別化的 JSONL 稽核日誌,並可將日誌重放到新的控制器
適用情境
適合想讓助理協助維運自架 UniFi 閘道的情況,例如稽核防火牆與連接埠暴露、調校 Wi-Fi、開通網路與攝影機,同時藉由預演與稽核紀錄讓寫入操作可被複核。也可用樁模式在沒有硬體時先試用工具集。
執行需求
以 stdio 在本機執行,或作為 Docker/Helm 容器在 3714 埠提供 Streamable HTTP。真實模式需要 UNIFI_HOST 與 UNIFI_API_KEY(於閘道 Integrations 設定產生的本機 API 金鑰);Access 模組另需 UNIFI_ACCESS_HOST 與 UNIFI_ACCESS_API_KEY。HTTP 傳輸需要 MCP_UNIFI_AUTH_TOKENS 中的 bearer 權杖。STUB_MODE 預設為 true,不需硬體。需 UniFi Network 9.x 或更新版本。
安裝前請注意
真實模式下擁有等同管理員的閘道控制權:工具可建立、修改與刪除網路、防火牆策略、WLAN 與連接埠轉送,組合工具會執行多步驟變更。不需要寫入時請維持 MCP_UNIFI_READONLY=true 或使用唯讀 API 金鑰。HTTP 傳輸在缺少 bearer 權杖時會拒絕啟動,關閉驗證會讓任何連線用戶端取得完整控制器權限。自簽憑證主控台的 TLS 驗證預設關閉,建議改用憑證固定。API 金鑰屬機密,應透過環境變數或檔案形式提供。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 UniFi Gateway,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

mcp-unifi

Safety-first MCP server for self-hosted UniFi. Dry-run previews, JSONL audit log, composite rollback. Network + Protect + Access.

[CI] [Coverage] [cosign] [MCP] [License: MIT]

An MCP server built around the assumption that LLM-driven infrastructure calls need guardrails. Every destructive tool accepts dry_run=True and returns the predicted change set without writing. Composite tools (create_iot_network, create_guest_network, provision_homelab_service, provision_camera) capture pre-state and roll back applied steps on partial failure. Every call — dry-run or real — lands in a JSONL audit log with secrets scrubbed; the included mcp-unifi-replay CLI can re-issue a log against a fresh controller.

Beyond the safety substrate: Network tools for devices, AP radio tuning, VLANs, WLANs, firewall, switch ports, port forwards, DHCP reservations, AP groups, observability, Threat Management / IDS-IPS, Honeypot, and Teleport VPN, plus opt-in Protect (cameras, motion events, smart detections, recording config) and Access (doors, credentials, visitors, badge events, hubs / readers). Every tool accepts a controller parameter so one server instance manages multiple UniFi sites. Speaks both stdio (Claude Desktop, uvx, .dxt) and Streamable HTTP (Docker, Helm). The full, always-current tool list is in the auto-generated Tool Manifest. Works on any UniFi OS gateway running UniFi Network 9.x or newer (UDM, UDM Pro, UDM SE, UCG-Fiber, UCG-Ultra, UDR, UDW, UniFi OS Server), authenticated with a local API key from Settings → Control Plane → Integrations. Verified against a UCG-Fiber on UniFi OS 5.1.33 running UniFi Network 10.6.101 (2026-09-13). Firewall reads cover both the legacy rulesets (list_firewall_rules) and the Zone-Based Firewall (list_firewall_policies, list_firewall_zones), and audit_open_ports checks both, so a site that has migrated to zones is not reported as having no firewall. Legacy firewall writes (create_firewall_rule and friends) target /rest/firewallrule; zone policy writes (create_firewall_policy, update_firewall_policy, delete_firewall_policy) go through the official Integration API only, and the provisioning composites create a zone policy instead of a legacy rule on a zone-based site (ADR 0009). Network and WLAN writes go through the official Integration API where the request maps onto it exactly, and fall back to the private API otherwise; UNIFI_WRITE_API=private keeps every write private (ADR 0008). No Site Manager or cloud account required.

Install

Four supported paths. Pick the one that matches how you run Claude.

Docker

Long-running container, Streamable HTTP on port 3714. Best for homelab and multi-client setups.

HTTP transport refuses to start without a bearer token, so supply one:

bash
export MCP_UNIFI_TOKEN=$(openssl rand -hex 32)docker run --rm -p 3714:3714 \  -e STUB_MODE=true \  -e MCP_UNIFI_AUTH_TOKENS="$MCP_UNIFI_TOKEN" \  ghcr.io/pete-builds/mcp-unifi:latest

Clients then send Authorization: Bearer $MCP_UNIFI_TOKEN. For throwaway local testing on loopback only, -e MCP_UNIFI_AUTH_REQUIRED=false skips auth entirely; never use it on an interface reachable by anything else, because every connected client gets admin-equivalent access to the controller.

Claude Desktop (.dxt) — one-click

Download mcp-unifi-<version>.dxt from the latest release and double-click. Configuration is through a built-in UI in Claude Desktop. The bundle ships the Python runtime; no separate install needed. Uses stdio transport.

Helm

bash
helm repo add mcp-unifi https://pete-builds.github.io/mcp-unifi/helm install unifi mcp-unifi/mcp-unifi \  --set unifi.host=192.168.1.1 \  --set unifi.apiKey=<your-local-api-key> \  --set auth.tokens=$(openssl rand -hex 32)

The chart ships auth.required: true with auth.tokens: "", so the pod will not start until you set a token (or --set auth.required=false, which is only appropriate for a trusted single-tenant cluster).

uvx / pipx

Quick one-off runs straight from the GitHub repo. Stdio transport.

bash
uvx --from git+https://github.com/pete-builds/mcp-unifi mcp-unifi

Pin a release with @v0.5.0-rc.2 (or any tag) appended to the URL.

Full guides for each install path live in the docs site.

Design

  • Read-only mode. MCP_UNIFI_READONLY=true makes the server structurally unable to change anything: mutating tools are hidden from tools/list and refused on tools/call, so naming a hidden tool gets a normal error envelope instead of a write. Classification is declared per tool at registration (@audited("list_networks", mutates=False)), never inferred from tool names — twelve mutating tools, confirm_destructive_action among them, carry no create_/update_/delete_/set_ prefix. Registration fails if a tool has not declared a classification, so a new tool cannot default into being callable. Defense in depth on top of a read-only UniFi API key, not a replacement for it.
  • Safety primitives. Every destructive tool accepts dry_run=True and returns the predicted change set without writing. Composite tools (create_iot_network, create_guest_network, provision_homelab_service, provision_camera) capture pre-state and roll back applied steps on partial failure. Every tool call lands in a JSONL audit log with secrets scrubbed; the included mcp-unifi-replay CLI can re-issue a log against a fresh controller.
  • Single image, multi-controller. One container runs Network, Protect, and Access together. The same process manages multiple UniFi sites in parallel via the controller parameter and a YAML controllers file (MCP_UNIFI_CONTROLLERS_FILE). No need to run a separate process per controller.
  • API-key-first auth. Uses the local API key from Settings → Control Plane → Integrations against the /proxy/network/api endpoint. No username/password storage, no cloud account, no Site Manager dependency.
  • Multi-channel distribution. Docker, .dxt one-click for Claude Desktop, Helm chart, uvx. Listed on the official MCP Registry. Container images are cosign-signed (keyless OIDC) with a CycloneDX SBOM attached to each release.
  • Network + Protect + Access. Network on by default; Protect and Access opt-in via MCP_UNIFI_MODULES_ENABLED=network,protect,access. Access ships read-only (door unlocks and credential issuance require session-token auth and are deferred). UniFi Drive is not in scope.

Quick start

Fastest cold-start: Docker + Claude Code in stub mode, no hardware required.

  1. Start the container. Auth is on by default, so mint a token first:

    bash
    export MCP_UNIFI_TOKEN=$(openssl rand -hex 32)docker run -d --rm -p 3714:3714 \  -e STUB_MODE=true \  -e MCP_UNIFI_AUTH_TOKENS="$MCP_UNIFI_TOKEN" \  --name mcp-unifi ghcr.io/pete-builds/mcp-unifi:latest
  2. Register it with Claude Code, passing the token:

    bash
    claude mcp add --transport http --scope user unifi http://localhost:3714/mcp \  --header "Authorization: Bearer $MCP_UNIFI_TOKEN"
  3. Verify the connection:

    bash
    claude mcp list
  4. In a Claude Code session, ask: "list my UniFi devices". You'll get two stubbed devices back.

  5. When you're ready to point at a real gateway, drop stub mode:

    bash
    docker run -d --rm -p 3714:3714 \  -e STUB_MODE=false \  -e UNIFI_HOST=192.168.1.1 \  -e UNIFI_API_KEY=<your-local-api-key> \  -e MCP_UNIFI_AUTH_TOKENS="$MCP_UNIFI_TOKEN" \  --name mcp-unifi ghcr.io/pete-builds/mcp-unifi:latest

Generate the API key under Settings → Control Plane → Integrations → Create API Key on the gateway.

Configuration

All config is read from environment variables (and .env when present). The six most common:

VariableDefaultNotes
STUB_MODEtrueWhen false, real-mode controller config is required.
UNIFI_HOST(empty)Gateway IP or hostname. Required in real mode.
UNIFI_API_KEY(empty)Local API key. Required in real mode.
MCP_UNIFI_READONLYfalseWhen true, mutating tools are hidden and refused. See the Security guide.
MCP_UNIFI_MODULES_ENABLEDnetworkSet to network,protect,access to enable all three modules.
MCP_UNIFI_CONTROLLERS_FILE(unset)YAML file with named controllers for multi-site.
MCP_UNIFI_OTEL_ENABLEDfalseOptional OpenTelemetry tracing, one span per tool call. Off by default and the SDK is not a dependency. See Operations.
UNIFI_API_KEY_FILE(unset)Read the API key from a file (a Docker or Kubernetes secret mount) instead of UNIFI_API_KEY. Wins if both are set, and turns TLS verification on by default.
UNIFI_ACCESS_API_KEY_FILE(unset)File-backed form of UNIFI_ACCESS_API_KEY.
UNIFI_OS_PASSWORD_FILE(unset)File-backed form of UNIFI_OS_PASSWORD.
MCP_UNIFI_AUTH_TOKEN_FILE(unset)File holding one bearer token (or the full MCP_UNIFI_AUTH_TOKENS grammar). Adds to whatever MCP_UNIFI_AUTH_TOKENS defines.
MCP_UNIFI_CLIENT_ID(unset)Client name for the bare token in MCP_UNIFI_AUTH_TOKEN_FILE.
UNIFI_PINNED_CERT(unset)Path to the console's own certificate (PEM) from mcp-unifi-pin-cert. When set, that certificate is the only one the server will accept from this controller. See below.

Full env var reference and the multi-site YAML schema are in the Configuration docs.

File-backed secrets

Every secret has a _FILE twin for Docker and Kubernetes secret mounts. The environment-variable form keeps working and is not deprecated by this release; the file form is opt-in and carries the hardened defaults inside it, so a controller configured by api_key_file verifies the gateway's TLS certificate unless you set verify_ssl: false. In a controllers YAML:

yaml
- name: lan  host: 192.168.1.1  api_key: <inline key>            # verify_ssl stays false: self-signed console on a LAN- name: datacenter  host: unifi.example.com  api_key_file: /run/secrets/unifi_api_key   # verify_ssl defaults to true here

A missing, empty or unreadable secret file fails startup with a message naming the controller and the field, never the contents. On every boot the server logs one line per controller still on the environment-variable shape or running with TLS verification off. That warning is the first step of a dated path (opt-in, then warn, then flip at a major release) recorded in ADR 0007; nothing is refused. docker-compose.yml shows the secret mount.

Certificate pinning

UniFi consoles present a self-signed certificate whose name list does not include the address you connect to, so ordinary TLS verification can never pass against one and verify_ssl defaults to off. Pinning closes that gap without a CA: record the console's certificate once, and from then on the server accepts that certificate and nothing else.

bash
mcp-unifi-pin-cert 192.168.1.1 --out /etc/mcp-unifi/pins/home.pem# prints the SHA-256 fingerprint; compare it against the console before trusting itssh [email protected] 'openssl x509 -in /data/unifi-core/config/unifi-core.crt -noout -fingerprint -sha256'# the same fingerprint read on the console itself, over a channel the pin does not depend on

Then set pinned_cert: /etc/mcp-unifi/pins/home.pem on the controller in the YAML, or UNIFI_PINNED_CERT for the single-controller env form. A pinned controller verifies every connection against that certificate and fails closed if the console presents anything else; there is no fallback. If a firmware update regenerates the console certificate, requests fail with a message that names the re-pin command, and you re-run it with --force after checking the new fingerprint. The server never fetches and trusts a certificate on its own: the bootstrap is always this explicit command. Pass --expect-fingerprint to have it refuse a certificate that does not match what you read off the console. In the container, mount the pin read-only (the compose file shows where).

How this is built

The engineering scaffolding around the tool surface (see the Tool Manifest for the current count), in case you want to know what's holding it up:

Test discipline. ~880 tests across unit, integration, and property-based (Hypothesis) — see pytest --collect-only for the current count. HTTP is mocked with respx so tests don't hit a real controller. Coverage gated at 80% branch coverage in CI; current floor is 90%.

Code quality gates. Ruff (pycodestyle, pyflakes, isort, flake8-bugbear, pyupgrade, simplify, flake8-bandit security ruleset, comprehensions) plus mypy strict (no implicit Any, unreachable code flagged, unused ignores flagged). Pre-commit hooks run lint, format, types, and regenerate the tool manifest with a drift check, so bad code never reaches CI.

CI pipeline (5 gated jobs). Every PR runs lockfile-drift check → lint + type check → tests + coverage → multi-arch Docker build → Trivy filesystem and image scan (HIGH/CRITICAL fails the build). Each gates the next.

Release pipeline. A git tag vX.Y.Z push triggers a multi-arch (linux/amd64 + linux/arm64) Docker build, cosign keyless signing via sigstore OIDC, SLSA build provenance attestation, CycloneDX SBOM via Syft attached to the GitHub release, a .dxt bundle for Claude Desktop one-click install, GHCR push with vX.Y.Z / X.Y / latest tags, and an auto-bump of the example docker-compose.yml on main.

Dependency hygiene. Hash-pinned via pip install --require-hashes. A custom CI step verifies every pinned dep in requirements.in matches requirements.lock so no one can bump one without the other. Dependabot auto-merges safe patches. The base image is digest-pinned, not tag-pinned.

Container hardening. Runs as non-root UID 1000, no shell, no home directory. Read-only root filesystem enforced via Docker / Helm. /tmp is a 16MiB tmpfs. no-new-privileges set. All Linux capabilities dropped. Dedicated /health endpoint keeps the streamable-HTTP transport from logging 406 noise on every Docker healthcheck.

Security posture. Bearer-token authentication on the HTTP transport, secure by default (refuses to start without tokens). Audit log records each authenticated client_id per call with secret scrubbing on api_key, passphrase, password, secret, token substring matches. API keys wrapped in pydantic SecretStr. SECURITY.md with a private disclosure path.

Distribution surface. GHCR (signed multi-arch), Smithery (registered), MCP Registry (listed), Helm chart (Secret/Deployment/Service/Ingress/NetworkPolicy templates), .dxt bundle, uvx / pipx.

Documentation discipline. Astro Starlight site auto-deploys to GitHub Pages. The per-tool reference pages are generated from FastMCP introspection by scripts/generate_tool_manifest.py, and the pre-commit hook regenerates and drift-checks them so code and docs can't diverge. CHANGELOG follows Keep a Changelog format.

Version discipline. pyproject.toml, the git tag, the CHANGELOG entry, the Docker image tag, the docker-compose example, and the Helm chart appVersion all stay aligned because the release workflow enforces it. There is never a moment where the docs and the code disagree about what version this is.

Development

Clone, install dev dependencies, and wire up the pre-commit hooks:

bash
git clone https://github.com/pete-builds/mcp-unifi.gitcd mcp-unifipython -m venv .venv && source .venv/bin/activatepip install -e ".[dev]" pre-commitpre-commit install

The pre-commit hooks run ruff (lint + format), mypy strict, and the tool manifest generator. The manifest hook regenerates docs/site/src/content/docs/tools/ whenever any file under src/mcp_unifi/modules/ changes and fails the commit if the on-disk manifest drifts from the registered tool surface. Run the tests with pytest.

To regenerate the manifest manually:

bash
python scripts/generate_tool_manifest.py        # writepython scripts/generate_tool_manifest.py --check  # CI-style drift check

Docs

License

MIT.

來源:README.md,提交 78e0d3d

工具

0
SourceWeft 曾在隔離沙箱中以無憑證方式啟動該軟體包一次,以列出其工具,但未能完成:該軟體包類型無法在沙箱中執行。

版本歷史

5
  1. v0.27.0最新Oct 21, 2026
  2. v0.26.0Oct 18, 2026
  3. v0.25.0Oct 2, 2026
  4. v0.24.0Oct 1, 2026
  5. v0.23.0Sep 16, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分