Google's Home MCP: how to expose real-world tools to agents

What shipped

Google has opened early access to Home MCP, a first-party Model Context Protocol server that lets an agent read and act on every Nest and Matter device in a home. According to TechCrunch, the rollout began on 16 September 2026 and continues over the coming weeks, limited to Google Home Premium Advanced subscribers in the United States at $20 per month. The supported agents named in that report are Claude, ChatGPT, Hermes, OpenClaw and Google Antigravity. Google declined to comment on a wider rollout.

The reason this matters to people who build agent systems, rather than people who own a Nest thermostat, is the shape of what Google exposed. Google's developer page describes two servers: Home MCP, which "connects agents natively to physical spaces" through a user-authorised OAuth flow, and Home Developer MCP, which grounds coding tools in "verified technical data" with no sign-up at all. The first is a rare, public example of a large consumer-hardware platform deciding exactly how much of the physical world an LLM should be allowed to touch. The second is something you can wire into Claude Code before you finish reading this.

Five tools, one of them writes

The Home MCP reference lists five tools. Four of them only read:

• list_homes — which structures the token can see
• list_home_resources — devices, areas, traits and the command schemas each device accepts
• list_home_states — current state of those devices
• list_home_history — the event history, including camera events

The fifth, run_home_actions, is the single write path. Google's own description is "execute parameterized action commands on target devices", and the parameters come from the schemas list_home_resources returned. That is the whole surface: an agent discovers what exists, reads what it is doing, and pushes commands through one choke point.

Two constraints sit on top of that. The docs state that "Home MCP enforces rate limits and safety protections, such as prohibiting sensitive actions like unlocking doors", and that "creating and managing automations with Home MCP is not supported at this time". So the agent can turn a lamp on now, but it cannot install a rule that turns the lamp on every night, and it cannot open the front door under any prompt. Known issues in the same document mention experimental traits and latency.

The production endpoint is https://home.googleapis.com/mcp with the OAuth scope https://www.googleapis.com/auth/home.platform.v2, and a preprod endpoint exists for testing. Per Unite.AI, the launch post came from Taylor, Group Product Manager for Google Home and Nest, access is rolling out in English to US users, and familiar-face recognition data needs separate, explicit consent from the structure manager. That last detail is a third tier of gating: paid subscription, then OAuth grant, then a distinct opt-in for the most sensitive data class.

Two minutes: Home Developer MCP in Claude Code

The companion server is the one you can use today. Home Developer MCP lives at https://homedevelopers.googleapis.com/mcp and exposes one tool, search_documents, over the Google Home Developer Center, OpenThread, the Matter Specification 1.5.1 and the Thread Specification 1.4.1. The unauthenticated trial runs on a "shared public quota"; for real use you send an X-Goog-Api-Key header with a key from your own Cloud project.

Google documents Claude Code setup through claude mcp add. The shape is a remote HTTP server registration:

claude mcp add --transport http home-developer https://homedevelopers.googleapis.com/mcp

Copy the exact invocation from Google's page rather than from memory, because the flag names for headers and transports have shifted between Claude Code releases. Once it is registered, a question like "what does the Matter OnOff cluster require for a dimmable light" gets answered from the specification text instead of from whatever the model half-remembers about a spec that is versioned quarterly. Google lists native support for the Antigravity suite plus "Claude Code, Cursor, and GitHub Copilot (VS Code)", so the same endpoint serves whichever editor your team standardised on.

If you build Matter or Thread firmware, this is the higher-value half of the announcement. It costs nothing and it removes an entire class of hallucinated cluster attributes.

What the full Home MCP setup actually costs

Home MCP is a different order of effort. Beyond the $20 per month subscription, which Engadget also lists at $200 per year, the setup steps are:

1. Create a Google Cloud project and enable the Home API.
2. Configure an external OAuth consent screen.
3. Create a web-application OAuth client, adding a redirect URI for every agent that will connect.
4. Publish the app so the agent can complete the OAuth flow.

Then each agent runs the standard OAuth dance against your client and receives a token scoped to home.platform.v2. Note what this design does: the paid subscription is an identity anchor (a billing relationship with a real person), the Cloud project is an accountability anchor (a named developer owns the client), and the OAuth grant is a consent anchor (the resident explicitly approved this agent). None of those is a technical control on its own, but together they mean there is always a human on the hook for any command the agent issues.

For a home-lab user that is a lot of ceremony. For a design review of how to gate agent access to hardware, it is the point.

The security argument, and why it is not solved

Engadget's framing deserves a straight answer. Its report sets the launch against warnings from security experts about MCP's "serious security flaws, like a lack of enforced authentication" and the breaches that have followed since adoption began. Google's response is the list above: OAuth 2.0, rate limits, the door-lock denylist, no automations.

Those controls address the server side. They do not address what happens on the agent side once a token exists. An agent that holds a Home MCP token also typically holds tokens for email, a browser, a file system, or a dozen other MCP servers. Prompt injection through any one of them can steer the same agent into calling list_home_history and exfiltrating camera events, or into calling run_home_actions with a payload the resident never asked for. The door-lock ban caps the worst physical outcome; it does nothing about a privacy leak, and nothing about a thermostat set to 30 degrees at 3 a.m. by a poisoned web page.

That is not a Google-specific flaw. It is the property of any agent with multiple tool grants, and it is the reason the read-heavy, single-write-path shape matters: it limits what a compromised agent can do to a bounded, auditable set of commands.

What to copy into your own tool surfaces

If you expose anything with real-world consequences to an agent, Google's layout is a pattern worth stealing outright:

• Separate discovery, state and history into read-only tools. Most agent tasks are reads. Keeping them side-effect free makes the write path small enough to review.
• One parameterised write tool, with schemas the agent must fetch first. run_home_actions takes commands that list_home_resources described. That forces the agent to ground its action in the server's vocabulary, not its own guess.
• A server-side denylist for irreversible actions. Door locks are Google's example. Yours might be deletes, payments, or production deploys. Refuse them in the server, not in the system prompt, because the system prompt is what an injection rewrites.
• No standing automations from the agent. A one-shot command is scoped to a conversation someone is watching. A rule the agent installs keeps running after the conversation ends.
• Scoped, consented, revocable tokens tied to an identity. The OAuth scope plus the paid subscription plus a separate consent for face data is three layers where most homegrown MCP servers have zero.

Then do the audit. List every MCP server your agents can reach. For each, ask: does it require authentication at all, does it have a write tool, does that write tool have any refusals baked in, and can the agent create something that persists after the session. The ones that fail all four are the ones an injected instruction will reach first. The MCP specification leaves all of this to the server author, which is exactly why a worked example from a platform with cameras in millions of homes is useful: it shows where the floor should be.