Extend Home Assistant MCP server to support building, not just controlling

[nielsrowinbik]

Problem statement

The Home Assistant MCP server today exposes only the Assist pipeline to connected AI clients, limiting them to the same surface area as the voice assistant: controlling devices and querying state. Nothing more.

#106 introduces a tool layer for automation authoring and wires it to the in-app assistant introduced in #44. But that capability remains locked inside HA's own UI. Users working in external AI clients such as Claude Desktop, Cursor, or similar tools still cannot use those tools to build or manage their home's automations. They face the same broken workflow as before: manually copying YAML, context-switching between their AI tool and the HA UI, and bridging the gap themselves.

This project exposes the automation authoring tool layer from #106 to external AI clients via the MCP server, replacing the need for the community-built ha-mcp integration with a first-party, properly scoped implementation.

Community signals

• The community-built ha-mcp integration has (at the moment of writing) 2.4k stars on GitHub and is getting feature repeatedly in Reddit posts like this and even in tech news outlets like The Verge (link).
• TODO: Expand with additional signals.

Scope & Boundaries

In scope

• Exposing the automation authoring tool layer introduced in Let home maintainers build automations together with AI #106 via the MCP server: list, read, create, update, enable/disable, and delete automations
• Adding a new MCP permission scope for authoring access, distinct from the existing control scope, with explicit opt-in required
• Adding documentation for external AI client setup and the authoring tools

Not in scope

• Building new automation capabilities. Those should be present before starting this project.
• Adding dashboard, script, or scene authoring tools (or any other tools not yet in the tool layer)
• Offering a CLI interface to save on tokens (separate future consideration)
• Any in-app assistant changes

Foreseen solution

The automation tool layer introduced in #106 is already defined, validated, and in use by the in-app assistant. This project wires those same tools to the MCP server under a new, explicitly granted authoring permission scope. External AI clients that are granted the authoring scope get access to the same tool set the in-app assistant uses. The implementation is shared, not duplicated.

The authoring scope is opt-in and separate from the existing control scope, giving users explicit control over how much access external clients have.

Risks & open questions

• Permission UX: How does a user grant the authoring scope to an external client? Needs to be clear and deliberate given the level of access involved.
• Stateless clients: External AI clients don't have the same context-passing infrastructure as the in-app assistant. How much does that affect the quality of automation authoring results, and is any mitigation needed (e.g. richer tool responses)?

Appetite

Small — the tool layer and permission model should already be defined prior to starting this project. Here, we just deliver protocol exposure and permission scoping, with no new infrastructure required.

Execution issues

No response

Decision log

Date	Decision	Outcome