How to Connect Home Assistant to an AI Agent With MCP
Enable Home Assistant's MCP server integration, create a long-lived access token for a dedicated user, and add the server to your MCP client such as Claude Desktop or Claude Code. Expose only the entities you want the agent to see. It handles questions and simple control well, and struggles with ambiguous names and multi-step automations.
What the connection gives you
Home Assistant already has a voice and conversation layer that maps natural language onto entities and services. Its MCP server integration makes that layer available to external MCP clients. Once connected, an agent can ask for state, such as which windows are open or what the living room temperature is, and call services, such as turning off lights in an area or setting a thermostat.
The practical difference from a built-in voice assistant is the agent on the other end. A general-purpose model can combine home state with other tools in the same conversation: check the weather through one server, the heating schedule through Home Assistant, and your calendar through a third, then reason across all three.
Setup, step by step
The exact screens change between releases, so treat this as the sequence rather than a click path.
1. Enable the MCP server integration
Add the Model Context Protocol server integration from Home Assistant's integrations page. It publishes an endpoint that MCP clients can connect to.
2. Create a dedicated user and token
Make a separate Home Assistant user for the agent and generate a long-lived access token for it. A dedicated user keeps the agent's actions identifiable in logs and lets you revoke access without touching your own account.
3. Choose what to expose
Use the exposure settings for voice assistants to pick which entities the agent can see and control. Start with read-only sensors and a few lights. Add more once you see how it behaves.
4. Add the server to your client
Configure your MCP client with the endpoint and token. Some clients connect to remote servers directly; others use a small local proxy that forwards to the endpoint. Restart the client and confirm the tools appear.
What works well
- Status questions. Which doors are unlocked, what used the most energy today, is anything left on downstairs.
- Area-level control. Turn off everything in the office, dim the bedroom lights. This works best when devices are assigned to areas.
- Explaining your setup. Asking what an automation does, or why a sensor reports a strange value, is a strong use because the agent can read state and reason about it.
- Drafting automations. The agent can propose automation YAML from a description, which you then review and paste in. Treat it as a draft.
The limitations
Naming is everything. If three entities are called light, light 2, and hue bulb, the agent will guess. Consistent names, aliases, and area assignments do more for reliability than any prompt.
Context is thin. The agent sees entity states and names. It does not know that the back door sensor is flaky, that the guest room heater should never run overnight, or why an automation exists. That knowledge lives in your head or scattered notes.
Multi-step logic is fragile. Asking for a sequence with conditions often works, but it is not an automation. It depends on a model call each time. Anything that must happen reliably belongs in a Home Assistant automation.
Latency and cost. Every command is a round trip through a model. For routine control, a local voice pipeline or a dashboard button is faster.
Safety: decide what the agent must never do
Language models misinterpret requests occasionally. For lights, that is harmless. For locks, alarm panels, garage doors, and heating in an empty house, it is not.
Keep those entities unexposed, or expose them only through scripts that require a confirmation step. Review the dedicated user's activity in the logbook for the first few weeks. And keep the token out of shared configuration files and repositories.
If you want the agent to know the quirks of your house, write them down once: which sensors are unreliable, what each automation is for, what must never be switched off. Index those notes and connect them alongside Home Assistant, so the agent retrieves the context instead of guessing it.
Frequently asked questions
- Can Claude control Home Assistant?
- Yes, through MCP. Home Assistant can run as an MCP server, and Claude Desktop or Claude Code can connect to it as a client. Claude then sees the entities you have exposed and can query their state or call services on them. What it can reach is governed by Home Assistant's exposure settings and the permissions of the token you issue.
- Is it safe to let an AI agent control my home?
- It is as safe as the boundary you set. Expose only what the agent needs, use a dedicated user with its own token, and keep locks, alarms, and garage doors unexposed or behind confirmation scripts. Treat the agent as a helpful but occasionally wrong operator, and keep anything safety critical in deterministic automations.
- Why does the agent pick the wrong device?
- Usually because of naming. The agent matches your words to entity names, aliases, and areas. Vague or duplicated names force it to guess. Rename entities descriptively, add aliases for how people actually refer to them, and assign every device to an area. Those changes improve built-in voice control at the same time.
- Should the agent write my automations?
- It is a good drafting tool. Describe the behaviour, ask for automation YAML, and review it before saving. Check the triggers, conditions, and entity names against your setup. Once saved, the automation runs deterministically without the model, which is exactly what you want for anything that must happen every time.