omada-controller-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OMADA_BASE_URL | No | URL of the Omada SDN controller. | https://your-controller.local:8043 |
| OMADA_CLIENT_ID | No | Client ID used to authenticate with the Omada controller. | |
| OMADA_VERIFY_SSL | No | Whether to verify TLS certificates. Usually false for self-signed LAN certificates. | false |
| FASTMCP_TRANSPORT | No | Transport mode for the MCP server: 'stdio' or 'http'. | stdio |
| OMADA_CLIENT_SECRET | No | Client secret used to authenticate with the Omada controller. | |
| OMADA_CLIENT_ID_FILE | No | Path to a file containing the Omada client ID (alternative to OMADA_CLIENT_ID). | |
| OMADA_MCP_AUTH_TOKEN | No | Bearer token used to authenticate MCP clients over HTTP. | |
| OMADA_CLIENT_SECRET_FILE | No | Path to a file containing the Omada client secret (alternative to OMADA_CLIENT_SECRET). | |
| OMADA_MCP_AUTH_TOKEN_FILE | No | Path to a file containing the MCP auth token (alternative to OMADA_MCP_AUTH_TOKEN). |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| server_infoA | Report which Omada API spec this server is running against. |
| refresh_catalogA | Re-fetch the controller's live OpenAPI spec and rebuild the operation catalog. Call this after a controller firmware upgrade to pick up new/changed/ removed endpoints without restarting this server. |
| search_operationsA | Search this controller's Omada API operations by keyword. Matches against operation id, summary, and path, e.g. "client", "reboot", "wlan ssid". Returns operation_id, method, path, and summary for each match - call get_operation_schema on one before calling it if its parameters aren't obvious from the summary. |
| get_operation_schemaA | Get one operation's method, path, parameters, and request body schema. |
| call_operationA | Call any cataloged Omada API operation by its operation_id. omadacId is filled in automatically. Other path parameters (e.g. siteId, apMac) go in path_params; query-string parameters in query_params; a JSON request body (for POST/PUT operations that take one) in body. Use get_operation_schema first if unsure what an operation needs. |
| list_sitesC | List sites this controller manages. |
| list_devicesA | List all managed devices (access points, switches, gateways) across every site. |
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 7 tools
Each tool serves a clearly distinct role: introspection (server_info), schema lookup (get_operation_schema), catalog management (refresh_catalog), discovery (search_operations), generic invocation (call_operation), and domain conveniences (list_sites, list_devices). No two tools have overlapping purposes; even the metadata tools chain together in an obvious workflow.
Most tools follow a clean verb_noun snake_case pattern: get_, refresh_, search_, call_, list_. server_info is the only deviation, being noun_noun instead of get_server_info, but it remains readable and does not introduce style mixing.
Seven tools is well within the ideal 3-15 range and appropriately scoped for a generic API wrapper with a couple of convenience helpers. Each tool earns its place without redundancy or bloat.
The dynamic call_operation plus catalog discovery tools give full coverage of the Omada API surface, while list_sites and list_devices address common high-level needs. The set covers discovery, schema inspection, invocation, and common queries with no obvious dead ends.