
Zigbee2mqtt Mcp
io.github.alexpfauPublished by GitHub account alexpfauv0.7.0Updated Oct 24, 2026
Administer a Zigbee2MQTT estate: health, mesh diagnostics, OTA, pairing, device management.
Overview
Lets an assistant administer a Zigbee2MQTT estate over MQTT: mesh health, link quality, pairing, bindings, reporting and firmware updates.
- What you can do
- Talks directly to the Zigbee2MQTT MQTT bridge API, so it works with or without Home Assistant. Read tools cover broker connection status, bridge info, device lists and details, a whole-estate health report, mesh topology with orphan detection, groups, bridge logs and a coordinator memory check. Write tools are tiered: safe mode adds pairing, device options, rename, configure, interview, binding, reporting, groups and state changes, while full mode adds device removal, OTA flashing, Touchlink and bridge restart.
- When to use it
- Use it when you need the layer below device control: weak links, devices that keep rejoining, stale batteries, interview state, OTA availability, permit_join windows, bindings and reporting intervals. It is not needed if you only want an assistant to switch lights that Home Assistant already exposes.
- Requirements
- Runs locally over stdio via npx; needs Node.js 22 or newer and network access to the MQTT broker Zigbee2MQTT uses. Z2M_MQTT_URL is required and must point at the broker, not the Zigbee2MQTT frontend port. Optional: Z2M_MQTT_USERNAME and Z2M_MQTT_PASSWORD for authenticated brokers, Z2M_BASE_TOPIC matching mqtt.base_topic, TLS material paths, and Z2M_WRITE_MODE.
Installation
In SourceWeft
- Open Zigbee2mqtt Mcp in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
zigbee2mqtt-mcp
[CI] [npm version] [License: MIT] [zigbee2mqtt-mcp MCP server] [Zigbee2MQTT MCP on mcprush]
A Model Context Protocol server for administering a Zigbee2MQTT estate.
Most Zigbee integrations already let an assistant turn a light on. This one is for the layer underneath: mesh health, weak links, devices that keep rejoining, stale batteries, firmware updates, pairing, binding, reporting intervals and device options — the things you normally open the Zigbee2MQTT frontend for.
It talks directly to the Zigbee2MQTT MQTT bridge API, so it works regardless of whether you use Home Assistant, Node-RED, openHAB or nothing at all. Tested against Zigbee2MQTT 2.x; several tools depend on bridge endpoints that only exist there, including bridge/health, device/binds/clear and the OTA scheduling topics.
Why this exists
If you already run Home Assistant, your Zigbee devices are exposed there and an assistant can control them. What Home Assistant does not expose is the bridge itself: link quality, mesh topology, interview state, OTA availability, permit_join, device options, bindings and reporting configuration. This server fills exactly that gap.
Design
- No database. Zigbee2MQTT publishes its bridge topics as retained messages, so a fresh subscription yields a complete picture in a few hundred milliseconds. The server keeps only the latest payload per topic in memory.
- No daemon. Pure stdio. It starts and dies with the MCP session.
- Correlated requests. Every
bridge/request/*carries atransactionid and is matched to itsbridge/response/*, so concurrent calls cannot cross wires. - Tiered writes. Destructive operations are gated behind a write mode and an explicit
confirmargument.
Install
Requires Node.js 22 or newer and network access to the MQTT broker that Zigbee2MQTT uses.
VS Code / GitHub Copilot
Add to your MCP configuration:
Claude Desktop
Point
Z2M_MQTT_URLat your MQTT broker, not at the Zigbee2MQTT frontend port. If Zigbee2MQTT'sconfiguration.yamlsaysmqtt.server: mqtt://192.168.1.10:1883, use that value verbatim.
Behind a corporate npm proxy? If
npm config get registryis nothttps://registry.npmjs.org/, your proxy's upstream feed may not carry this package. Add an explicit override to the args rather than changing your global registry:"args": ["-y", "--registry", "https://registry.npmjs.org/", "zigbee2mqtt-mcp"]
Configuration
Write modes
Tools above the active tier are not registered at all, so a model cannot reach for them.
Irreversible tools (z2m_remove_device, z2m_ota_update, z2m_touchlink, z2m_restart_bridge, z2m_set_bridge_options) additionally require confirm: true on every call. Three safe tools reduce state rather than only adding to it, so they are annotated destructive: z2m_rename_device, z2m_manage_group and z2m_bind. Their reducing actions also require confirm: true — z2m_manage_group (remove, remove_all_members) and z2m_bind (clear). z2m_rename_device is annotated destructive because it breaks anything referencing the old name, but stays unconfirmed since renaming back restores it.
Every tool also advertises MCP tool annotations so a client can decide what may run without prompting:
Annotations describe the tool, not the tier: a safe tool can still be destructive. The tier decides what is registered, the annotation tells the client what to ask about.
Opt in to the destructive tier only when you want it:
Tools
Read
Safe writes
z2m_check_updates, z2m_permit_join, z2m_set_device_options, z2m_rename_device, z2m_configure_device, z2m_interview_device, z2m_set_state, z2m_manage_group, z2m_bind, z2m_configure_reporting
Full writes
z2m_remove_device, z2m_ota_update, z2m_restart_bridge, z2m_set_bridge_options, z2m_touchlink
Data availability caveats
Some fields depend on your Zigbee2MQTT configuration. The server detects what is available and tells you rather than silently returning nothing.
Security notes
- The broker URL may carry credentials (
mqtt://user:pass@host). They are redacted everywhere the URL is echoed back to a model or written to a log, and error text from the MQTT client is scrubbed before it leaves the process. Zigbee2MQTT logs its own broker URL at startup, so lines relayed byz2m_get_logsare scrubbed too. safemode can actuate anything on the mesh viaz2m_set_state, including locks, valves and sirens. Useoffif that matters.z2m_permit_joinopens the network to any nearby Zigbee device for the duration of the window. It is insafebecause it is routine and reversible, but it is a security boundary.
Example prompts
- "Is my Zigbee network healthy?"
- "Which devices have the weakest signal?"
- "Which batteries need replacing?"
- "Any firmware updates available?"
- "Open the network for pairing via the kitchen router for two minutes."
- "This sensor stopped reporting temperature — fix it."
- "Bind the hallway remote to the hallway light so it works if the bridge is down."
Development
Note that an MCP server may receive requests concurrently. When testing ordering,
await each response before sending the next, as roundtrip.mjs does — piping
several requests at once will produce misleading results.
The unit tests cover health classification, capability detection, topic routing,
write-mode gating and configuration parsing. They are broker-free by design, so
anything that needs a live mesh belongs in scripts/ instead.
A passing suite only proves the tests ran, so scripts/mutate.mjs breaks the
source one change at a time and checks the suite notices each one:
A surviving mutant marks behavior nothing actually tests, and exits non-zero. Add a mutant alongside any fix worth keeping fixed.
Releases are tag-driven: npm version <patch|minor|major> then
git push --follow-tags. CI publishes to npm with provenance, rewrites
server.json's version from the tag and publishes to the MCP Registry, then
creates the GitHub release. The version committed in server.json is therefore
not authoritative — the tag is.
Safety
This server can remove devices from your network and flash firmware. Both are irreversible and OTA failures can brick hardware. Those tools live in the full tier, which is not enabled by default — you must opt in with Z2M_WRITE_MODE=full. Broker credentials are read from the environment and never logged.
Status
Early release. Developed and tested against a 50-device EmberZNet estate on Zigbee2MQTT 2.12.x. Other adapters (Texas Instruments, deCONZ/ConBee, zStack), TLS and WebSocket brokers, and large estates are unverified. Bug reports and pull requests are very welcome — please include your adapter type and Zigbee2MQTT version from z2m_bridge_info.
License
MIT
Source: README.md at commit 3957aa6
Tools
0Version history
1- v0.7.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts