Google Home MCP is a first-party remote MCP server that lets a compatible personal agent read your Google Home structure, query live device state and history, and run supported device actions. It is a physical-world tool surface, not a browser scrape of the Home app.
Google opened Home MCP in Early Access around September 16, 2026. The Home MCP Server docs describe OAuth-backed access for clients such as Google Antigravity, Claude Cowork, and OpenClaw. Public launch coverage also named Hermes and OpenClaw among example agents that can call MCP tools. This post stays with what those official pages document, and what that means for self-hosted OpenClaw or Hermes-class setups.
Short answer
Use Home MCP when you already run Google Home, you have the Early Access entitlement (Google Home Premium Advanced, US English rollout at launch), and you want an authorized agent to work against real rooms, devices, and event history over MCP.
Do not treat Google's hard safety bans as a full approval design. Platform limits such as prohibiting unlocking doors are a floor. Your Gateway or agent process still decides who can invoke the tools, which mutating calls need a human, and how a shared household is isolated. Start from what MCP servers are, local vs remote MCP, and permissions with human approval.
Home MCP is separate from Home Developer MCP on the same overview page. Home Developer MCP grounds coding tools in Home API, Matter, and OpenThread docs. This article is about the personal Home MCP that touches devices.
What the tools expose
The Home MCP Server documents five capability areas:
- `list_homes` - homes and structures the authorized user can access
- `list_home_resources` - devices, areas, traits, attributes, and command schemas
- `list_home_states` - live connectivity and trait state
- `list_home_history` - past state changes and chronological event logs
- `run_home_actions` - parameterized actions and mutations on target devices
Those map to the product examples on the MCP overview: how many lights you have, whether the home is secured, turn off outside lights, what happened while you were out. History and state tools are read paths. `run_home_actions` is the physical mutation path. Treat that split the same way you would treat a write tool on any other MCP server.
Creating and managing automations through Home MCP is not supported yet. Google lists that under Coming Soon. Experimental traits may not behave as expected. Latency can be higher than you want at Early Access.
Auth and access model
Home MCP uses a user-authorized OAuth flow. Setup requires a Google Cloud project, the Home API enabled, an OAuth consent screen, and a Web application OAuth client ID and secret. Client configs use the remote endpoint `https://home.googleapis.com/mcp`. OpenClaw examples on Google's page use SSE transport and the scope `https://www.googleapis.com/auth/home.platform.v2`.
Prerequisites in the docs: an active Google Home with devices, Google Home Premium Advanced, a Cloud project, and an MCP-compatible client. At Early Access, access was rolling out in English for Premium Advanced users in the United States. Google also noted a temporary entitlement bug that could let Nest Aware Plus subscribers reach Home MCP; they said a fix was coming. Recheck current entitlement rules before you plan a deployment on them.
Access can be revoked from the Google Home app or the My Accounts page. Familiar face camera data needs a separate explicit consent link (structure manager, compatible Nest camera or doorbell with Familiar face detection enabled, personalized with your OAuth client ID and structure ID). Do not assume ordinary Home MCP OAuth covers that data.
Hard safety bans are a floor
Google's docs warn that connecting a real home lets the agent control devices on your behalf. Home MCP enforces rate limits and safety protections, including prohibiting sensitive actions such as unlocking doors. That is important. It is not enough by itself.
The same warning says that, depending on your agent, connecting it to Home MCP can still produce unexpected or undesired behavior. Review developer policies and terms. If the home has other household members, tell them the agent can control devices and access home data, or use a separate development home for testing.
On a self-hosted OpenClaw or Hermes Gateway, platform bans do not replace tool policy. Prefer enabling the list and state tools before `run_home_actions`. Require a human for mutating calls until you have a narrow allowlist you trust. Bind approvals to the exact action payload where your client supports it. MCP permission controls that survive retries and typed action budgets are the patterns for tools you operate. They do not describe Google's internal ban list; they sit beside it.
OpenClaw and Hermes-class angle
Google documents an OpenClaw setup path: patch MCP server config for `home_mcp`, restart the Gateway, then `openclaw mcp login home_mcp` and finish OAuth in the browser. That puts a remote, OAuth-protected MCP server next to whatever else your Gateway already exposes.
Hermes was named in launch coverage as an example MCP-capable agent. Google's Home MCP setup pages currently spell out Antigravity, Claude Cowork, and OpenClaw client steps. If you connect Hermes or another host, confirm that host's remote MCP and OAuth support against current Hermes docs and Google's page before you treat it as a supported path.
Either way, you still own the host trust boundary. A shared Gateway that can call `run_home_actions` on a family home is a shared physical authority. Trust boundaries for self-hosted agents and the OpenClaw vs Hermes operating split still apply. Narrow the tool surface. Separate Gateways or profiles when operators do not share household trust. Keep browser automation out of the path when the MCP tool already exists; see browser vs MCP as the wrong surface.
Household and shared-home trust
Home MCP acts under the Google account that completed OAuth. Device history, live state, and allowed actions become agent-reachable context. That is useful for summaries and monitoring. It is also a privacy and safety boundary for everyone who lives in the structure.
Write down who may invoke the agent, which tools are enabled, and how revoke works (Google account revoke plus your Gateway tool policy). Prefer a dedicated test structure for development. Do not point an unattended cron or unattended mode at `run_home_actions` on a live home until the mutating path has an explicit human gate or a hard deny when nobody is present.
How this fits implementation work
OrchestriAI does not operate Google Home MCP, OpenClaw, or Hermes. MCP development is how we shape narrow tools when you need a custom boundary instead of a broad vendor surface. AI agent systems define the job, the tool list, and the human gate. Systems integration keeps credentials, identity, and side effects on the account that matches the home you authorized.
Home MCP is a useful case study for physical-world MCP: remote endpoint, user OAuth, read versus mutate tools, platform safety floor, and leftover agent-side policy. The same checklist applies when you wire any other remote MCP that can change the real world.
Independence and limitations
OrchestriAI is an independent implementation provider. Product names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Google, OpenClaw, or Nous Research / Hermes. This article summarizes Early Access documentation on developers.home.google.com/mcp and developers.home.google.com/mcp/home as of late September 2026. Entitlements, tool schemas, safety bans, and client setup steps can change. Confirm current Google Home MCP docs and your agent host docs before you connect a live home.
