What can you do with this server?

This server exposes TP-Link Omada SDN controller management as MCP tools for reading and configuring sites, devices, clients, networks, switches, firewalls, schedules, and site settings. * Read/monitor infrastructure: list sites, devices, clients, device stats, client activity/history, threat list, events/logs, internet/WAN info, LAN/WLAN configs, SSIDs, firewall settings/rules, IP groups, routes, port forwardings, switch ports/stacks, cable test results, and firmware details. * Manage devices and clients: adopt/reboot devices, set device LEDs, start firmware upgrades, block/unblock/reconnect clients, rename clients, reserve fixed IPs, and set rate limits. * Configure networks and firewalls: create/update/delete LAN networks and LAN profiles, update firewall settings, create/delete firewall ACLs, and manage switch VLAN trunking. * Manage switch ports: set port profile, PoE, name, status, and profile override on individual or multiple ports; run cable tests. * Schedule and site settings (internal API): list/create/update/delete reboot schedules and PoE schedules, list time range profiles, get/patch site settings, and set the site timezone. * Perform arbitrary operations: call any Omada API endpoint directly via genericApiCall. * Auth/compatibility notes: schedule, site-settings, firewall ACL, IP group, switch port, event, and WAN connection tools require OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD; controller firmware affects which endpoints work.

Which integrations are available for this server?

Provides tools for managing TP-Link Omada SDN controllers, including reading and managing sites, devices, clients, networks, switch ports, firewalls, schedules, and site settings.

How do I use Omada MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Omada MCP Server Show me all devices currently offline in my main site" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Omada MCP Server

by Zesty0wl

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Omada MCP Server

MCP server for TP-Link Omada SDN controllers. Exposes 72 tools for reading and managing sites, devices, clients, networks, switch ports, firewalls, schedules and site settings over the Model Context Protocol.

Lineage and attribution

This is a fork of a fork. Credit where it is due:

Repo	Contribution
MiguelTVMS/tplink-omada-mcp	The original MCP server — transport, auth, tool scaffolding, read tools
realtydev/omada-mcp	Added full CRUD, switch port management, batch operations, cable testing, and the internal web UI API fallback for firewall ACLs. Last updated February 2026
Zesty0wl/omada-mcp (this repo)	Forked August 2026 from `realtydev` @ `376e242`. Adds scheduling and site settings, extends the internal-API fallback, and documents actual controller compatibility

What this fork adds

New: scheduling and site settings (12 tools). Reboot schedules, PoE schedules, time range profiles, and site settings including timezone. None of these exist in the Open API; they are internal-API only.

Extended internal-API fallback. Upstream routes only firewall ACLs through the internal web UI API. This fork extends that to getSwitchPorts and listEvents, which return -1600 Unsupported request path on the Open API of every controller tested.

Documented OMADA_WEB_USERNAME / OMADA_WEB_PASSWORD. Upstream reads these in src/config.ts but never documents them, so the internal-API code path is effectively unreachable unless you read the source. They are documented below.

Honest compatibility matrix. Upstream's README lists 60+ tools without noting that a large fraction return -1600 on common hardware. See Controller compatibility.

Test fixes. tests/tools/index.test.ts asserted a stale 45-tool manifest against 60 registered tools, so the suite failed on a clean checkout. The manifest now matches the registered set.

Related MCP server: tplink-omada-mcp

Quick start

{
  "mcpServers": {
    "omada": {
      "command": "node",
      "args": ["/path/to/omada-mcp/dist/index.js"],
      "env": {
        "OMADA_BASE_URL": "https://192.168.1.10",
        "OMADA_CLIENT_ID": "your-client-id",
        "OMADA_CLIENT_SECRET": "your-client-secret",
        "OMADA_OMADAC_ID": "your-omadac-id",
        "OMADA_SITE_ID": "your-site-id",
        "OMADA_WEB_USERNAME": "controller-login",
        "OMADA_WEB_PASSWORD": "controller-password",
        "OMADA_STRICT_SSL": "false"
      }
    }
  }
}

Build first with npm install && npm run build.

Getting your credentials

OMADA_CLIENT_ID / OMADA_CLIENT_SECRET come from Settings → Platform Integration → Open API → Add New App. Choose Client Mode (the server only ever uses the client_credentials grant — a redirect URL is never used) and grant a role with write access; read-only blocks every config tool.

OMADA_OMADAC_ID is available unauthenticated:

curl -sk https://<controller>/api/info

OMADA_SITE_ID is optional — omit it and call listSites to find it.

Environment variables

Variable	Required	Default	Description
`OMADA_BASE_URL`	Yes	-	Controller URL
`OMADA_CLIENT_ID`	Yes	-	Open API client ID
`OMADA_CLIENT_SECRET`	Yes	-	Open API client secret
`OMADA_OMADAC_ID`	Yes	-	Controller ID
`OMADA_SITE_ID`	No	-	Default site ID
`OMADA_WEB_USERNAME`	No	-	Controller web UI login. Enables the internal API — required for schedules, site settings, firewall ACLs, IP groups, switch ports, events and WAN connect/disconnect
`OMADA_WEB_PASSWORD`	No	-	Controller web UI password
`OMADA_STRICT_SSL`	No	`true`	Set `false` for self-signed certificates
`OMADA_TIMEOUT`	No	`30000`	Request timeout (ms)

Server transport variables (MCP_SERVER_USE_HTTP, MCP_HTTP_PORT, MCP_HTTP_BIND_ADDR, MCP_SERVER_LOG_LEVEL, MCP_SERVER_LOG_FORMAT, MCP_SERVER_STATEFUL, MCP_HTTP_TRANSPORT) are unchanged from upstream.

Controller compatibility

Omada controllers expose two APIs: the documented Open API (/openapi/v1/..., OAuth) and the undocumented internal web UI API (/{omadacId}/api/v2/..., cookie + CSRF). Which endpoints exist on which varies by controller model and firmware — the Open API surface is considerably smaller than its documentation suggests.

Verified against OC200 hardware controller, firmware 6.2.14.12 (ER7206 gateway, T1600G-28PS and SG2008P switches, EAP610 access points):

Work over the Open API alone — listSites listDevices getDevice getSwitch listClients getClient listDevicesStats listMostActiveClients listClientsActivity listClientsPastConnections getInternetInfo getLanNetworkList getLanProfileList getWlanGroupList getSsidList getSsidDetail getFirewallSetting updateFirewallSetting searchDevices rebootDevice adoptDevice blockClient unblockClient reconnectClient updateClient setDeviceLed getFirmwareDetails startFirmwareUpgrade listRoutes listLogs listPortForwardings getCableTestResults getSwitchStackDetail updateSwitchPort setSwitchPort* batchSetSwitchPort* and the LAN network/profile write tools. listEvents and getSwitchPorts work here too, with reduced detail.

Require OMADA_WEB_USERNAME / OMADA_WEB_PASSWORD — all schedule and site settings tools, listFirewallAcls, createFirewallAcl, deleteFirewallAcl, listIpGroups, setGatewayWanConnect. getSwitchPorts and listEvents prefer the internal API when it is available.

Not working on this hardware — getPortForwardingStatus: the insight endpoint answers -1001 Invalid request parameters for both User and UPnP even with the documented page parameters; listPortForwardings returns the configured rules instead. startCableTest has not been exercised, because it disrupts the links it tests. getCableTestResults and getSwitchStackDetail do route on 6.2.14.12 — 0.6.0 listed them as absent — though this site has no stack to read.

A note on -1600. Earlier releases listed far more tools here. Most of them were calling the wrong HTTP method or path, not a missing endpoint: the controller answers -1600 Unsupported request path for PUT on a PATCH-only route exactly as it does for a path that does not exist. Every endpoint this server calls has since been checked against the controller's own OpenAPI document in docs/openapi/ — see the CHANGELOG for what changed.

Your controller may differ. genericApiCall is the escape hatch for anything not covered.

Discovering endpoints for your firmware

The controller ships no OpenAPI spec, but its web UI declares every endpoint it calls. Dump the full internal API surface for your firmware — no credentials needed:

node scripts/dump-endpoints.mjs https://192.168.1.10

controller: 6.2.14.12 (api v3)
manifest:   /js/su/configJson-9cdc9a57dd.js
modules:    225
endpoints:  224
written:    docs/endpoints/controller-api3-6.2.14.12.txt

Dumps are committed per firmware under docs/endpoints/. The method, the Open API vs internal API distinction, and the error codes that tell a missing endpoint (-1600) from a wrong argument (-1001) are all in docs/endpoint-discovery.md. That is how the schedule endpoints in this fork were found.

If you run different hardware or firmware, a dump and a compatibility correction is the most useful contribution you can make — see CONTRIBUTING.md.

Tools

Scheduling and site settings (new in this fork — internal API)

Tool	Description
`listRebootSchedules`	List reboot schedules, their target devices and next execution time
`createRebootSchedule`	Create a daily/weekly/monthly reboot schedule for specific devices
`updateRebootSchedule`	Replace an existing reboot schedule
`deleteRebootSchedule`	Delete a reboot schedule
`listPoeSchedules`	List PoE schedules
`createPoeSchedule`	Create a PoE schedule (power-cycles switch ports on a time range)
`updatePoeSchedule`	Replace an existing PoE schedule
`deletePoeSchedule`	Delete a PoE schedule
`listTimeRanges`	List time range profiles — the primitive PoE/WLAN/ACL schedules bind to
`getSiteSettings`	Timezone, DST, NTP, mesh, band steering, airtime fairness, roaming, LED, auto-upgrade
`updateSiteSettings`	Patch individual site settings sections
`setSiteTimeZone`	Set the site timezone, handling the required `region`/`scenario` fields

Check your timezone and your DST setting before trusting any schedule. Controllers commonly ship set to UTC. Worse, Omada treats daylight saving as a separate setting from the timezone — site.dst.enable, with manual recurring start/end rules — and it is off by default. Setting an IANA zone such as Europe/London does not on its own make schedules observe summer time: the controller stays on the standard offset year-round, so a "06:00" reboot fires at 07:00 wall-clock from March to October.
Verify with getSiteSettings (check site.timeZone and site.dst.enable) and with listRebootSchedules — a schedule's nextExecute is a UTC epoch, and notInDst: true confirms DST is not being applied. setSiteTimeZone sets the zone; configuring the DST rules must currently be done in the web UI under Site Settings.

Read tools

Tool	Description
`listSites`	List all sites on the controller
`listDevices`	List devices for a site
`listClients`	List active clients for a site
`getDevice`	Details for a specific device
`getClient`	Details for a specific client
`getSwitch`	Full switch info including `portList`
`getSwitchPorts`	All ports for a switch (internal API)
`getSwitchStackDetail`	Switch stack configuration and status
`searchDevices`	Search devices globally across all sites
`listDevicesStats`	Device statistics with pagination and filtering
`listMostActiveClients`	Top clients by traffic
`listClientsActivity`	Client activity time series
`listClientsPastConnections`	Historical client connections
`getThreatList`	Security threat list
`getInternetInfo`	Internet / WAN configuration
`getPortForwardingStatus`	Port forwarding status (User/UPnP) — see compatibility notes
`listPortForwardings`	Configured port forwarding rules: name, status, WAN port, external/internal port, target IP
`getLanNetworkList`	LAN networks and VLAN settings
`getLanProfileList`	LAN profiles for switch ports
`getWlanGroupList`	WLAN groups
`getSsidList`	SSIDs in a WLAN group
`getSsidDetail`	Detailed SSID configuration
`getFirewallSetting`	Firewall settings and policies
`getFirmwareDetails`	Latest firmware info for a device (current version, available update)
`listEvents`	Paginated site events (internal API)
`listLogs`	Site event log over the Open API, filterable by time window and module
`listFirewallAcls`	Firewall ACL rules (internal API)
`listIpGroups`	IP/port groups for ACL rules (internal API)
`listRoutes`	Static routes
`getCableTestResults`	Cable test results
`getSwitchNetworks`	Switch VLAN trunking configuration

Write tools

Tool	Description
`createLanNetwork` / `updateLanNetwork` / `deleteLanNetwork`	Manage LAN networks, including DHCP pools and the DNS servers handed to clients
`createLanProfile` / `updateLanProfile`	Manage switch port LAN profiles (networks, PoE, 802.1X, STP, bandwidth/storm control)
`updateFirewallSetting`	Update firewall settings
`createFirewallAcl` / `deleteFirewallAcl`	Manage firewall ACL rules (internal API)
`updateSwitchPort`	Set profile, override, PoE, status and name on one port in a single call
`updateClient`	Rename a client, reserve a fixed IP, set per-client rate limits
`setSwitchNetworks`	Set switch VLAN trunking

Switch port tools

Tool	Description
`setSwitchPortProfile` / `setSwitchPortPoe` / `setSwitchPortName` / `setSwitchPortStatus` / `setSwitchPortProfileOverride`	Single-port configuration
`batchSetSwitchPortProfile` / `batchSetSwitchPortPoe` / `batchSetSwitchPortStatus` / `batchSetSwitchPortName`	Multi-port configuration
`startCableTest`	Start a cable test on a switch

Action tools

Tool	Description
`rebootDevice`	Reboot a device
`adoptDevice`	Adopt a device
`blockClient` / `unblockClient`	Block or unblock a client
`reconnectClient`	Reconnect a client
`setDeviceLed`	Set device LED behaviour
`startFirmwareUpgrade`	Start a firmware upgrade
`setGatewayWanConnect`	Connect or disconnect a gateway WAN port (internal API)

Generic

Tool	Description
`genericApiCall`	Invoke any Omada Open API endpoint directly

Documentation

Document	Contents
CHANGELOG.md	Release history, with the controller firmware each release was verified against
CONTRIBUTING.md	Dev setup, adding tools, reporting a new firmware version
docs/endpoint-discovery.md	How to enumerate a controller's API surface, and how to read its error codes
docs/endpoints/	Committed endpoint dumps, one per firmware version

Updating from upstream

This fork keeps upstream pointed at realtydev/omada-mcp. After cloning:

git remote add upstream https://github.com/realtydev/omada-mcp.git   # if not already set
git fetch upstream
git log --oneline HEAD..upstream/main        # what is new upstream

Merge and validate:

git checkout -b merge-upstream
git merge upstream/main
npm install && npm run check && npm test

Things to watch when merging:

src/tools/index.ts conflicts on nearly every upstream change, since both sides add imports and register* calls. Keep both sets.
tests/tools/index.test.ts asserts an exact tool manifest. Any tool added on either side must be added to expectedTools, or the suite fails.
New upstream tools may not work on your firmware. Check them against your endpoint dump and update the compatibility matrix rather than assuming they work.
Re-run the endpoint dump after a controller firmware upgrade, not just after a code merge — TP-Link moves these paths between releases. Commit the new dump and add a firmware row to the changelog.

To update the server itself after pulling:

npm install && npm run build

then restart your MCP client so it reloads the tool list.

Development

npm install
npm run dev      # live reload via tsx
npm run build    # compile TypeScript
npm run check    # lint + type check
npm test         # vitest
npm start        # run compiled server (stdio)

Security notes

OMADA_WEB_PASSWORD is a full controller administrator credential — the internal API is the web UI's own API and inherits that account's privileges. Anything holding this value can reconfigure your network. Keep it out of version control, and give it its own password rather than reusing one shared with Wi-Fi or other services.

Known issues inherited from upstream

src/tools/getDevicesStats.ts is dead code: it duplicates listDevicesStats.ts, exports an identically named function, and is never imported.
Several tools listed in upstream's README do not work on common hardware. See Controller compatibility.

License

MIT

Available Tools

72 tools

adoptDeviceA

Destructive

Adopt a pending device by its MAC address into the site.

Inputs: deviceMac (required), siteId.

batchSetSwitchPortNameB

Destructive

Batch set names on multiple switch ports. Each entry specifies a port number and name (1-128 chars).

Inputs: switchMac (required), portNameList (required), siteId.

batchSetSwitchPortPoeA

Destructive

Batch enable or disable PoE on multiple switch ports. 1=on (802.3at/af), 0=off.

Inputs: poeMode (required), portList (required), switchMac (required), siteId.

batchSetSwitchPortProfileB

Destructive

Batch enable or disable profile override on multiple switch ports.

Inputs: portList (required), switchMac (required), profileOverrideEnable (required), siteId.

batchSetSwitchPortStatusA

Destructive

Batch enable or disable multiple switch ports. 0=off, 1=on.

Inputs: status (required), portList (required), switchMac (required), siteId.

blockClientB

Destructive

Block a client device by its MAC address, preventing it from accessing the network.

Inputs: clientMac (required), siteId.

createFirewallAclA

Destructive

Create a firewall ACL rule for inter-VLAN isolation or traffic control. Use listFirewallAcls first to see the expected rule shape.

Inputs: rule (required), siteId.

createLanNetworkB

Destructive

Create a new LAN network with VLAN, gateway/subnet, and DHCP settings.

Inputs: name (required), vlan (required), purpose (required), dhcpSettings (required), +3 more.

createLanProfileB

Destructive

Create a new LAN profile with native/tagged network assignments and port settings.

Inputs: poe (required), name (required), lldpMedEnable (required), tagNetworkIds (required), +5 more.

createPoeScheduleA

Create a PoE schedule. Prefer a reboot schedule where the target is an Omada-managed device — cutting PoE is a hard power cut, and it will also drop anything else sharing the port, including a PoE-powered controller. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: data (required), siteId.

createRebootScheduleA

Create a reboot schedule targeting specific devices. Useful for capping the memory creep that makes access points degrade over long uptimes. Times are interpreted in the site timezone, so verify that first with getSiteSettings. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: hour (required), name (required), deviceMacs (required), timingType (required), +6 more.

deleteFirewallAclA

Destructive

Delete a firewall ACL rule by its ID.

Inputs: aclId (required), siteId.

deleteLanNetworkB

Destructive

Delete a LAN network by its network ID.

Inputs: networkId (required), siteId.

deletePoeScheduleA

Delete a PoE schedule by id. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: scheduleId (required), siteId.

deleteRebootScheduleB

Delete a reboot schedule by id. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: scheduleId (required), siteId.

genericApiCallA

Destructive

Execute an arbitrary Omada API call. Use this for any endpoint not covered by other tools. Path is relative (e.g. "/sites/{siteId}/setting/firewall/acls"). The omadacId prefix is added automatically.

Inputs: path (required), method (required), body, version, +1 more.

getCableTestResultsA

Get cable test results for a switch. Run startCableTest first.

Inputs: switchMac (required), siteId.

getClientC

Fetch details for a specific Omada client.

Inputs: clientId (required), siteId.

getDeviceB

Fetch detailed information for a specific Omada device.

Inputs: deviceId (required), siteId.

getFirewallSettingA

Get firewall configuration and rules for a site, including ACL rules, IP groups, and security policies.

Inputs: siteId.

getFirmwareDetailsB

Get firmware information for a device including current version and available updates.

Inputs: deviceMac (required), siteId.

getInternetInfoB

Get internet configuration information for a site, including WAN settings and connectivity details.

Inputs: siteId.

getLanNetworkListA

Get the list of LAN networks configured in a site, including VLAN settings, IP ranges, and DHCP configuration.

Inputs: siteId.

getLanProfileListB

Get the list of LAN profiles configured in a site. LAN profiles define network settings that can be applied to switch ports.

Inputs: siteId.

getPortForwardingStatusA

Get port forwarding status and rules for a site. Retrieves either User-configured or UPnP-discovered port forwarding rules. Both page and pageSize parameters are required by the API. Call this tool twice (once with type="User" and once with type="UPnP") to get complete port forwarding information.

Inputs: type (required), siteId (required), page, pageSize.

getSiteSettingsA

Get full site settings: timezone and DST, NTP servers, mesh, band steering, airtime fairness, roaming, LED, auto-upgrade, alerts and remote logging. Check the timezone here before trusting any schedule time. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: siteId.

getSsidDetailA

Get detailed information for a specific SSID (wireless network), including security settings, rate limits, scheduling, and advanced configurations. Requires wlanId (from getWlanGroupList) and ssidId (from getSsidList).

Inputs: ssidId (required), wlanId (required), siteId.

getSsidListA

Get the list of SSIDs (wireless networks) configured in a WLAN group. Requires wlanId which can be obtained from getWlanGroupList. Use the ssidId from this list to call getSsidDetail.

Inputs: wlanId (required), siteId.

getSwitchA

Get full switch info including portList array by MAC address.

Inputs: switchMac (required), siteId.

getSwitchNetworksB

Get switch networks / VLAN trunking configuration for a switch.

Inputs: switchMac (required), siteId.

getSwitchPortsA

Get all ports for a switch by its MAC address, including status, profile, PoE, link speed, and STP state.

Inputs: switchMac (required), siteId.

getSwitchStackDetailC

Fetch detailed information for a specific switch stack.

Inputs: stackId (required), siteId.

getThreatListA

Get the global view threat management list. Returns paginated threat information including severity, source/destination IPs, countries, classification, and more.

Inputs: endTime (required), archived (required), startTime (required), page, +5 more.

getWlanGroupListA

Get the list of WLAN groups configured in a site. WLAN groups contain SSIDs and define wireless network settings. Use the wlanId from this list to call getSsidList.

Inputs: siteId.

listClientsC

List network clients connected to a site.

Inputs: siteId.

listClientsActivityA

Get client activity statistics over time from the dashboard. Returns time-series data showing new, active, and disconnected clients (both wireless/EAP and wired/switch) for each time snapshot. Useful for monitoring client connection trends and activity patterns.

Inputs: end, start, siteId.

listClientsPastConnectionsA

Get client past connection list with historical connection data. Returns information about clients that have previously connected to the network, including connection timestamps, traffic data, duration, and device details. Supports pagination, filtering by time range and guest status, sorting by last seen time, and fuzzy search by name/MAC/SSID.

Inputs: page, guest, siteId, timeEnd, +4 more.

listDevicesC

List provisioned network devices for a specific site.

Inputs: siteId.

listDevicesStatsA

Query statistics for global adopted devices with pagination and filtering. Supports fuzzy search by MAC address, name, model, or serial number, and filtering by tag or device series type (0: basic, 1: pro).

Inputs: page, pageSize, filterTag, searchSns, +4 more.

listEventsB

List paginated events for a site (alerts, warnings, system events).

Inputs: page, siteId, pageSize.

listFirewallAclsA

List firewall ACL rules for a site (access control lists for inter-VLAN traffic, etc.).

Inputs: siteId.

listIpGroupsA

List IP/port groups configured in a site. Groups can be used in firewall ACL rules. Requires the internal web UI API (OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD).

Inputs: siteId.

listLogsB

List paginated logs for a site (system logs, configuration changes).

Inputs: page, siteId, pageSize.

listMostActiveClientsA

Get the most active clients in a site, sorted by total traffic. Returns client name, MAC address, type, model, wireless status, and total traffic. This is a dashboard endpoint that provides a quick overview of top clients by traffic usage.

Inputs: siteId.

listPoeSchedulesB

List PoE schedules for a site. PoE schedules cut and restore power to switch ports on a time range, which power-cycles whatever is attached. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: siteId.

listRebootSchedulesA

List reboot schedules for a site, including which devices each one targets and the next execution time. nextExecute is a millisecond epoch in UTC — compare it against the site timezone, since a site left on UTC will run schedules an hour early during summer time. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: siteId.

listRoutesB

List static routes configured for a site.

Inputs: siteId.

listSitesA

List all sites configured on the Omada controller.

Inputs: no named parameters.

listTimeRangesA

List time range profiles for a site. These are the reusable schedule primitive that PoE schedules, WLAN schedules and ACL rules bind to. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: siteId.

rebootDeviceB

Destructive

Reboot a network device by its MAC address.

Inputs: deviceMac (required), siteId.

reconnectClientB

Destructive

Force a client to reconnect to the network by its MAC address.

Inputs: clientMac (required), siteId.

searchDevicesA

Search for devices globally across all sites the user has access to. Returns devices matching the search key.

Inputs: searchKey (required).

setDeviceLedA

Destructive

Set the LED on/off/site-default for a device by its MAC address.

Inputs: deviceMac (required), ledSetting (required), siteId.

setGatewayWanConnectB

Destructive

Connect or disconnect a gateway WAN port.

Inputs: action (required), portId (required), gatewayMac (required), siteId.

setSiteTimeZoneA

Set the site timezone, handling the region and scenario fields the controller requires alongside it. IMPORTANT: on firmware tested, the timezone alone does NOT make schedules observe daylight saving. Omada keeps DST as a separate site setting (site.dst.enable, with manual recurring start/end rules) which is off by default, so a controller runs on standard offset year-round and a "06:00" schedule fires at 07:00 wall-clock during summer time. Check site.dst via getSiteSettings, and treat a schedule's notInDst flag as confirmation. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: timeZone (required), siteId.

setSwitchNetworksC

Destructive

Set switch networks / VLAN trunking configuration for a switch.

Inputs: data (required), switchMac (required), siteId.

setSwitchPortNameB

Destructive

Set the name of a single switch port (1-128 characters).

Inputs: name (required), port (required), switchMac (required), siteId.

setSwitchPortPoeA

Destructive

Enable or disable PoE on a single switch port. 1=on (802.3at/af), 0=off.

Inputs: port (required), poeMode (required), switchMac (required), siteId.

setSwitchPortProfileC

Destructive

Assign a LAN profile to a single switch port.

Inputs: port (required), profileId (required), switchMac (required), siteId.

setSwitchPortProfileOverrideB

Destructive

Enable or disable profile override on a single switch port.

Inputs: port (required), switchMac (required), profileOverrideEnable (required), siteId.

setSwitchPortStatusA

Destructive

Enable or disable a single switch port. 0=off, 1=on.

Inputs: port (required), status (required), switchMac (required), siteId.

startCableTestA

Start a cable test on a switch. Use getCableTestResults to retrieve results after completion.

Inputs: switchMac (required), siteId.

startFirmwareUpgradeB

Destructive

Start a firmware upgrade for a device. Use getFirmwareDetails first to check for available updates.

Inputs: deviceMac (required), siteId.

unblockClientA

Destructive

Unblock a previously blocked client device by its MAC address, restoring network access.

Inputs: clientMac (required), siteId.

updateClientC

Destructive

Update client settings such as display name, static IP, and rate limits.

Inputs: clientMac (required), name, siteId, fixedIp, +3 more.

updateFirewallSettingA

Destructive

Update firewall settings for a site. Pass the same shape returned by getFirewallSetting (broadcastPing, sendRedirects, synCookies, etc.).

Inputs: settings (required), siteId.

updateLanNetworkA

Destructive

Update an existing LAN network configuration including VLAN, gateway/subnet, and DHCP settings.

Inputs: name (required), vlan (required), purpose (required), networkId (required), +4 more.

updateLanProfileB

Destructive

Update an existing LAN profile configuration including network assignments and port settings.

Inputs: poe (required), name (required), profileId (required), lldpMedEnable (required), +6 more.

updatePoeScheduleA

Update an existing PoE schedule (replace, not merge). Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: data (required), scheduleId (required), siteId.

updateRebootScheduleA

Update an existing reboot schedule. This is a replace (PUT), not a merge: read the schedule with listRebootSchedules, change the fields you want, and send the whole object back. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: data (required), scheduleId (required), siteId.

updateSiteSettingsA

Patch site settings. Only the sections supplied are changed. Read the current values with getSiteSettings first. Requires OMADA_WEB_USERNAME/OMADA_WEB_PASSWORD.

Inputs: data (required), siteId.

updateSwitchPortC

Destructive

Update a switch port configuration (profile, PoE, speed, STP, isolation, etc.).

Inputs: portId (required), switchMac (required), poe, duplex, +8 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.9/5.0

Scored 2026-08-31 17:40 across 72 tools

Disambiguation3/5

Most tools target distinct resources and actions, but several boundaries are fuzzy: getSwitch vs getSwitchPorts, getFirewallSetting vs listFirewallAcls, and the confusing setSwitchPortProfile vs batchSetSwitchPortProfile (which actually toggles profile override). The descriptions help, but with 72 tools an agent can easily select the wrong one.

Naming Consistency3/5

The set predominantly uses camelCase verb_noun names, but mixes list and get prefixes inconsistently for collection endpoints (listSites vs getWlanGroupList, getSsidList vs listFirewallAcls). It also mixes update vs set for similar configuration actions, and genericApiCall is an outlier, though the overall pattern is still readable.

Tool Count1/5

With 72 tools, this server far exceeds the reasonable scope for an MCP toolset and would overwhelm an agent's context and tool-selection process. Even for a broad network management domain, this many tools should be consolidated or split into focused servers.

Completeness3/5

Core workflows are covered: LAN networks, firewall ACLs, client management, device lifecycle, switch ports, and reboot/PoE schedules all have CRUD or equivalent operations. However, WLAN/SSID creation and modification are absent, IP groups and static routes are read-only, and port-forwarding rules are status-only; genericApiCall partially fills these gaps but the dedicated surface is incomplete.

Resources

Related MCP Connectors

Tempr MCP Connector
io.temprhq
One OAuth connector for your team's remote MCP servers, with Tool Packs, guardrails and logs.
Security Observability Developer Tools
1
https://api.temprhq.io/mcp/connector
CloudPepper
io.cloudpepper
Manage CloudPepper servers, Odoo instances, backups, and deployments over MCP.
Cloud Platforms CI/CD & DevOps ERP Systems
2
https://mcp.cloudpepper.io
MCPBundles HubA
com.mcpbundles
Access all your MCPBundles tools in one place. Unified hub for all enabled bundles.
Developer Tools Agent Orchestration
2
https://mcp.mcpbundles.com/hub/
X402-Broker Universal MCP Gateway & Multi-Agent Swarm RouterB
com.x402broker
Single-connection MCP gateway discovering and executing 490+ verified MCP & A2A tools.
Agent Orchestration Autonomous Agents Developer Tools
151
https://x402broker.com/api/mcp

Related MCP Servers

Firewalla MCP Server
Security Monitoring
drewrad8
A
license
Not graded
quality
Not graded
maintenance
Enables interaction with Firewalla network security devices for network monitoring, device management, traffic analysis, and security rule configuration through MCP tools.
Updated a year ago (2025-12-28 01:37 UTC)
-
tplink-omada-mcp
Networking & Infrastructure Monitoring
MiguelTVMS
A
license
C
quality
D
maintenance
Exposes TP-Link Omada controller APIs to AI copilots, enabling listing of sites, devices, and clients, and executing arbitrary Omada API calls via natural language.
Updated 7 months ago (2026-04-01 15:19 UTC)
84
29
MIT
tplink-omada-mcp
Networking & Infrastructure Observability
aljopro
A
license
C
quality
B
maintenance
MCP server that lets AI assistants monitor and manage TP-Link Omada controllers. It provides analytics and read-only queries plus write operations such as rebooting devices, blocking clients, and changing network or firewall settings.
Updated 2 days ago (2026-11-13 13:40 UTC)
84
MIT
omada-controller-mcp
Networking & Infrastructure Monitoring
samhaque
A
license
A
quality
B
maintenance
Enables MCP-aware agents to query and manage a TP-Link Omada SDN controller by searching, inspecting, and calling operations from its live OpenAPI catalog.
Updated 2 months ago (2026-09-27 19:39 UTC)
7
1
MIT

Omada MCP Server

Lineage and attribution

What this fork adds

Quick start

Getting your credentials

Environment variables

Controller compatibility

Discovering endpoints for your firmware

Tools

Scheduling and site settings (new in this fork — internal API)

Read tools

Write tools

Switch port tools

Action tools

Generic

Documentation

Updating from upstream

Development

Security notes

Known issues inherited from upstream

License

Available Tools

Tool Schema Changelog

TDQS

Resources

Related MCP Connectors

Related MCP Servers

Firewalla MCP Server

tplink-omada-mcp

tplink-omada-mcp

omada-controller-mcp