UniFi Fabric MCP Server
Related Servers
Alternatives to UniFi Fabric MCP Server
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityDmaintenanceA server implementation that enables natural language interactions with UniFi network devices by wrapping the UniFi Network API for AI agents like Goose and Claude.10MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to query and manage UniFi controllers and console fleets through natural language, using the UniFi Site Manager Cloud Connector. Runs remotely on Cloudflare Workers with no local install.MIT
- AlicenseDqualityDmaintenanceEnables comprehensive management of UniFi network infrastructure through the UniFi Cloud API, including device control, client management, camera settings, and access door control through natural language.3935 npmApache 2.0
- AlicenseAqualityCmaintenanceMCP server that turns Claude into a UniFi network specialist. Manage devices, optimize WiFi, audit security, and troubleshoot your network through natural language.3116 npm2MIT
- AlicenseAqualityDmaintenanceControl your UniFi network via AI with a lightweight 2-tool MCP server that supports both cloud and local UniFi controllers.329 npmMIT
- AlicenseBqualityDmaintenanceEnables AI assistants to manage UniFi network infrastructure through 50+ tools covering devices, clients, networks, WiFi, firewall rules, and guest access using the official UniFi Network API.5226 npm5MIT
TDQS
Scored across 283 tools
The overwhelming majority of tools are cleanly separated by resource (networks, firewall policies, cameras, sirens, subscribers…), and the long descriptions usually disambiguate well. However, several genuinely confusable pairs exist — list_devices vs list_all_devices vs search_device_fleet vs search_across_sites all return device lists over overlapping scopes, and generic execute_client_action/execute_device_action wrappers coexist with dedicated block/unblock/reconnect and restar/ocate/upgrade tools. get_isp_metrics vs query_isp_metrics and the dual WLAN/wifi_broadcast representations add further selection risk.
The core CRUD backbone (list_/ get_/ create_/ update_/ delete_ + resource) is applied with striking consistency across 200+ tools, and family prefixes (hotspot_, firewall_, inner_space_?, carrier_, mobility_) reinforce recognizability. Deviations exist but are localized: the Protect action tools mix styles (siren_play vs block_client), P TZ uses a prefix style (ptz_goto_preset), and update_arm_profile_settings actually selects the active profile rather than updating a profile's settings — a genuinely misleading name.
283 tools is far beyond the 50+ threshold the rubric treats as an extreeme mismatch, and it exceeds what most models' tool-selection windows can even accept. The multi-product scope (Network, Protect, InnerSpace, Carrier, Mobility) justifies a large surface, but near-duplicates like list_devices/list_all_devices and the execute_* wrappers bloat the count further; this server would be far more usable split into per-application servers.
Coverage is exceptional: full CRUD for networks, firewall policies, WLANs, VPN servers, traffic rules/routes, hotspot vouchers/operators, ACL rules, DNS policies, device tags, and nearly every Protect device family (cameras, sirens, relays, speekers, fobs…), plussite-manager, carrier, mobility, and InnerSpace surfaces. The generic fabric_connector_get/post/put/patch/delete escape hatch closes any remaining gap. Minor read-only holes exist (classic firewall rules/groups, RADIUS accounts, DDNS, hotpot packages) but are mostly upstream limitations or legacy-API by design.