omada-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OMADA_ALLOW_WRITES | No | Set to 1 or true to unlock write operations. Unset or 0 → every non-GET is refused. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| omada_statusA | Health and wiring check: controller version/info, Open API token state, write-mode, deny-list state, API index freshness, legacy web-session availability, and the site list. Run this first when anything looks off. |
| omada_sitesA | List the sites on this controller (siteId + name), which most other calls need. |
| omada_devicesB | Adopted Omada devices for a site (gateways, switches, APs) with model, MAC, IP, status, uptime and firmware. |
| omada_clientsB | Clients currently connected to a site: name, MAC, IP, wired/wireless, SSID, signal, traffic. Paginated. |
| omada_ssidsB | WLAN groups on the site and the SSIDs inside each: name, band, security, guest-network and VLAN settings. |
| omada_search_apiA | Search this controller's own OpenAPI spec for endpoints. Use it before omada_call whenever the exact operation is not already known - e.g. "poe port", "block client", "port forwarding", "firmware", "vlan". |
| omada_describe_apiA | Full detail for a single operation: path/query parameters, request-body schema and response shape. Accepts an operationId from omada_search_api, or "METHOD /path". |
| omada_callA | Invoke any controller Open API endpoint. Give either operationId (from omada_search_api) or method+path. {omadacId} and {siteId} are filled in automatically. Non-GET calls are refused in read-only mode, and even when writes are unlocked they return a dry-run preview unless confirm: true - show that preview to the user and get an explicit yes first. |
| omada_ui_callA | Fallback transport for settings the Open API does not expose: the session API the Omada web UI itself uses (/{omadacId}/api/v2/...). Requires OMADA_WEB_USER/PASS. Same write rules as omada_call. Find paths by watching the browser network tab, or from the Omada community API notes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool has a clearly separated role: status, sites, devices, clients, and SSIDs are distinct resource views, while search_api, describe_api, call, and ui_call form a staged API workflow. There is minor overlap between omada_status (which also lists sites) and omada_sites, and between omada_call and omada_ui_call, but the descriptions make the boundaries explicit enough.
The omada_ prefix and snake_case are consistent, but the pattern is mixed: status/sites/devices/clients/ssids are noun-only names, while search_api/describe_api/call/ui_call are verb-oriented. This is readable and not chaotic, yet it does not follow a uniform verb_noun convention.
Nine tools is well-scoped: five high-level read/resource tools cover the common Omada surfaces, and four API/UI tools provide discovery, documentation lookup, and safe execution. Each tool earns its place without the set feeling bloated or thin.
The high-level tools cover the main query needs, while omada_search_api, omada_describe_api, omada_call, and omada_ui_call fill essentially any gap in the controller's exposed API or UI-facing session API. The dry-run/confirm write flow also prevents dead ends for mutating operations.