Key takeaways
- Two different tools share this name. Pick by the job you're doing.
- The official integration exposes your home as context to Claude or ChatGPT.
- The community ha-mcp (~4k stars) lets a model build and edit automations.
- It can change your home, so treat connecting it as a write decision.
You typed homeassistant mcp server into a search box and got a repo, an official docs page, and a directory that lists two dozen options. None of them tells you the thing that matters most: the top two results are not the same tool. Search mcp server home assistant with the words flipped and you get the same jumble. Before you install anything, there is one fork to settle, and one decision underneath it that no tutorial makes for you.
One honest note before we start. What follows is built from public sources, not a first-hand install benchmark. I'll say where the exact steps live so you can act on the current versions, not a snapshot.
Two things share the name "homeassistant mcp server"
Here is the trap. Both of the tools you keep landing on are legitimately called a Home Assistant MCP server, and their names differ by about one word. That is exactly why searchers land confused.
The first is Home Assistant's own built-in integration. It lets Home Assistant provide context to MCP client applications like Claude and ChatGPT. Your home becomes something an AI client can look at.
The second is a community project, homeassistant-ai/ha-mcp. Its users frame it the other way around: a tool for building out your Home Assistant configs, adding automations, scripts, and helpers. It is the server people reach for when they want the model to write, not just read.
Same three words. Opposite orientation. The setups do not overlap. Get this fork right and everything after it is easy.
The built-in option: Home Assistant's official MCP Server integration
The built-in integration turns Home Assistant into a context provider. It exposes your home to MCP LLM client applications such as Claude and ChatGPT, so the client can read the state of your house and reason over it. Under the hood, an MCP server exposes a data source in a format an AI client can read and act on. That is the general mechanism behind any Home Assistant MCP server, and it is worth holding onto, because "act on" is the word that carries the risk later.
Pick this one when your job is reading and acting on home state from a client you already use. You want Claude to answer "is the garage door open?" or "which lights are still on downstairs?" and you want it done through a first-party integration you did not have to trust a stranger to maintain.
Where it can disappoint: it is framed as a context provider, not a config editor. The person who built the community server started from a real complaint, that the Home Assistant MCP servers already out there weren't tuned for daily use with a language model. So if your actual job is heavy automation editing, the built-in path may feel thin. I won't pin a version number for it; no primary release source is in front of me, and MCP tooling moves weekly.
The community option: homeassistant-ai/ha-mcp
ha-mcp is the popular one, and the numbers show it. As of mid-2026 the repo sits at roughly 4,000 stars, 164 forks, and more than 2,000 commits, with new commits landing the same week. Treat those as a moving snapshot, not a fixed figure; the point is that it is alive and actively worked on, not that the count is exact.
What it adds beyond reading state is the whole reason people use it: a model that builds. Its community describes it as the MCP server that helps AI agents build your configs out, adding automations, scripts, and helpers. It uses natural language to control the smart home, so "turn the porch light to 30 percent at sunset" becomes an automation the model writes for you.
The honest cost: it is unofficial and community-maintained, not a first-party Home Assistant integration. No independent hands-on benchmark validates its reliability or its setup friction. You are trusting an active project and its maintainers, which is a fair trade for a lot of people, as long as you make it on purpose.
Before you connect: this is a write decision, not a read
Here is the point every tutorial skips. An MCP server does not just let a client read your home. The mechanism is read and act, the client controls the smart home in natural language, and ha-mcp goes further and creates and edits automations. Put those together and you have a write path into your house, not a query.
Make it concrete. A read is "tell me the thermostat setpoint." A write is "create an automation that unlocks the front door when my phone gets home." The second one changes your house, and it can be wrong, and it can be hard to notice it happened. The community server's own recent work shows the project wrestling with exactly this: its commit history includes changes to how its auto-approve setup behaves. There is an approve step, which means there is something worth approving.
So here is my position, and I'll flag it as judgment, not a quoted rule: before a tool can fire against your home, put a human confirmation step in front of it. Let the model propose the automation. You approve it. This is a reversibility-first read, not a benchmarked policy, but the logic is plain: the cost of a bad confirmation click is tiny, and the cost of a silent write is your front door.
Which one to pick, by the job you're doing
There is no single "best Home Assistant MCP server." There is only the one that matches your job. Here is the fork in one glance.
| Question | Official HA MCP Server integration | Unofficial ha-mcp |
|---|---|---|
| What it's for | Exposes your home as context to a client | Lets a model build and edit configs |
| Read or write | Read and act on home state | Build automations, scripts, helpers |
| Maintained by | Home Assistant, first-party | Community project, unofficial |
| Adoption signal | Built in, no separate metric | ~4k stars, 2,000+ commits, mid-2026 |
| Best when | You want Claude or ChatGPT to see your home | You want the model to write automations |
The rule to keep: if the job is exposing home state to a client, take the built-in integration. If the job is having an LLM build and edit your automations, take ha-mcp.
Where each loses. Skip ha-mcp if you need a first-party supported integration and you are not comfortable with a community project that no one has independently benchmarked. Skip the built-in integration if your real job is building automations, where the earlier field was found underoptimized. This rule is synthesis. Validate it against your own setup before you commit.
Connecting it to your LLM client
The literal question is "how do I connect it," so here is the shape. Both paths speak to MCP clients: ha-mcp works with Claude and ChatGPT, and the official integration provides your home as context to those same MCP clients. The pattern in every case is the same. You run the server, you get a server URL, and you add that URL to your client's MCP configuration, whether that client is Claude Desktop, Claude.ai, or ChatGPT.
I won't hand you an exact URL or a click-by-click path, because the current server URL and setup steps are not pinned from a primary release source here, and a stale command is worse than none. Get the live steps from the official Home Assistant docs for the built-in integration, and from the ha-mcp repository on GitHub for the community server. There is no separate magic setup wizard to hunt for; it is the integration on the Home Assistant side plus the MCP entry on the client side. One caution: I am not asserting Gemini client support. The evidence covers Claude and ChatGPT, so treat Gemini as unconfirmed until the docs say otherwise.
Scope and transport: the decision after you pick
Choosing the implementation is step one. Step two is scope. What are you actually exposing, and over what transport, at what access level? This is where the reversibility mindset earns its keep. Start read-only. Add write access only when you have a reason. And use controls the server already gives you: if it ships an auto-approve setting, the safe default is off, so the model proposes and you confirm. The narrower the surface you hand over, the smaller the blast radius when something misfires.
A reversibility checklist before you flip it on
Keep this short list and run it once, before the first connection:
- Turn off any auto-approve, so the model proposes and you approve.
- Grant read access first. Add write access as a separate, later decision.
- Keep one throwaway automation you can delete, to test the write path safely.
- Know, in advance, how to revoke the client's access in a single step.
If you cannot answer the last one, you are not ready to connect yet.
How to tell it's working, and what to do next
The fastest verification costs nothing. Ask the connected client to read one specific home state, a single light, a single sensor, and confirm it returns the real value you can see in Home Assistant. If the read comes back true, the connection is live and the client can see your home.
Be clear about what that proves. A working read is a sanity check on the connection, not a security audit. It tells you the pipe is open. It does not tell you the write path is scoped the way you want, or that a bad automation would get caught. So verify the read, then, before you ever let it act, decide what "act" is allowed to mean.
What no one has benchmarked yet
The gap in this whole space is honest to name: no independent, hands-on benchmark compares these two implementations on setup friction, reliability, or which one is better for which job. The enthusiasm posts are real, and the adoption is real, but nobody has published the install-and-measure test. This page is synthesis of public sources and a decision framework, not a first-run report. When first-party install notes exist, the right move is to fold them in and upgrade this from a rule into a benchmark. Until then, treat the fork and the write decision as the durable parts, and treat the specific steps as things you confirm at the source.
Your next move is small. Pick the implementation that matches your job, then wire it to your MCP client at read-only scope first. If you want the mechanics of attaching a server to a client at the right scope and transport, read how to add an MCP server to Claude. If you are weighing several servers at once, our notes on GitHub MCP servers walk the same read-versus-write question. And if the write decision is the part that stuck with you, that instinct is the whole argument for a controllable, reversible harness around any agent that gets a write path.