deco-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DECO_HOST | No | The main Deco's LAN address (default 192.168.68.1, the Deco default) | 192.168.68.1 |
| DECO_EMAIL | Yes | TP-Link account email used to log in to the control port | |
| DECO_PASSWORD | Yes | TP-Link account password used to log in to the control port | |
| DECO_STATE_DIR | No | Optional; lockout state and the web session directory (default ~/.local/state/deco-local) | ~/.local/state/deco-local |
| DECO_MCP_READONLY | No | Set to 1 for a read-only MCP server with no write tools | |
| DECO_WEB_PASSWORD | No | Optional, if the web interface password differs from the TP-Link account password |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_readsA | Every read this router exposes (client list, Wi-Fi config, QoS, port forwarding, DHCP, VPN config, firmware, ...), and which of them the web-interface fallback can also provide. Use get_router_data to read one. |
| get_router_dataB | Read one named value from the Deco (see list_reads). Secrets (Wi-Fi passwords, VPN private keys) are redacted. Returns {source, result} and, when the web interface answered, why. |
| mesh_overviewA | The mesh at a glance: each node (name, model, online, wired or wireless backhaul with signal 0-3, upstream node, IP, firmware, client count) and each online client (name, IP, node, band, signal). Two reads, with the web-interface fallback. |
| lockout_statusA | Whether the router is still applying a write (control port locked), and how the last lockout went. No router contact. |
| get_router_data_unredactedA | Like get_router_data but includes secrets (e.g. Wi-Fi passwords, a WireGuard private key). Only use this when the user specifically needs the secret, and don't write it anywhere without asking. |
| router_snapshotA | Read every known value in one pass (~70 reads, paced 1 s apart, so over a minute). Heavy on the router; use get_router_data for what you actually need. |
| list_writesA | Every write this server can attempt: verified (proven live with a read-back), upstream (seen in real app captures, not re-tested), noop (proven to do nothing) or inferred (opcode-numbering guess), with a note. |
| write_router_settingA | Write a setting (see list_writes). Pass the whole object as read from the matching read, with
your change made (e.g. read led_schedule, flip enable_night_mode, send it to led_set). Refuses
unverified writes unless allow_unverified=True -- ask the user first. Returns the read-back
( |
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 8 tools
The read/write catalogs are cleanly separated from the execute tools, and lockout_status is unique. Overlap remains between get_router_data and get_router_data_unredacted (a flag could have been a parameter) and to a lesser degree between mesh_overview and router_snapshot, so an agent can occasionally hesitate.
All names are descriptive snake_case with no style mixing, and most start with clear verbs (list_, get_, write_). Three names are noun phrases (mesh_overview, router_snapshot, lockout_status), so the verb_noun pattern is not fully uniform.
Eight tools for a router-management server is well within the ideal range. Each has a distinct role: catalog, read, write, overview, lockout status, snapshot, and secrets access.
Reads are comprehensively enumerated via list_reads and router_snapshot, and writes via list_writes plus read-modify-write. The surface lacks explicit action tools for non-setting operations (e.g. reboot or firmware action) if those exist, but core lifecycle coverage is strong.