Can HA's core MCP integration & ha-mcp co-exist?

[Thomptronics]

I am using Kiosk Satellite's Realtime assistant with the Gemini LLM, which in turn uses HA's core MCP integration to control HA devices. Works great and I have no interest in using my voice and Gemini to build and maintain automations, scripts, or dashboards. It is simply for getting sensor info and turning off and off devices.

For helping build automations, scripts, or dashboards, I would like to use Claude Code and ha-mcp. So, I'm wondering...

To keep the permissions separate and clean between my Gemini-powered voice assistant and my Claude-powered "scripting helper" I was thinking of installing ha-mcp on the same HA instance that hosts HA's core MCP. I would then point Gemini at the core MCP and Claude at ha-mcp (assuming that's possible).

QUESTIONS:

• Is this feasible (can the two MCPs co-exist or would they clash)?
• Does this even sound like a good idea? Or, are there better ways to keep the two separate and, for example, prevent Gemini from deciding to create an automation for me.

[stanleys12]

Yes, they can co-exist. They are two separate MCP servers with separate endpoints, so pointing Gemini at HA's core MCP integration and Claude Code at ha-mcp is a normal setup. I did not find anything in the ha-mcp custom component that registers HA's core MCP path (/api/mcp), so I don't see a clash there. I haven't run both side by side myself.

On whether it's a good idea: the core MCP integration is built on Assist, so Gemini can only read and control entities you have exposed to Assist. It has no way to create or edit automations, scripts or dashboards. The README's comparison table says this directly:

ha-mcp/README.md

Lines 273 to 289 in 1aaf2ad

	## 🆚 ha-mcp vs. Home Assistant's built-in MCP Server
	Home Assistant ships its own [MCP Server integration](https://www.home-assistant.io/integrations/mcp_server/). It is built on the **Assist** pipeline, so a connected MCP client can read and control the entities you have exposed to Assist and run the intents Assist understands — handy for voice-style control of already-exposed devices.
	ha-mcp is a standalone server built for **configuring, building, and debugging** your smart home, not just controlling it. On top of device control, it adds capabilities the built-in integration does not have:
	| Capability | Built-in MCP Server | ha-mcp |
	|------------|:-------------------:|:------:|
	| Control exposed devices, query states | Yes | Yes |
	| Entity scope | Only entities exposed to Assist | Everything in Home Assistant |
	| Create / edit automations, scripts, scenes | No | Yes |
	| Build & edit dashboards | No | Yes |
	| Debug automations from traces, read history & logs | No | Yes |
	| Manage helpers, areas, zones, labels, groups | No | Yes |
	| Backups, apps, HACS, device & entity registry | No | Yes |
	**Rule of thumb:** Use the built-in integration for voice-style control of devices you have already exposed; use ha-mcp when you want an AI assistant that can also build and maintain your Home Assistant setup.

So Gemini on the core MCP can't create an automation, as long as you keep it pointed there and don't also hand it the ha-mcp URL. To keep the voice assistant tame, limit what you expose to Assist. That is the only permission lever on that side.

ha-mcp is the "everything in Home Assistant" side, so keep its URL or secret away from the Gemini setup. If you also want Claude to be less able to break things while it helps with scripts, ha-mcp has a Read Only Mode, and you can append /readonly to the HTTP endpoint for a connection that hides write tools. You could use that for any agent you want to be look-only:

ha-mcp/README.md

Lines 389 to 404 in 1aaf2ad

	### Read-only HTTP connections
	Append `/readonly` to the server's HTTP MCP endpoint to restrict that connection
	to the existing Read Only Mode while other clients keep normal access:
	```text
	Normal: https://example.com/private_your_secret
	Read-only: https://example.com/private_your_secret/readonly
	```
	OAuth and OIDC connections use the same login/provider: for example,
	`https://example.com/mcp/readonly`. No additional secret or server is required.
	Read-only connections hide write tools and block write calls, including calls
	through cached tools or search proxies. The global Read Only Mode setting still
	restricts both endpoints when enabled. Reconnect the client after changing its URL
	so it refreshes its tool list.

Note that /readonly is a connection mode, not a permission on the credential. Anyone holding the same URL or credentials can use the normal endpoint, so don't treat it as a security boundary against a client you don't trust.

(I looked this up in the code with help from an AI assistant; the links are to the lines I checked.)

[Thomptronics]

Thanks for the quick reply and thorough answer -- exactly what I wanted to know.

[Sultan57git]

In principle they shouldn't conflict: both are just clients of the same Home Assistant instance. The separation you want comes mostly from who each one authenticates as. If ha-mcp connects with a long-lived access token, create a dedicated Home Assistant user for it and issue the token from that user, separate from whatever the voice setup uses. Then you can revoke one without touching the other, and the logbook shows which side made a change. Also keep Claude Code's approval prompts on for write actions. Editing automations and dashboards is exactly where you want a confirmation step.

[Thomptronics]

Got it. And, good points -- I might not have thought of making separate long-lived access tokens.