ESPHome Lets AI Agents Edit and Flash Your Devices Now. Read the Fine Print First

Most of the AI-in-the-smart-home news this fall has been about the hub. Home Assistant's built-in MCP server, the community ha-mcp server, Hubitat's per-client tokens, openHAB's add-on. All of those let an agent turn things on and off, or edit automations.

ESPHome 2026.10 goes one layer down. Its Device Builder now has an optional MCP endpoint that lets an agent write firmware configs and flash them to real devices. That's the first first-party MCP surface I've seen below the hub, and it changes what a mistake can cost.

What it does

From ESPHome's 2026.10 release post: the new /api/mcp endpoint "lets an MCP client, such as Home Assistant's MCP integration, read and edit configs, add components and automations, and validate, compile and install."

The pull request that added it lists who it's for: Home Assistant's mcp integration, Claude Code, or Claude Desktop through a local bridge. "Twenty tools wrap existing WS commands." That covers listing devices, reading and writing configs, adding components, validating, compiling, installing, searching the component and board catalogs, creating a device, managing automations, and listing secret names and setting one.

Two things ESPHome is careful to say. It's optional. And "The Device Builder never calls an AI model itself. The endpoint does nothing until you connect an MCP client." If you don't connect anything, nothing changes.

The guardrails are the good part

The PR was written by bdraco, and the review thread is the most practical thing I've read about agent safety this month. The rule they landed on: "Every MCP write now proves what it read." In practice:

• update_config and delete_automation require an expected value, meaning the agent has to show what it thinks is in the file before it can change it.
• add_component guards itself internally.
• set_secret needs an explicit overwrite to replace an existing secret.

That's the right idea. A lot of agent damage comes from the model acting on a stale or imagined picture of your config. Making it prove what it read turns a silent clobber into a refused write.

They tested it for real, too. bdraco reports running it end to end through Home Assistant: "the model read, wrote with expected, validated, listed and deleted an automation; a delete with a stale listing was refused with the diff, which the model read correctly." And then the honest bit: "Its first write guessed an automation: block and only validation corrected it."

That's the whole lesson of AI and home configs in one line. The model guessed. Validation caught it. Never give an agent a path that skips validation.

The part I'd think hard about

Two caveats from the PR deserve more attention than the feature list.

Secrets. get_config can read your secrets file. Every other tool that takes a configuration refuses it, and set_secret is the only way to change it. Per the merged notes, the docs now warn that reading secrets.yaml puts its values into the model's context, and that a replaced secret can't be recovered from version history. In plain terms: if your agent reads your secrets file, whatever you keep in there, usually Wi-Fi passwords and API keys, is now in a conversation with an AI model. Decide if you're OK with that before you connect anything.

No password from Home Assistant. This is the big one. The PR says: "Home Assistant's client only speaks OAuth on a 401, so from HA the server has to be reachable without a password." So if you want Home Assistant's MCP integration to drive Device Builder, the Device Builder has to accept unauthenticated requests on your network.

Combine that with "compile and install," and you can see the risk. Something on your LAN that can reach that endpoint can push firmware to your devices. The review process caught exactly that early on: an automated reviewer on the PR flagged that the endpoint lacked an Origin/Host check, which on a no-password install could chain config writes and a compile into code execution on the host. That was fixed before merge. It's still a good reminder of how close "convenient" and "exposed" sit here.

How I'd use it, if I did

I'd treat this as a power tool, not a default:

1. Leave it unconnected unless you have a specific job for it, like scaffolding a new sensor config.
2. If you use it, use a client that can authenticate, rather than opening Device Builder up without a password for Home Assistant's sake.
3. Don't let the agent read secrets.yaml. Use !secret references and keep the values out of the conversation.
4. Have it validate and compile, then flash yourself. The install step is where a bad guess becomes a dead device on a ladder.
5. Keep config backups. The expected checks prevent stale writes, not bad ideas.

For the hub-level version of this checklist, see my home MCP server security checklist and the comparison of Home Assistant's native MCP server and ha-mcp. The rest of the ESPHome release, including the breaking changes, is in my 2026.10 notes.

The ESPHome team did this carefully, and the PR thread shows it. Firmware is still firmware. I'd rather an agent help me write the YAML than have it hold the flash button.