Home Assistant's Built-In MCP Server or ha-mcp? Start Small

Home Assistant 2026.10 turned the built-in MCP server into a one-click switch under Settings > System > AI, which I covered in my 2026.10 rundown. The question that leaves: is the built-in server enough, or do you need the community server everyone links to, ha-mcp? They do very different jobs, and ha-mcp's v8.7.0, released October 14, is a good excuse to lay out the difference.

Short version: the built-in server lets an AI assistant use your house. ha-mcp lets it rebuild your house. Pick the smallest one that does the job.

What the built-in server can and can't do

Home Assistant's MCP Server integration works through Home Assistant's LLM APIs, Assist among them. A connected client like Claude, ChatGPT, Claude Code or Codex can read state and control devices, and the docs say clients "can only control or provide information about entities that are exposed to them." It supports OAuth 2.0 with PKCE, so in most clients you sign in rather than paste a token.

What it won't do is edit your configuration. Marc-Antoine Lambert's guide to Home Assistant and MCP puts it plainly: it "is not a general editor: do not assume it can write automations.yaml, modify a dashboard, or administer every integration."

Two defaults to know. A new setup exposes all LLM APIs, and only administrator accounts can connect. Both are switches on the integration's Configure screen under Settings > Devices & services > Model Context Protocol Server. And if your assistant runs in the cloud, which per the docs includes Claude's connectors even in Claude Desktop, your instance has to be reachable from the internet.

What ha-mcp adds

ha-mcp calls itself "The Unofficial and Awesome Home Assistant MCP Server," and it's the opposite design. The README lists 87 tools, and its comparison table is blunt. Built-in server entity scope: "Only entities exposed to Assist." ha-mcp: "Everything in Home Assistant." It creates and edits automations, scripts and scenes, builds dashboards, reads traces, history and logs, and manages helpers, backups, apps, HACS and the device and entity registries. Opt-in beta tools, off by default, go further into files and configuration.yaml.

The README's own rule of thumb is the best one-liner I've seen on this: use the built-in integration "for voice-style control of devices you have already exposed," and ha-mcp "when you want an AI assistant that can also build and maintain your Home Assistant setup."

Here's the part I'd underline. The recommended install is a custom component from HACS that runs the server inside Home Assistant, and setup asks for an administrator access token. The README's safer option is a separate account just for ha-mcp, set to Local access only with Administrator on, instead of your own login. Either way, the agent works as an admin. That's the price of a tool that can edit anything.

It does ship guardrails: a Read Only Mode toggle, per-tool enable and disable, tool security policies that ask for your approval, and automatic backups before edits. Remote access starts disabled. If you turn on its search-based tool discovery, calls are split into separate read, write and delete proxies, so your client can auto-approve reads, prompt on writes and confirm deletes.

There's also a /readonly suffix you can add to the endpoint URL for a client that should only look. Read the fine print on that one. The README calls it "a connection mode for automated agents, not a separate permission on the credential: the same credentials still work at the normal endpoint." It keeps a well-behaved agent from writing. It does nothing about someone who has the URL.

What changed in v8.7.0

From the v8.7.0 release notes:

• Support for Home Assistant 2026.10's MCP discovery and tool metadata, plus a fix for the pip_kwargs() signature coming in 2026.11. It's already tracking the next release.
• Backup access controls, and a report when a tool disable is being ignored.
• Clearer Claude Desktop approval guidance across write tools, and changes to how tool security approvals resume.
• Redaction of unmarked PEM private keys.
• Z-Wave parameters readable without configuration entities, and Thread dataset preference and deletion actions.
• The standalone binaries and .mcpb bundle are retired: "use uvx or Docker." The mcp-proxy setup recommendations are gone too.

That last item is the action item. If you installed ha-mcp from one of those binaries or the .mcpb bundle, move to the custom component, Docker or uvx before you're stuck on an old build.

Know what you're signing up for, too. Per the README, dev releases publish on every push to master, and the repo has more than 5,000 stars on GitHub. Popular and busy is good, but behavior changes often. I'd stay on stable releases and read the notes before each update.

How I'd set up either one

Lambert's guide is the clearest least-privilege method I've found, and it applies to both servers. His flow is "observe, propose, review, then save in Home Assistant," because "the final automation runs locally without calling AI on every trigger." The AI helps write the automation. It isn't in the loop when the leak sensor trips.

My version of his checklist:

1. Take a backup and test the restore before connecting anything.
2. Start with the built-in server. Expose only the sensors and switches you actually need to Assist. Leave locks, garage doors, alarms, main water valves and sensitive scripts out at first.
3. Use a separate account where you can. Lambert suggests a non-admin account for the Assist endpoint, /api/mcp/assist, where possible. Going by the docs, the "Require an administrator account" switch has to be off before a non-admin account can connect.
4. Prefer OAuth over long-lived tokens. Lambert's line: long-lived tokens "remain powerful until revoked."
5. Observe before you control. Have it list entity IDs and explain one automation before it touches a lamp. A text reply doesn't prove a tool ran, so check the client log and the entity state.
6. Bring in ha-mcp only for a build job. Give it its own local-only admin account, turn on tool approvals, and use /readonly for anything automated.

One of Lambert's examples is a water-leak alert that deliberately doesn't close a valve on its own. I like that restraint. An agent drafting an automation that closes your main valve is fine. An agent that can close it, untested, is not.

Where this leaves you

The pattern matches openHAB's MCP add-on: the token is effectively a password, and an agent is only as safe as the account behind it. What's different in Home Assistant is that you get two MCP servers with very different blast radii, and you get to choose. For "what's the basement humidity" or "turn off the porch light," the built-in server is the right answer. ha-mcp is for the weekend you want help rebuilding dashboards and automations, and I'd switch it off when the weekend's over.