Which integrations are available for this server?

Provides tools for managing TP-Link Omada controllers, including client and device management, switch port configuration, gateway and LAN network settings, firewall ACLs, analytics, and a generic API escape hatch.

How do I use tplink-omada-mcp?

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., "@tplink-omada-mcp List all clients currently connected to the 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.

tplink-omada-mcp

by aljopro

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

tplink-omada-mcp

A Model Context Protocol server for TP-Link Omada controllers.

This is MiguelTVMS/tplink-omada-mcp v0.15.0 with one addition: the generic API escape hatch ported from realtydev/omada-mcp.

356 tools. Everything upstream has, plus every write tool from realtydev.

Why this exists

Two useful forks of the same project had diverged, and neither had everything:

	Tools	Analytics	Escape hatch
`MiguelTVMS/tplink-omada-mcp` 0.15.0	327	yes	no
`realtydev/omada-mcp` 0.5.5	63	no	yes, plus 29 typed write tools
this repo	356	yes	yes, all 30

The realtydev fork branched at 0.5.5 and added write tools, but upstream moved on to 0.15.0 and added a large amount of read tooling the fork never got — the dashboard, traffic-distribution, RF-scan and Wi-Fi-summary tools among them. So choosing the fork meant losing analytics; choosing upstream meant losing writes.

Both are MIT and share an identical OmadaClient composition pattern (buildOmadaPath is byte-identical between them), so the port is small: one 31-line GenericOperations class, one tool file, four wiring lines and one entry in the category union.

Both upstreams appear dormant — last commits 2026-03-31 and 2026-02-19 respectively — which is the only reason maintaining a merge here is reasonable rather than a treadmill.

Related MCP server: safe-omada-mcp

Two things that will waste your time

Both cost hours to work out. Neither is a bug.

1. The default config hides most of the tools

The server ships with a deliberately narrow category filter:

OMADA_TOOL_CATEGORIES="dashboard:r,client-insights:r,clients:r,devices-all:r"

That is 4 of 30 categories, read-only — so out of the box you see about 84 tools and nothing that writes. This looks exactly like "the image is read-only", and is easy to misdiagnose as the wrong build being deployed. It is not: it is a config default.

To get everything:

OMADA_TOOL_CATEGORIES="all:r,generic:rw,clients:rw"

Suffixes: :r read, :w write, :rw both, none = :rw.

Enabling categories individually rather than a blanket all:rw is worth doing deliberately — upstream adds write tools over time, and a blanket grant picks them up silently on the next pull.

2. HTTP clients must carry the session header

In HTTP mode, initialize returns an Mcp-Session-Id header. Every subsequent request must send it back. Without it, tools/list returns an empty list and no error — which reads as "the server has no tools" rather than "you forgot a header".

SID=$(curl -sD - -o /dev/null -X POST http://host:3000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"c","version":"1"}}}' \
  | grep -i mcp-session-id | tr -d '\r' | cut -d' ' -f2)

curl -s -X POST http://host:3000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H "Mcp-Session-Id: $SID" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

`genericApiCall`

An escape hatch to any Omada Open API endpoint not covered by a typed tool. It is registered under the generic category with permission: 'write', so it is off unless you enable it.

{
  "method": "GET",
  "path": "/sites/<siteId>/devices",
  "version": "v1",
  "queryParams": { "page": 1, "pageSize": 50 }
}

path is relative — /openapi/<version>/<omadacId> is prepended for you.

Note that paginated endpoints need page and pageSize; the typed tools add those via fetchPaginated, and a raw call without them returns HTTP 400.

Configuration

Same as upstream. Minimum:

OMADA_BASE_URL=https://your-controller:8043
OMADA_CLIENT_ID=<from Settings -> Platform Integration -> Open API>
OMADA_CLIENT_SECRET=<same>
OMADA_OMADAC_ID=<GET /api/info -> result.omadacId, no auth needed>
OMADA_SITE_ID=<optional but recommended; site-scoped tools need it somewhere>
OMADA_STRICT_SSL=false   # controllers use self-signed certs

The credential is an Open API application (Settings → Platform Integration → Open API, Client Mode), not a controller user account. Give it the most restricted role that answers your questions.

Docker

docker build -t tplink-omada-mcp .

docker run -d --name omada-mcp \
  --add-host host.docker.internal:host-gateway \
  --env-file .env \
  -e OMADA_TOOL_CATEGORIES="all:r,generic:rw,clients:rw" \
  -e MCP_SERVER_USE_HTTP=true \
  -e MCP_HTTP_BIND_ADDR=0.0.0.0 \
  -p 8001:3000 \
  tplink-omada-mcp

If the controller runs on the same host with host networking, point OMADA_BASE_URL at https://host.docker.internal:8043 rather than a LAN IP — it follows the host regardless of what address it holds.

What was ported, and what was not

Of realtydev's 30 write tools, 28 ported across unchanged. One was replaced and one removed, because the Open API cannot express them — see Two that could not port as-is below.

Area	Tools
Clients	`updateClient` (rename, static IP, rate limits), `blockClient`, `unblockClient`, `reconnectClient`
Devices	`adoptDevice`, `rebootDevice`, `setSiteLed`, `startFirmwareUpgrade`
Switch ports	`setSwitchPortName` / `Poe` / `Profile` / `Status`, `setSwitchPortProfileOverride`, `updateSwitchPort`, `setSwitchNetworks`, four `batchSet*` variants, `startCableTest`
Network	`createLanNetwork`, `updateLanNetwork`, `deleteLanNetwork`, `createLanProfile`, `updateLanProfile`
Firewall	`createFirewallAcl`, `deleteFirewallAcl`, `updateFirewallSetting`
Escape hatch	`genericApiCall`

Two that could not port as-is

setDeviceLed → setSiteLed. The Open API has no per-device LED endpoint. Only PUT /sites/{siteId}/led exists, and it applies to every device on the site, so the tool is site-scoped and named accordingly. For identifying one device, POST /sites/{siteId}/devices/{mac}/locate makes it flash — a good first contribution if someone wants it.
setGatewayWanConnect removed. There is no Open API endpoint that connects or disconnects a gateway WAN port. The fork's version pointed at a path that does not exist, so it could only ever have returned 404.

Two adaptations were needed:

Upstream's RequestHandler only exposed a generic request(). The ported code calls post / put / delete helpers, so those were added as thin wrappers around it.
realtydev's firewall ACL methods prefer an internal web-UI API (required for ACL management on an OC200) and fall back to the Open API otherwise. That subsystem — internalAuth.ts, internalRequest.ts, and the webUsername / webPassword config — is not ported here, and those branches were removed so the methods use the documented Open API path only. If you manage ACLs on an OC200, use realtydev's fork instead.

The suite passes: 2,305 tests green across 390 files. Porting itself only needed the tool-count assertions moved (327 → 356, and the clients write-tool count 3 → 7); the rest of the growth is test coverage added afterwards for the ported write tools, which arrived with none.

A caution about write tools

OMADA_TOOL_CATEGORIES defaults to read-only, and that is a sensible default. These tools reboot devices, change firewall rules, delete LAN networks and cut PoE to ports. If you expose this server over HTTP, remember that MCP has no authentication of its own — whatever can reach the port can drive your network. Enable write categories deliberately, and prefer an Open API account scoped to the least privilege that does the job.

Credits and licence

MIT, unchanged. Copyright remains with the original author.

MiguelTVMS/tplink-omada-mcp — the entire server
realtydev/omada-mcp — GenericOperations and genericApiCall

All credit for the actual work belongs upstream. This repo is a merge.

Available Tools

84 tools

getAllDeviceBySiteA

Get all devices in a site including offline and disconnected devices. Unlike listDevices which may filter to active-only, this returns the full device inventory. Useful for auditing what hardware is registered to a site.

Inputs: siteId, customHeaders.

getApDetailA

Fetch full configuration and status for a specific access point: model, firmware, CPU/memory, connected clients count, SSIDs, uptime, and mesh status. Use listDevices to get the apMac.

Inputs: apMac (required), siteId, customHeaders.

getApGeneralConfigA

Get general configuration for an access point. Returns device name, LED settings, country/region, management VLAN, bandwidth limits, and other global AP parameters. Use getApDetail for runtime status; this returns stored configuration.

Inputs: apMac (required), siteId, customHeaders.

getApIpv6ConfigB

Get IPv6 configuration for a specific access point.

Inputs: apMac (required), siteId, customHeaders.

getApLldpConfigB

Get LLDP (Link Layer Discovery Protocol) configuration for an access point. Returns enabled state and advertised TLVs. LLDP allows network devices to advertise identity and capabilities to neighbours.

Inputs: apMac (required), siteId, customHeaders.

getApQosConfigA

Get QoS configuration for a specific access point.

Inputs: apMac (required), siteId, customHeaders.

getApRadiosA

Get radio status for a specific access point: 2.4GHz and 5GHz band config, channel, TX power, channel utilization, and associated client count per radio. Use listDevices to get the apMac.

Inputs: apMac (required), siteId, customHeaders.

getApSnmpConfigA

Get SNMP configuration for an access point. Returns SNMP version, community strings, trap settings, and enabled state. Useful for auditing SNMP-based monitoring configurations on wireless infrastructure.

Inputs: apMac (required), siteId, customHeaders.

getApUplinkConfigA

Get the uplink configuration for an access point. Returns uplink mode (wired/wireless mesh), preferred uplink settings, and failover configuration. Useful for understanding mesh topology and wired uplink assignments.

Inputs: apMac (required), siteId, customHeaders.

getApVlanConfigA

Get VLAN configuration for an access point. Returns the AP's management VLAN and per-SSID VLAN tagging settings. Useful for verifying network segmentation on wireless infrastructure.

Inputs: apMac (required), siteId, customHeaders.

getCableTestFullResultsA

Get full cable test results for all ports on a switch. Returns detailed per-port diagnostic data including cable status (OK/open/short), estimated cable length, and fault location. More detailed than getCableTestLogs.

Inputs: switchMac (required), siteId, customHeaders.

getCableTestLogsB

Get cable test logs for a switch. Returns history of cable diagnostics including per-port test results, cable length estimates, and fault detection. Useful for diagnosing physical layer connectivity issues.

Inputs: switchMac (required), siteId, customHeaders.

getClientA

[DEPRECATED] Use listClients instead. When you have a client MAC, getClientDetail is also available. This tool filters the site client list in-process to emulate a per-client lookup. Fetch details for a specific Omada client.

Inputs: clientId (required), siteId, customHeaders.

getClientDetailA

Get full detail for a specific client by MAC address, including connection info, IP, VLAN, signal strength, and traffic stats.

Inputs: clientMac (required), siteId, customHeaders.

getClientsDistributionA

Get client count distribution by connection type and band (wired, 2.4GHz, 5GHz, 6GHz). Useful for understanding the network composition at a glance.

Inputs: siteId, customHeaders.

getDashboardMostActiveEapsA

Get the most active access points (EAPs) in a site, sorted by traffic volume.

Inputs: siteId, customHeaders.

getDashboardMostActiveSwitchesA

Get the most active switches in a site, sorted by traffic volume.

Inputs: siteId, customHeaders.

getDashboardOverviewA

Get the site overview topology: device counts (gateways, switches, APs), client counts (wired, wireless, guest), connectivity graph, and overall health status. Good first call to understand what's in the network.

Inputs: siteId, customHeaders.

getDashboardPoEUsageA

Get PoE (Power over Ethernet) usage statistics for a site, showing power consumption per switch.

Inputs: siteId, customHeaders.

getDashboardSwitchSummaryB

Get switch summary for a site dashboard: total switch count, total ports, active ports, PoE budget used vs available, and aggregate bandwidth.

Inputs: siteId, customHeaders.

getDashboardTopCpuUsageA

Get the top devices by CPU usage for a site, useful for identifying overloaded devices.

Inputs: siteId, customHeaders.

getDashboardTopMemoryUsageA

Get the top devices by memory usage for a site, useful for identifying memory-constrained devices.

Inputs: siteId, customHeaders.

getDashboardTrafficActivitiesB

Get traffic activity time-series data for a site, showing upload and download trends over time.

Inputs: siteId, customHeaders.

getDashboardWifiSummaryB

Get WiFi summary for a site dashboard: total APs, connected AP count, wireless client count, channel utilization per band (2.4GHz/5GHz), and SSID count.

Inputs: siteId, customHeaders.

getDeviceC

[DEPRECATED] Use listDevices instead. Filters the site device list in-process. No dedicated per-device detail endpoint exists in the spec. Fetch detailed information for a specific Omada device.

Inputs: deviceId (required), siteId, customHeaders.

getDeviceTagListB

Get the list of device tags defined in a site.

Inputs: siteId, customHeaders.

getDownlinkWiredDevicesA

Get wired downlink devices connected to an access point's LAN port. Returns a list of devices using the AP as a wired switch, including their MAC addresses and connection details. Useful for APs with built-in switch ports (e.g. EAP615-Wall).

Inputs: apMac (required), siteId, customHeaders.

getFirmwareInfoB

Get the latest available firmware information for a device. Returns current firmware version, latest available version, and whether an upgrade is available. Use listDevices to get deviceMac values.

Inputs: deviceMac (required), siteId, customHeaders.

getFirmwareUpgradePlanC

Get the firmware upgrade plan list for devices managed by the controller.

Inputs: page, pageSize, customHeaders.

getGatewayDetailA

Fetch full configuration and status for a specific gateway: model, firmware, CPU/memory, WAN/LAN ports, routing mode, and feature flags. Use listDevices to get the gatewayMac.

Inputs: gatewayMac (required), siteId, customHeaders.

getGatewayLanStatusB

Get LAN port status for a specific gateway: port link state, speed, duplex, connected device, and VLAN assignment. Use listDevices to get the gatewayMac.

Inputs: gatewayMac (required), siteId, customHeaders.

getGatewayPortsA

Get all WAN and LAN port details for a specific gateway: link status, speed, IP address, bytes in/out, and port profile. More detailed than getGatewayWanStatus or getGatewayLanStatus. Use listDevices to get the gatewayMac.

Inputs: gatewayMac (required), siteId, customHeaders.

getGatewayWanStatusA

Get the WAN port status and connectivity information for a specific gateway. Returns WAN IP, DNS, uptime, link speed, TX/RX rates, and connection type for each WAN port. Use listDevices to find the gatewayMac.

Inputs: gatewayMac (required), siteId, customHeaders.

getGridAutoCheckUpgradeC

Get the auto-check upgrade plan list showing scheduled firmware upgrade checks across devices. Useful for auditing upgrade schedules and identifying devices due for automatic firmware updates.

Inputs: page, pageSize, customHeaders.

getGridClientHistoryB

Get per-client connection history (paginated). Returns past connection sessions for a specific client including timestamps, SSID/network, traffic, and authentication type.

Inputs: clientMac (required), page, siteId, pageSize, +2 more.

getGridKnownClientsB

Get historical known clients list (paginated). Returns clients that have previously connected to the site, with optional time range and search filtering.

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

getIspLoadA

Get per-WAN ISP link load over a time range. Shows traffic volume and utilization per internet uplink. Useful for understanding load balancing behaviour, identifying saturated WAN links, and analysing failover events. start and end are Unix timestamps in seconds.

Inputs: end (required), start (required), siteId, customHeaders.

getMeshStatisticsA

Get mesh link statistics for an access point. Returns wireless backhaul link quality, signal strength, throughput, and hop count for mesh-connected APs. Useful for diagnosing mesh network performance.

Inputs: apMac (required), siteId, customHeaders.

getOswStackLagListA

Get Link Aggregation Group (LAG) list for a switch stack. Returns configured LAG/trunk groups including member ports, load balancing mode, and status. Use getSwitchStackDetail to get the stackId.

Inputs: stackId (required), siteId, customHeaders.

getPastClientNumA

Get historical client count trend over a time range. Returns a time-series of client counts to show how connected devices changed over the specified period. Requires start and end as Unix epoch seconds.

Inputs: end (required), start (required), siteId, customHeaders.

getRadiosConfigA

Get per-radio configuration for an access point. Returns settings for each radio (2.4GHz, 5GHz, 6GHz) including band, channel, transmit power, channel width, and enabled SSIDs. Use getApRadios for runtime radio status; this returns configuration.

Inputs: apMac (required), siteId, customHeaders.

getRFScanResultA

[DEPRECATED] Get the last RF scan results for an access point. This endpoint is marked deprecated in the Omada OpenAPI spec. Returns detected neighbouring networks, per-channel utilization, interference levels, and RSSI data. Use triggerRfScan first to initiate a fresh scan; this returns the most recent stored results.

Inputs: apMac (required), siteId, customHeaders.

getSitesApsAvailableChannelC

Get available channels for an AP.

Inputs: apMac (required), siteId, customHeaders.

getSitesApsBridgeC

Get P2P bridge config for an AP.

Inputs: apMac (required), siteId, customHeaders.

getSitesApsChannelLimitC

Get channel limit config for an AP.

Inputs: apMac (required), siteId, customHeaders.

getSitesApsIpSettingC

Get IP settings for an AP.

Inputs: apMac (required), siteId, customHeaders.

getSitesApsLoadBalanceA

Get load balance config for an AP.

Inputs: apMac (required), siteId, customHeaders.

getSitesApsOfdmaB

Get OFDMA configuration for an AP.

Inputs: apMac (required), siteId, customHeaders.

getSitesApsPowerSavingB

Get power saving config for an AP.

Inputs: apMac (required), siteId, customHeaders.

getSitesApsTrunkSettingC

Get trunk setting for an AP.

Inputs: apMac (required), siteId, customHeaders.

getSitesDeviceWhiteListC

Get the device whitelist for a site.

Inputs: page, siteId, pageSize, customHeaders.

getSitesGatewaysGeneralConfigC

Get gateway general config.

Inputs: gatewayMac (required), siteId, customHeaders.

getSitesGatewaysPinC

Get PIN setting for a gateway (LTE model).

Inputs: gatewayMac (required), siteId, customHeaders.

getSitesGatewaysSimCardUsedC

Get SIM card used by a gateway.

Inputs: gatewayMac (required), siteId, customHeaders.

getSitesHealthGatewaysWansDetailsC

Get WAN port health details for a gateway.

Inputs: gatewayMac (required), siteId, customHeaders.

getSitesSwitchesEsC

Get easy managed switch info.

Inputs: switchMac (required), siteId, customHeaders.

getSitesSwitchesEsGeneralConfigB

Get easy managed switch general config.

Inputs: switchMac (required), siteId, customHeaders.

getSpeedTestResultsA

Get the last speed test results for an access point. Returns upload/download throughput measurements from the most recent speed test. Use triggerSpeedTest first to initiate a new test; this returns stored results.

Inputs: apMac (required), siteId, customHeaders.

getStackNetworkListA

Get the VLAN network list for a switch stack. Returns VLAN interface assignments across all stack members. Use getSwitchStackDetail to get the stackId.

Inputs: stackId (required), page, siteId, pageSize, +1 more.

getStackPortsC

Get all port information for a switch stack.

Inputs: stackId (required), siteId, customHeaders.

getSwitchDetailA

Fetch full configuration and status for a specific switch: model, firmware, CPU/memory, all port states, PoE usage, VLAN config, and STP status. Use listDevices to get the switchMac.

Inputs: switchMac (required), siteId, customHeaders.

getSwitchDot1xSettingA

Get the 802.1X switch port authentication setting. Controls port-based network access control on managed switches.

Inputs: siteId, customHeaders.

getSwitchGeneralConfigB

Get general configuration for a switch including device name, LED settings, LLDP settings, flow control, and other global switch parameters. Use listDevices to get switchMac values.

Inputs: switchMac (required), siteId, customHeaders.

getSwitchStackDetailC

Fetch detailed information for a specific switch stack.

Inputs: stackId (required), siteId, customHeaders.

getTrafficDistributionB

Get traffic distribution by protocol and application type over a time range. Shows breakdown of traffic by category (video, gaming, web, etc.) helping identify what is consuming bandwidth on the network. start and end are Unix timestamps in seconds.

Inputs: end (required), start (required), siteId, customHeaders.

getUpgradeLogsB

Get firmware upgrade logs showing the history of upgrade operations performed on devices.

Inputs: page, pageSize, customHeaders.

getUpgradeOverviewCriticalB

Get the number of critical firmware upgrades available across managed devices.

Inputs: customHeaders.

getUpgradeOverviewTryBetaC

Get the try-beta firmware switch status for the controller.

Inputs: customHeaders.

getUplinkWiredDetailA

Get wired uplink detail for an access point. Returns the AP's Ethernet uplink port information including connected switch, port number, link speed, and PoE status. Useful for mapping physical network topology.

Inputs: apMac (required), siteId, customHeaders.

listClientsA

List all network clients (wired and wireless) connected to a site. Returns client details including MAC address, IP, hostname, connected device, SSID (for wireless), signal strength, download/upload traffic, and online status. Use this to audit connected devices or find a specific client by name or MAC.

Inputs: siteId, customHeaders.

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, customHeaders.

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, +5 more.

listDevicesA

List all provisioned (adopted) network devices in a site: gateways, switches, and access points. Returns MAC address, model, firmware version, IP, uptime, CPU/memory usage, and status for each device. Use MAC addresses from this response as input to getGatewayDetail, getSwitchDetail, getApDetail, etc.

Inputs: siteId, customHeaders.

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, +5 more.

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, customHeaders.

listPendingDevicesA

List devices discovered on the network but not yet adopted into this site. Returns device type, MAC, IP, and model. These are devices waiting to be provisioned.

Inputs: siteId, customHeaders.

listSitesApsPortsC

List ports on an AP.

Inputs: apMac (required), siteId, customHeaders.

listSitesCableTestSwitchesIncrementResultsC

Get cable test incremental results for a switch.

Inputs: switchMac (required), siteId, customHeaders.

listSitesCableTestSwitchesPortsB

List ports available for cable test on a switch.

Inputs: switchMac (required), siteId, customHeaders.

listSitesStacksB

List switch stacks in a site.

Inputs: page, siteId, pageSize, customHeaders.

listSwitchNetworksA

List VLAN network assignments for a switch. Returns which VLANs are assigned to which ports, including tagged and untagged configurations. Use listDevices to get switchMac values.

Inputs: switchMac (required), page, siteId, pageSize, +1 more.

listUpgradeFirmwaresC

List uploaded firmware files available for manual upgrade.

Inputs: page, pageSize, customHeaders.

listUpgradeOverviewFirmwaresC

List firmware pool entries in the upgrade overview.

Inputs: page, pageSize, customHeaders.

searchDevicesC

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

Inputs: searchKey (required), customHeaders.

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.8/5.0

Scored 2026-09-10 15:25 across 84 tools

Disambiguation2/5

Many tools overlap heavily, especially around AP and device configuration: getApRadios vs getRadiosConfig, getApDetail vs getApGeneralConfig, and a long list of getSitesAps... getters. Several deprecated tools like getDevice and getClient add further confusion, while listDevices, listDevicesStats, and getAllDeviceBySite have unclear boundaries.

Naming Consistency3/5

Naming is consistently camelCase and mostly follows get/list + resource, but the pattern is not predictable: the same resource appears as getApDetail vs getSitesAps..., getGatewayDetail vs getSitesGateways..., and getGrid.../getDashboard... prefixes are mixed in. The naming is readable but lacks a uniform convention.

Tool Count1/5

84 tools is an extreme count for an MCP server, far beyond the 3-15 well-scoped range. Many tools are micro-getters for single configuration fields that could be consolidated into richer detail endpoints, making the surface unwieldy for agents.

Completeness2/5

The server provides broad read-only coverage of device, client, dashboard, and firmware data, but it is almost entirely observational. There are no create/update/delete operations, no client control, no SSID/WLAN management, and no upgrade/reboot actions; referenced tools like triggerSpeedTest are also missing.

Maintenance

ActivityStale

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Zapier
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
https://mcp.zapier.com/api/v1/connect
Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
https://api.artificialwit.com/mcp
Server4AgentA
com.server4agent
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
App Automation Cloud Platforms Developer Tools
343
https://mcp.server4agent.com
mcp-openai
io.github.AceDataCloud
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
AI & Machine Learning Image & Video Processing
11
https://openai.mcp.acedata.cloud/mcp

Related MCP Servers

omada-mcp
Networking & Infrastructure Security
dfla-me
A
license
A
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to read and safely modify TP-Link Omada networks through capability-gated tools, with a default read-only profile and dry-run writes for security.
Updated 6 months ago (2026-05-26 00:16 UTC)
11
1
MIT
safe-omada-mcp
Networking & Infrastructure Observability Security
gaspareduard
A
license
C
quality
B
maintenance
Security-focused MCP server for TP-Link Omada Open API workflows, enabling network management via natural language.
Updated 17 days ago (2026-10-24 19:19 UTC)
117
57 npm
28
MIT
UniFi MCP
Networking & Infrastructure Home Automation & IoT
frousselet
A
license
B
quality
D
maintenance
An MCP server that enables AI assistants to manage UniFi network infrastructure, including cloud management, local network devices, and Protect cameras, through natural language.
Updated 3 months ago (2026-08-21 11:35 UTC)
62
1
MIT
mcp-omada
Networking & Infrastructure Monitoring
thalisantunes
A
license
A
quality
C
maintenance
Read-only MCP server for TP-Link Omada SDN controllers, enabling querying controller, site, device, and WiFi state.
Updated 5 days ago (2026-11-06 02:53 UTC)
8
Apache 2.0

tplink-omada-mcp

Why this exists

Two things that will waste your time

1. The default config hides most of the tools

2. HTTP clients must carry the session header

genericApiCall

Configuration

Docker

What was ported, and what was not

Two that could not port as-is

A caution about write tools

Credits and licence

Available Tools

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

omada-mcp

safe-omada-mcp

UniFi MCP

mcp-omada

`genericApiCall`