Five function names now stand between an AI agent and the everyday machinery of a Google Home. Google's early-access Home MCP server can enumerate a home, discover its devices, read live state, inspect event history and issue actions, according to the published tool reference. For developers, that compact interface is the consequential part of the launch: a model can receive both the evidence needed to make a decision and the command needed to carry it out. Claude switching off a lamp is the easy part. The engineering question is where a home's permission boundary sits when the reasoning software comes from another company.
Google began rolling out the service on September 16 to US subscribers on its $20-per-month Google Home Premium Advanced plan, according to TechCrunch's report on the release. Access is arriving over several weeks. Google has not given a timetable for other countries or plans. The service is separate from Gemini for Home, which remains Google's built-in assistant in the Home app and on Nest speakers, The Verge reported.
Five calls span sensing and action
The official MCP reference lists a small surface. list_homes returns the structures a user can access. list_home_resources discovers rooms, devices, supported traits and command schemas. list_home_states reads current device conditions, while list_home_history retrieves past state changes and events. The fifth tool, run_home_actions, sends commands to one or more devices.
That last pair changes the nature of the integration. A conventional voice command starts with a human instruction and ends with a device response. Home MCP can let an agent look backward through events before choosing an action. Google's user guide suggests prompts that ask what happened while someone was away or whether a home is secured, alongside a command to turn off outside lights. The server can also return the schemas an agent needs to construct a valid action instead of relying on a fixed list baked into the client.
The current release stops short of giving agents every Home feature. Creating and managing automations is listed as coming later, and some exposed device traits are experimental. Google also warns that latency can be longer than expected in the known-issues section of its guide. Those limits leave this as an early integration layer. The mature controls in the Home app remain.
MCP itself is the transport contract here. The server publishes typed tools at https://home.googleapis.com/mcp. An agent host discovers their definitions through the standard tools/list method and submits a structured call, as shown in Google's server reference. The model does not need a custom Google Home plug-in for every device brand. Google translates the common call into the Home graph and the command schema supported by the target device.
'Any agent' still involves a developer setup
Protocol compatibility is only the first requirement. Google's setup flow asks a user to create a Google Cloud project, enable the Home API, configure an external OAuth consent screen, create a web-application client ID and publish the app. The user then adds the server URL and credentials to an MCP client before completing Google's sign-in flow. That is familiar work for a developer. It is a high bar for someone who only wants another assistant to control a thermostat.
Google's guide provides instructions for Antigravity, Claude Cowork and OpenClaw. TechCrunch also names ChatGPT and Hermes among compatible agents. The phrase 'any agent' describes an open protocol boundary. It does not make the feature available inside every chat product. A client still has to support remote MCP connections, OAuth and the Home server's tools. Its maker must decide how calls are displayed and when the person at the keyboard gets an approval prompt.
The public configuration uses one OAuth scope, https://www.googleapis.com/auth/home.platform.v2. During authorization, the user selects the Home structure the client may access. Google's launch documentation does not publish separate OAuth scopes for device discovery, state, history and actions. Familiar-face data gets an additional consent flow, and only a manager of the selected Home structure can grant it. That extra step is useful, but it also shows how much information sits behind the broader Home connection before facial recognition enters the picture.
The subscription gate narrows the first test group further. The Verge puts the qualifying plan at $20 per month or $200 per year in the US. A Premium Advanced subscription, a Cloud project and an MCP-capable client are all prerequisites in Google's guide. Early reports will therefore come mostly from developers and users willing to configure a Cloud project. They will not represent all Google Home households.
Google's action block is one part of the boundary
Google says Home MCP applies rate limits and blocks sensitive actions such as unlocking a door. Its guide does not provide a complete public table of every blocked command. That distinction matters when a home includes thermostats, cameras, lights and appliances from different manufacturers. Developers can rely on the documented door-lock example. They still need to test the allowed behavior of each device trait instead of treating 'safe' as a complete action specification.
The server can refuse a forbidden action. The client still decides how clearly it explains an allowed one before asking for approval. Google's verification steps tell users to grant tool-execution permission when their chosen client prompts them. A vague dialog saying that an assistant wants to use run_home_actions conveys less than one naming the device, requested state and reason. MCP standardizes the call shape, while the quality of that consent moment belongs to the client.
Google's own warning is unusually direct. Connecting an agent may produce unexpected or unwanted behavior, the Home MCP guide says, and people should tell other household members that an agent can reach device data and controls. The company suggests creating a separate Home with test devices during development. Access can be revoked through the Google Home app or the user's Google Account.
Those instructions define a sensible test routine. Start with devices that cannot admit a person, disable an alarm or create a hazardous physical condition. Inspect every requested tool call. Revoke the grant and confirm the client loses access. None of those checks proves that a model will behave correctly later, but they verify the controls Google actually documents around it.
Event history deserves the same attention as device control
A switched light is visible. A history query is quieter and may disclose more. The server can retrieve chronological state changes and event logs over a selected period. Google promotes this for questions such as how long lights remained on or what happened while the user was away. The Verge also describes Google's example of summarizing a child's arrival across multiple cameras.
That access can reveal household routines without moving a single device. Repeated light, thermostat and camera events may indicate when people wake, leave or return. Google requires separate consent for familiar-face data in its Home MCP guide, but ordinary device history already gives an agent material for inferences about occupancy and habits. Developers should treat list_home_history as sensitive access in its own right. Calling it the harmless read half of the API would miss what the events can reveal.
History is also where Home MCP can do more than reproduce a voice assistant. A model can compare events across rooms, explain a pattern in plain language or build a dashboard around the result. The same breadth that makes those uses possible makes data minimization harder. The current guide describes choosing a Home structure during consent. It shows no separate grant for one named bulb or one hour of history. Client makers can still constrain their own calls, though that is an application promise rather than a separate Google permission shown in the launch documentation.
Useful early tests start with failure
Google has shipped enough reference material for developers to test the boundary instead of guessing about it. Useful reports can now show which actions the server rejects, what a client displays before an allowed command, whether revocation takes effect immediately and how much history a routine request returns. They can also compare the confirmation behavior of Antigravity, Claude Cowork and OpenClaw against the same five server tools.
Watch for Google to publish finer permission choices, a full list of action restrictions and a schedule beyond the US Premium Advanced tier. The current guide says automation support is coming later, so the action model documented today is incomplete. For now, the five tool names are easy to audit. The harder test is whether every person in the home can understand, limit and withdraw what those five calls permit.