{
  "markdown": "![keenetic-mcp, the Keenetic MCP server: secure automation and control for Keenetic routers via the Model Context Protocol. Your AI client talks to the MCP server, which talks to the router. Works natively with Claude and Codex, and with Cursor over MCP. Secure and private, all operations run locally in your network. No installation, nothing installed on your Keenetic. Manage settings, users, Wi-Fi and firewall. You decide what to automate and when.](https://raw.githubusercontent.com/salatmaster/keenetic-mcp/main/docs/banner.png)\n\n# keenetic-mcp\n\n**Control your Keenetic router from Claude, Codex, Cursor, or any MCP agent.**\n\n[![npm](https://img.shields.io/npm/v/keenetic-mcp)](https://www.npmjs.com/package/keenetic-mcp)\n[![license](https://img.shields.io/badge/license-MIT-blue)](LICENSE)\n[![MCP](https://img.shields.io/badge/MCP-server-black)](https://modelcontextprotocol.io)\n[![KeeneticOS](https://img.shields.io/badge/KeeneticOS-5.1%20tested-green)](#supported-routers)\n\nAsk your agent about your network in plain language. No USB stick, no Entware,\nnothing installed on the router.\n\n```\n> who is using the most bandwidth right now?\n\n  Three devices are active. Sorted by traffic:\n\n  work-laptop      wifi:HomeNet   -46 dBm    7.7 GB down\n  living-room-tv   wired:Home                3.2 GB down\n  hallway-camera   wifi:HomeNet   -48 dBm    5.4 MB down\n\n  The laptop is on the 2.4 GHz radio at -46 dBm, which is a strong\n  signal, so the throughput is not a coverage problem.\n\n> block the camera until tomorrow morning\n\n  Blocked hallway-camera (02:00:00:00:00:14).\n\n  Applied to the running configuration and verified, but NOT saved.\n  A reboot discards it. Backup taken before the change:\n  ~/Library/Application Support/keenetic-mcp/backups/…txt\n\n  Say the word and I will make it permanent, or leave it and it\n  reverts on the next restart.\n```\n\n## Why\n\n- **Nothing on the router.** It talks to the router's own HTTP API over your\n  LAN. No USB drive, no Entware, no firmware modification.\n- **Works on any Keenetic.** The tool set adapts to what your specific model and\n  firmware actually support.\n- **Safe by construction.** Changes are never saved unless you ask, a backup is\n  taken before the first one, and every change is read back and verified before\n  it is reported as done.\n- **Read-only if you want it.** One flag and the agent physically cannot change\n  anything.\n\n## Install\n\n### Claude Code\n\n```\n/plugin marketplace add salatmaster/keenetic-mcp\n/plugin install keenetic@keenetic\n```\n\nThen run the setup wizard in your terminal:\n\n```\nnpx -y keenetic-mcp init\n```\n\n### Codex\n\n```\ncodex plugin marketplace add salatmaster/keenetic-mcp\ncodex plugin add keenetic@keenetic\nnpx -y keenetic-mcp init\n```\n\nThis brings the skills along with the server. For the server on its own:\n\n```\ncodex mcp add keenetic -- npx -y keenetic-mcp\n```\n\n### Anything else\n\n```json\n{\n  \"mcpServers\": {\n    \"keenetic\": { \"command\": \"npx\", \"args\": [\"-y\", \"keenetic-mcp\"] }\n  }\n}\n```\n\nThe wizard finds your router from the default gateway, confirms it really is a\nKeenetic, checks the password against it, and stores the password in your\noperating system keychain. Only the address and login go in a settings file.\n\nPrefer environment variables? `KEENETIC_HOST`, `KEENETIC_USER` and\n`KEENETIC_PASSWORD` override everything, which is what you want in a container.\n\n## What it can do\n\n**Read**\n\n| Tool | |\n|---|---|\n| `list_devices` | every device, filtered by active, wired, wireless or blocked, sorted by traffic or signal |\n| `get_device` | one device in full: lease, Wi-Fi rate, policy, schedule, traffic |\n| `list_interfaces` | WAN links, bridges, access points, VPN tunnels |\n| `get_interface` | one interface in full, including WireGuard peers |\n| `get_wifi_status` | radios by band, with client counts |\n| `get_internet_status` | reachability, and which check failed |\n| `list_routes` | routing table, or just the default route |\n| `list_policies` | connection policies for selective routing |\n| `get_system_info` | model, firmware, CPU, memory, installed components |\n| `get_config_state` | unsaved changes, who changed what and when |\n| `list_segments` | every bridge, and whether the web interface lists it as a segment |\n| `backup_config` | download the configuration to a local file |\n\n**Change**\n\n| Tool | |\n|---|---|\n| `update_device` | rename, block or allow, assign a routing policy, schedule or priority |\n| `set_interface_state` | bring an interface up or down |\n| `create_segment` | a guest or IoT network the web interface actually lists, with Wi-Fi, DHCP and optional VPN routing |\n| `delete_segment` | remove a segment and everything created with it |\n| `save_config` | make pending changes survive a reboot |\n\n**Escape hatch**\n\n| Tool | |\n|---|---|\n| `rci_call` | any router API path at all, for whatever the tools above do not cover |\n\n## Skills included\n\nThe plugin ships four skills, so the agent knows how your router behaves rather\nthan guessing. One plugin directory serves both Claude Code and Codex: they read\ndifferent manifests but share the same skills and the same server definition.\n\n- **keenetic-rci** teaches the router's API tree: which paths exist, which ones\n  return 100 KB, and how to recover the exact syntax of a command from the\n  router's own configuration.\n- **keenetic-safe-changes** teaches the change workflow: what the router's\n  fail-safe does and does not protect against, and which interfaces will cut off\n  your own access.\n- **keenetic-segments** covers building an isolated network the router will\n  admit exists. The obvious way produces a guest network that carries traffic\n  perfectly and never appears in the web interface, because a segment is\n  VLAN-backed and the VLAN is the part everyone leaves out.\n- **keenetic-troubleshoot** is an ordered diagnostic playbook for \"the internet\n  is down\", \"Wi-Fi is bad\" and \"one device cannot connect\".\n\n## Safety\n\n- **Nothing is saved unless you ask.** Changes apply to the running\n  configuration and are discarded on reboot until `save_config` is called. The\n  server never calls it on its own.\n- **A backup is taken automatically** before the first change of a session.\n- **Every change is verified.** The router accepts some wrong commands silently\n  and changes nothing, so each write is read back and compared before it is\n  reported as successful.\n- **Read-only mode really is read-only.** With `--read-only`, the write tools\n  are not registered at all rather than registered and refusing, so the agent\n  never sees them.\n- **Your password goes in the system keychain**, not in a config file, and never\n  in a log or a tool response.\n- **LAN only.** No cloud, no telemetry, no outbound connection to anything but\n  your router.\n\nWhere the password is stored on each platform, and how to report something\nprivately, are in [SECURITY.md](SECURITY.md).\n\n## Supported routers\n\nRCI, the API this uses, is a standard part of KeeneticOS rather than a feature\nof expensive models, so this works across the range. Verified against a\n**Keenetic Ultra (KN-1811) on KeeneticOS 5.1.3**.\n\nModels on the current 5.1 branch: Giga (KN-1010), Hero (KN-1011, KN-1012),\nStart and Starter (KN-1111, KN-1112, KN-1121), Air and Explorer (KN-1613,\nKN-1621), Extra and Carrier (KN-1713, KN-1714, KN-1721), Ultra and Titan\n(KN-1810, KN-1811, KN-1812). Older hardware on 4.x and earlier has RCI too; the\ntool set adapts to the components each router actually has.\n\n## How it works\n\nKeenetic routers expose RCI, a JSON mirror of their command-line tree, over\nHTTP. This server authenticates with the router's challenge-response scheme,\nkeeps one session alive across the agent's questions, and shapes the answers so\nthey fit in a model's context: the raw interface listing alone is 32 KB, and the\nNAT table is over 100 KB.\n\nThere is no coherent public documentation for RCI, so\n[docs/rci-api.md](docs/rci-api.md) is the notes taken while building this: the\nauthentication handshake, the paths that exist, the traps, and how to recover a\ncommand's syntax from the router itself.\n\n## Development\n\n```\nnpm install\nnpm test          # no router required\nnpm run typecheck\nnpm run build\n```\n\nA checkout reports its version as `0.0.0-dev`, because there is no version\nwritten down anywhere in the sources. Put `KEENETIC_MCP_VERSION` in a `.env` at\nthe repository root to say otherwise; the same file can hold `KEENETIC_HOST`\nand `KEENETIC_PASSWORD` so you do not have to export them. A real environment\nvariable always wins over that file, and an installed copy never reads one.\n\nTests run against sanitized fixtures captured from a real router. To refresh\nthem, and to run a read-only smoke test against your own:\n\n```\nKEENETIC_HOST=… KEENETIC_PASSWORD=… npm run capture:fixtures\nKEENETIC_TEST_HOST=… KEENETIC_TEST_PASSWORD=… npm run smoke\n```\n\nFixtures are anonymized deterministically and a test scans the whole repository\nfor anything that looks like a real MAC address, private IP or key.\n\nThe setup wizard reads a password from the terminal, which no unit test can\nreach: piped input takes a different code path entirely. That part is checked\nwith a script that drives a real pty, so it needs a terminal and cannot run in\nCI:\n\n```\nKEENETIC_TEST_PASSWORD=… ./scripts/verify-wizard.exp\n```\n\n### Releasing\n\nA release is a tag and nothing else. There is no version commit to write,\nbecause there is no version in the repository to change: `package.json` carries\n`0.0.0-dev`, the plugin manifests carry none at all, and the release workflow\nstamps the tag into `package.json` immediately before publishing without\ncommitting it.\n\n```\ngit tag v0.2.2 && git push origin v0.2.2\n```\n\nThe workflow refuses a tag that does not name a version, and a test refuses a\ntree that has a version written into it, so the two can never disagree. The\nplugins pin `keenetic-mcp@^0`, which tracks the major only and is meant to be\nedited once, at 1.0.\n\n## License\n\nMIT\n",
  "bytes": 9930,
  "sha": "cda19bdd4ecf97560ef9c127f2a3e0483a65d27e5ff067bfffc0efbac854b832",
  "repo_slug": "salatmaster/keenetic-mcp",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_salatmaster_keenetic_mcp_c94699a9/readme"
}