Get UniFi Network application version and basic info. Use this first to verify the connection is working and check the controller version. If this fails, check UNIFI_API_URL and UNIFI_API_KEY.

List all UniFi sites on this controller. Most controllers have a single 'default' site, but multi-site setups exist. The site ID is required for nearly all other tools — call this first if you need it. If UNIFI_SITE_ID is set, that site is used automatically.

List all adopted UniFi devices (APs, switches, gateways, etc.) with their state, firmware version, model, IP, and MAC. Use this to assess fleet health: look for OFFLINE devices, firmware that needs updating (firmwareUpdatable=true), and feature/interface differences across your deployment. Determine each device's role from its features: switching+accessPoint = gateway combo (UDM/UDR/UXG), accessPoint only = AP, switching only = switch. Supports filtering — e.g. filter="state.eq('OFFLINE')" to find down devices.

Get full details for a single adopted device including uplink topology, radio interfaces, port configuration, features, and provisioning info. Use this to inspect a specific device after list_devices identifies one of interest. The response includes interfaces.radios (for APs) and interfaces.ports (for switches).

Get real-time performance statistics for a device: CPU utilization, memory usage, load averages (1/5/15 min), uptime, uplink TX/RX rates, and radio stats. Key for diagnosing performance issues — high CPU or memory on an AP often explains client disconnects. Compare load averages across devices to spot overloaded APs.

List devices discovered on the network but not yet adopted. These are new devices plugged in or factory-reset devices waiting for adoption. Use device_action with action 'adopt' to bring them under management.

Execute an action on an adopted device. Currently supports RESTART (reboot). WARNING: restart will briefly disconnect all clients on that device.

Update properties of an adopted device — primarily for renaming. Use this to give devices self-documenting names following the {role}-{location} convention. Determine the role from the device's features array: switching+accessPoint (UDM/UDR/UXG combo) → gw, accessPoint only → ap, switching only → sw. Then append the physical location: gw-office, ap-living-room, sw-desk. Call list_devices or get_device first to check the current name and features. Uses the classic Network Application REST API (the integration API v1 does not support device updates).

List all currently connected clients (wired, wireless, VPN, guest). Shows client type, MAC, IP, connection time, and authorization status. Use this to check client distribution across APs — if one AP has 20 clients and another has 3, there may be a roaming or placement issue. Also check for unauthorized guests that may need attention. To identify unknown clients, check: (1) MAC address — if bit 1 of the first octet is set (second hex char is 2/3/6/7/a/b/e/f), the MAC is randomized (modern phone/laptop/tablet); if not, the first 3 octets are an OUI identifying the manufacturer. (2) IP address — cross-reference with list_networks to determine which VLAN/network the client is on. (3) Connection type — WIRED clients are typically infrastructure (servers, smart hubs, media devices); WIRELESS with randomized MAC are personal devices. (4) Name — a descriptive hostname means the device announced itself via DHCP; a raw MAC address means the device didn't announce a name and needs an alias.

Get detailed info for a single connected client. Shows which AP/switch it's connected to, signal strength, connection type, and network membership. Use this to troubleshoot a specific device's connectivity.

Execute hotspot guest access actions on a connected client. AUTHORIZE_GUEST_ACCESS grants guest WiFi access, UNAUTHORIZE_GUEST_ACCESS revokes it.

List ALL historically known clients (not just currently connected) with rich metadata from the classic REST API. Returns fields the integration API doesn't expose: oui (manufacturer from MAC OUI lookup), hostname (DHCP hostname), last_radio (ng=2.4GHz, na=5GHz), last_connection_network_name, first_seen, last_seen. Use this as the FIRST identification tool for unknown clients — the oui field identifies the manufacturer without any network scanning. Works across VLANs (no firewall limitations like nmap/dns-sd).

Set or update the friendly name (alias) for a network client. Use this to replace MAC-only or generic hostnames with descriptive names. Convention: {type}-{owner-or-purpose} — e.g. 'phone-pedro', 'laptop-work', 'tv-living-room', 'speaker-kitchen'. Identify the client's MAC from list_clients first. Uses the classic Network Application REST API (the integration API v1 does not support client updates).

List all network configurations including VLAN IDs, DHCP settings, and status. Check for proper network segmentation — IoT devices should be on a separate VLAN from your main network. The 'default' network (VLAN 1) is the untagged LAN. Additional networks use VLAN IDs >= 2.

Create, update, or delete a network. CREATE: provide name, vlanId (>=2 for non-default), enabled, management type. UPDATE: provide networkId + fields to change. DELETE: provide networkId — WARNING: disconnects all clients on that network. Use list_networks to see existing configs before modifying. For VLAN segmentation (e.g. IoT isolation), create a new network with a unique VLAN ID, then assign a WiFi SSID to it with manage_wifi.

List all WiFi SSIDs (broadcasts) with their security config, data rates, client isolation, multicast settings, and associated network. Key things to check for optimization: - Security type (WPA3 preferred over WPA2) - Data rates (higher minimum rates improve airtime efficiency) - Client isolation (should be ON for guest networks) - Multicast-to-unicast conversion (ON improves performance with smart home devices) - Hidden SSID (avoid — causes probe request overhead)

Create, update, or delete a WiFi SSID (broadcast). CREATE requires: type, name, enabled, securityConfiguration, multicastToUnicastConversionEnabled, clientIsolationEnabled, hideName, uapsdEnabled. Key config fields for optimization: - basicDataRateKbpsByFrequencyGHz: set 2.4GHz min to 12000+ and 5GHz to 12000+ to reduce legacy rate overhead - clientIsolationEnabled: true for guest SSIDs - multicastToUnicastConversionEnabled: true for better smart home performance - broadcastingDeviceFilter: limit which APs broadcast this SSID - network: associate with a VLAN network for segmentation Use list_wifi to see existing configs before modifying.

List all firewall zones. Zones group network interfaces for policy enforcement. A well-segmented network has separate zones for LAN, IoT, Guest, and WAN. Policies are defined between zone pairs (source → destination).

List all firewall policies with their source/destination zones, actions, and ordering. Policies are evaluated in order — first match wins. Check for: - Overly permissive rules (any→any allow) - Missing inter-zone rules (IoT should not reach LAN) - Disabled policies that may need attention Use manage_firewall_policy to create/modify/reorder policies.

Create, update, or delete a custom firewall zone. Zones are containers for network interfaces — create one per security boundary (e.g. 'IoT', 'Guest', 'Cameras'). Default zones (LAN, WAN) cannot be deleted. After creating a zone, assign networks to it and create policies between zones.

Create, update, delete, or reorder firewall policies. Policies define traffic rules between zone pairs. CREATE requires: enabled, name, action, source (with zoneId), destination (with zoneId), ipProtocolScope, loggingEnabled. REORDER: pass data as { policyIds: ['id1', 'id2', ...] } to set evaluation order. CRITICAL: Policy order matters — first match wins. Always verify order after changes.

Save the network profile generated during init. This persists the profile to ~/.unifi-mcp/profile.json so it's available as the unifi://network/profile resource in all future conversations. Only call this after completing the init discovery flow.

List, create, update, delete, or reorder ACL (Access Control List) rules. ACL rules provide fine-grained network access control beyond firewall policies. LIST: returns all ACL rules with ordering. CREATE: define source/destination criteria and allow/deny action. REORDER: pass { ruleIds: ['id1', 'id2', ...] } — order matters, first match wins.

List, create, update, or delete DNS filtering policies. DNS policies control which domains clients can resolve — use for content filtering, ad blocking, or security (blocking known malicious domains). LIST: returns all DNS policies. CREATE/UPDATE: define filtering rules and target clients/networks.

List, create, update, or delete traffic matching lists. Traffic rules define patterns for matching network traffic — used by firewall policies and QoS rules to identify specific traffic types (e.g. gaming, video streaming). LIST: returns all traffic matching lists. CREATE/UPDATE: define matching criteria (ports, protocols, IP ranges, DPI apps).

List, create, or delete hotspot vouchers for guest WiFi access. LIST: returns all active vouchers. CREATE: generate one or more vouchers with time limit, optional data cap, and optional rate limiting. Each voucher is a unique code guests enter to get online. CREATE params: count (number to generate), name (note), timeLimitMinutes (required), authorizedGuestLimit, dataUsageLimitMBytes, rxRateLimitKbps, txRateLimitKbps. DELETE: remove a single voucher by ID, or delete all vouchers (use with caution).

List WAN (internet uplink) interfaces with status, IP, and throughput. Use this to diagnose internet connectivity issues or check multi-WAN setups. Shows each WAN port's connection state and current bandwidth.

List VPN tunnels and servers. Returns both site-to-site VPN tunnels (connecting remote sites) and VPN servers (for remote client access). Check tunnel status and uptime for connectivity monitoring.

List DPI (Deep Packet Inspection) application categories and applications. Returns the catalog of recognized traffic types (e.g. Streaming, Gaming, Social Media) and specific applications (e.g. Netflix, YouTube, Zoom). Use this to understand traffic classification for creating traffic rules or analyzing what's consuming bandwidth on the network.

Search the UniFi action catalog and return action IDs that can be executed via execute_action. Use this when the direct tool list is too large or when you want category-focused discovery.

Execute a UniFi action by actionId using a generic params object. This is useful for agents that prefer a stable two-tool interface: search_actions + execute_action.