Google Home MCP Opens in Early Access With Five Tools and Only One That Writes

Google's Home MCP server is in Early Access as of developer documentation last updated on September 15, 2026, exposing five tools through which an AI agent can inspect and control a smart home. The five are list_homes, list_home_resources, list_home_states, list_home_history and run_home_actions, and run_home_actions is the only one that issues a command to a device. Connecting requires an active Google Home setup with connected devices, an active Google Home Premium Advanced subscription, access to a Google Cloud project and an MCP-compatible client, and Google names Google Antigravity, Claude Cowork and OpenClaw as example clients. ASAP reads this connection tool by tool to separate what it permits from what it blocks.

Four of the five tools read and one writes

The five tools Home MCP exposes split into four reads and one write, and that ratio is where any permission analysis starts. list_homes retrieves accessible homes and structures, and list_home_resources enumerates devices, room layouts, traits, attributes and command schemas. list_home_states checks real-time device connectivity and trait state, and list_home_history queries past state changes and event logs over a given period.

The write tool is run_home_actions, which executes parameterized action commands on target devices. Every path by which an agent actually changes something inside the house runs through that single tool. The sample prompts in the documentation cover the four capability areas: how many lights are in the house, whether the home is secured, turning off all the outside lights, and what happened while the user was out.

The server itself acts as a proxy between smart home infrastructure and AI applications. Authentication is OAuth 2.0, and the auto-configuration prompt in the documentation specifies sse transport, the home.platform.v2 scope and a server address on the preprod-home.sandbox.googleapis.com domain. The words preprod and sandbox inside that address describe the stage this is at.

The gates before connection are a subscription and a cloud project

Four prerequisites stand between a user and a working Home MCP connection, and two of them are unfamiliar territory for a consumer. The first is an active Google Home smart home setup with connected devices and the second is an active Google Home Premium Advanced subscription. The third is access to a Google Cloud project and the fourth is an MCP-compatible AI client or application.

The setup itself is a developer workflow. You create a Google Cloud project, enable the Home API, configure the OAuth consent screen for an external audience, create a web-application OAuth client ID and copy the client secret. Authorized redirect URIs differ per client: the documentation specifies a callback on the antigravity.google domain for Google Antigravity, the MCP auth callback on the claude.ai domain for Claude Cowork, and whatever URI a local installation designates for OpenClaw. Finally the app has to be published from the Google Auth Platform before the connection opens.

What that procedure means is unambiguous. Home MCP at this stage is a developer feature rather than a consumer one. Few households will walk through configuring an OAuth consent screen in a cloud console and publishing an app. Combined with the subscription requirement, the audience for this Early Access stage narrows to developers building smart home agents and to early adopters.

The key to the house moves from assistant brand to protocol

Google naming Claude Cowork and OpenClaw as connection targets in its own documentation is a signal that the axis of smart home competition is shifting. The last decade of that competition was a fight over which assistant owned the house. Device makers wired separate integrations to Google Assistant, Alexa and Siri, and choosing an assistant meant choosing the control layer for your home along with it.

Opening the house through MCP inverts that structure. What Google provides here is not an assistant but a specification for five tools, and whatever agent the user picked can be the thing that calls them. For Google this is not a concession. Opening the control layer leaves device integrations, home structure and history data inside Google Home, and the Premium Advanced subscription remains as the billing point. It is a structure in which Google can lose the assistant market and stay in the home platform market.

The relationship to Matter resolves in the same frame. Matter standardized interoperability between devices, while MCP standardizes interoperability between agents and platforms. Different layers, so they stack rather than substitute. As the manufacturer barrier falls below and the assistant barrier falls above, what remains as competitive advantage shifts toward device coverage, data quality, and the safeguards that apply when an agent gets something wrong in a real house.

History retrieval is the heaviest permission in this release

Among the five Home MCP tools, list_home_history is the one that touches privacy most directly, because it reads the full record of state changes and event logs inside a house over a chosen period. Turning a light on and off is visible and reversible, while a history query happens silently and leaves nothing to reverse. When a house was empty, when someone returned, which room was occupied at what hour: a time series of device state changes reconstructs much of that on its own.

Google separating face data into its own consent flow acknowledges that sensitivity. Accessing familiar-face data through Home MCP requires the user to give separate, explicit consent for the feature, requires the consenting user to be an admin of the Google Home structure, and requires at least one compatible Google Nest camera or doorbell in the structure with an active Google Home Premium subscription that has familiar-face recognition enabled for each device. Consent is granted by visiting a link customized with the OAuth 2.0 client ID and the home structure ID.

General history retrieval carries no equivalent separate consent step in the documentation. list_home_history opens under the same single scope as the other four tools. Given that a time series of household activity identifies a person about as well as a face image does, per-tool permission granularity looks like the design need for the next stage. Google does state that agent access to Home MCP can be revoked at any time from the Google Home app or the account page, and that blanket revocation is currently the strongest control a user holds.

The one named prohibition is unlocking doors

The safety protections in Google's warning are rate limiting and a prohibition on sensitive actions such as unlocking doors, and unlocking doors is the only action the documentation names. The same warning adds that connecting to Home MCP may produce unexpected or unwanted behavior depending on the agent, and directs developers to review the developer policies and terms of service carefully. No number is given for the rate limit.

The brevity of that prohibition list is worth weighing in practice. Opening a door is the most obvious hazard, and it is not the only action in a house that resists being undone. Turning off heating in midwinter, disarming a security system, disabling a camera: all are forms of control that can travel through run_home_actions. The documentation states that traits marked experimental were included to give agents the broadest possible capability, which is Google explaining its own tilt toward openness over restriction.

One agent-specific risk sits on top of that. Values Home MCP returns include device names, room names and event log entries, all strings that users or manufacturers chose freely. From a prompt-injection standpoint those strings are model input, and a session in which read-tool output and write-tool invocation are both available deserves care as a design matter. Google's advice to inform other household members before connecting a shared home, and to create an additional home for development and testing, reads as counsel written against the same uncertainty.

What to check first before evaluating this outside the US

The first item to verify for any team evaluating Home MCP is whether a Google Home Premium Advanced subscription is available in the market in question. The subscription is a prerequisite rather than an option, and Google Home Premium tiers have opened on different schedules by country. Whether the tier that includes familiar-face recognition is offered, and whether compatible Nest cameras are in place, need the same verification.

The second is the shape of the local device ecosystem. In markets where smart homes formed around carrier hubs and domestic manufacturer platforms, how many devices are actually registered in Google Home decides whether Home MCP does anything useful. An empty return from list_home_resources makes an open tool meaningless. Expanding Matter-capable devices to raise the count registered on the Google Home side is closer to a precondition than a follow-up.

The third is what this move implies for platform operators elsewhere. Once Google opens the control layer through MCP, a home platform that reaches users only through the assistant inside its own app has a harder time holding its position. Letting whatever agent the user runs reach your devices is the better long-run bet for device sales and subscriptions, and what that requires is a tool specification and a permission model rather than another assistant. The form Google published, five tools under one scope, shows a workable minimum unit to copy.

What Early Access does not hide about being unfinished

Google lists its known issues and upcoming features in the documentation, and that list is the fair measure of current maturity. There are two known issues: some traits marked experimental were included to give agents the broadest capability and may not behave as expected, and Home MCP latency may be higher than expected while Google works on optimization.

Automations sit on the upcoming list. Creating and managing automations through Home MCP is not supported today, and Google states it is developing the capability and plans to provide automation support in a future release. That one line summarizes the current stage. What an agent can do now is read the house and touch it occasionally, not write standing rules into it.

The absence of automations is closer to good news from a risk standpoint. The moment automation-creation authority opens, a single misjudgment by an agent hardens into a rule resident in the house, and that rule keeps firing until a person opens the automation list. Today every action ends with its session, which bounds the blast radius to that session. The release that adds automation support is the one that genuinely tests Home MCP's safety design, and the thing to watch then is whether a prohibition list longer than one line and a rate limit with an actual number arrive alongside it.

Source: Google Home MCP Server (Google Home Developers, updated September 15, 2026)