Google Home MCP Makes Household State and Device Actions Callable—Governance Now Spans the Whole Chain
Google Home MCP is more consequential than a new way to turn off a light. Its documented tool surface lets an AI client discover a home, inspect current device state, query historical events, and request physical actions through one OAuth-authenticated connection. The product boundary therefore extends beyond model behavior to include client approvals, Google’s server-side policy, household consent, revocation, and audit evidence.
Google announced Early Access on September 16, 2026, with an English-language rollout for Google Home Premium Advanced users in the United States. The official launch post described a phased rollout, while TechCrunch reported that access would continue expanding to eligible subscribers over the following weeks. Google’s setup page remained labeled Early Access when checked on September 18, 2026 and was marked “Last updated 2026-09-15 UTC.” Google launch announcement Google Home MCP documentation TechCrunch launch report
The practical conclusion is narrower than “agents can run the house.” Home MCP exposes both observation and mutation, but the reviewed documentation does not yet describe a complete end-to-end governance model for unattended physical control.
Five tools create two different authority classes
Google documents five Home MCP tools. Four retrieve information; one requests changes to devices. That distinction should drive approval and deployment policy. Google Home MCP documentation
| Tool | Documented function | Authority class |
|---|---|---|
list_homes |
Retrieves accessible homes and structures | Discovery |
list_home_resources |
Lists devices, areas, traits, attributes, and command schemas | Discovery |
list_home_states |
Reads connectivity and current trait states | Current-state observation |
list_home_history |
Queries past state changes and event logs for specified time ranges | Historical observation |
run_home_actions |
Executes parameterized commands against target devices | Physical mutation |
Google’s sample prompts make the boundary concrete. “What happened while I was out?” is a historical query; “Turn off all the outside lights” is a control request. The launch announcement also describes camera summaries, home-history analysis, voice messages through Google Home speakers, and custom dashboards as early-use examples—not as accuracy guarantees or universal compatibility commitments. Google Home MCP documentation Google launch announcement
Illustrative authority spectrum: Google Home MCP’s discovery, live-state, and history tools remain observational, while run_home_actions crosses into physical mutation. This is a conceptual classification, not a measured risk score.
Inference: A workflow can be undesirable even when each individual call is valid. An agent might use history to infer which devices matter, discover command schemas, select a broad target set, and then call run_home_actions. Google confirms that the server blocks at least some sensitive actions, but that does not establish that every surprising sequence or overbroad device selection is prevented. This is an inference from the documented tool division, not a claim about undisclosed Google safeguards.
MCP standardizes calls, not one universal approval screen
The versioned MCP 2026-07-28 Tools specification defines tools as model-invokable functions. Clients discover the available set through tools/list and invoke a selected tool through tools/call; the returned tool set may vary according to the authorization presented with a request.
The specification describes tools as model-controlled and says the protocol does not mandate a particular interaction model. It uses SHOULD, rather than MUST, when recommending visible tool exposure, invocation indicators, confirmation prompts, a human able to deny calls, display of tool inputs before sensitive operations, and tool-use logging for audit purposes. Different clients can therefore satisfy those recommendations differently.
The broader 2026-07-28 MCP specification states stronger principles: users must explicitly consent to data access and operations, retain control over shared data and actions, and understand tools before authorization. It also says MCP cannot enforce those principles at protocol level. In other words, the standard expresses a consent requirement, while the actual confirmation interface remains an implementation responsibility.
The dated 2026-07-28 pages are now marked as an older specification version. Implementers should verify the protocol version negotiated by their chosen client and review the latest MCP Tools specification rather than assuming identical behavior across releases.
Google documents meaningful controls—but not every link in the chain
Confirmed Home MCP controls include:
- The setup uses a Google Cloud project, Home API enablement, access approval, OAuth credentials, and an MCP-compatible client. Google names Google Antigravity, Claude Cowork, and OpenClaw in its prerequisites.
- Google says Home MCP enforces rate limits and safety protections and explicitly identifies unlocking doors as a prohibited sensitive action. Because Google uses “such as,” that example should not be interpreted as a complete deny list.
- Access can be revoked from the Google Home app or the user’s My Accounts page.
- Google warns that behavior can be unexpected or undesired depending on the agent. It advises informing other household members when a shared home is connected and suggests creating an additional Home for development and testing.
- Familiar-face data requires a separate consent flow. The consenting user must manage the relevant Home structure, and compatible cameras or doorbells must have familiar-face detection enabled.
Illustrative control chain: a user request passes through an MCP host and client, OAuth authorization, Google Home MCP server policy, and the target device. Household notice, explicit approval, server denial, and revocation operate at different points.
Google’s Home Developer Policies impose broader platform obligations on integration developers. They require appropriate—not excessive—permissions, disclosure of data collection and use, security throughout the data lifecycle, and compliance with deletion requests. They also require device-setting changes to occur with user knowledge and consent and to be easily reversible.
The policies prohibit using data from a Google Home Developer Platform integration to train AI models or related tools. They also require secondary verification for operations that move a device into a non-secure or disabled state, citing examples that include unlocking a door, turning off a camera, disabling a security system, or opening a potentially safety-sensitive device. Bypassing platform safety checks and putting users’ physical safety at risk are expressly prohibited.
Those are platform-wide developer obligations, not proof that Home MCP exposes every cited operation or presents secondary verification identically in every client. The Home MCP-specific fact is narrower: Google says its server prohibits sensitive actions such as door unlocking.
Eligibility includes a subscription and developer setup
Early Access is not simply unlocked by owning an MCP-compatible assistant. Google lists the following prerequisites: an active Google Home with connected devices, Google Home Premium Advanced, a Google Cloud project, an MCP-compatible client, access approval, Home API enablement, and OAuth credentials. The launch condition further restricts the initial rollout to English-language users in the United States.
The official US Google Store displayed these baseline prices when checked on September 18, 2026:
- Standard: US$10 per month or US$100 per year
- Advanced: US$20 per month or US$200 per year
The store also advertises a 30-day trial. Home MCP Early Access requires Advanced, not Standard. Google Home Premium pricing
Google’s October 2025 subscription announcement said Google AI Pro members receive Standard and can upgrade to Advanced for US$10 per month, while Google AI Ultra members receive Advanced. Eligibility for Home MCP still depends on the Advanced entitlement and the other Early Access conditions; a bundle does not remove the Cloud, approval, OAuth, geography, language, or rollout requirements. Google Home Premium announcement
Early Access still carries documented limitations and open questions
Google lists two known issues: some exposed traits are experimental and may not work as expected, and Home MCP can experience longer-than-expected latency. The page also states that Home MCP cannot currently create or manage automations. That limitation applies to Home MCP, not necessarily to automation features elsewhere in Google Home.
Several operational details remain open within the reviewed Home MCP materials:
- Google confirms rate limiting but publishes no numerical Home MCP quotas, burst rules, or quota units on the setup page.
- The page provides no Home MCP availability target or latency service-level objective.
list_home_historyaccepts specified time ranges, but the page gives no numerical maximum query window.- Google provides a door-unlock example but no complete Home MCP sensitive-action catalogue.
- The MCP specification recommends client logging, but Google’s Home MCP page defines no Home-specific audit record covering the proposing model, displayed arguments, user approval, execution result, or denial reason.
These are documentation boundaries, not claims that Google lacks internal controls.
The setup page contains an unexplained endpoint discrepancy
The official page’s automated-setup prompt specifies:
https://preprod-home.sandbox.googleapis.com/mcp
Its manual configurations for Google Antigravity, Claude Cowork, and OpenClaw specify:
https://home.googleapis.com/mcp
The page version marked Last updated 2026-09-15 UTC does not explain the difference. That is a verified documentation inconsistency—not evidence that either endpoint is insecure, unstable, or functionally distinct. Google links a public Home MCP issue tracker for bugs and feature requests; teams should obtain clarification rather than compare the addresses with real household data.
A defensible deployment rule: read first, mutate only with visible approval
Recommendation—not a Google requirement: begin in a separate development Home with discovery and read-only workflows. Do not enable unattended run_home_actions calls until the actual tool inventory, client approval behavior, denial handling, audit evidence, household notice, and revocation path have been validated.
Proposed validation—Tech Trend Insight has not performed these tests:
- Snapshot the exposed tools. Record the names, descriptions, input schemas, and available arguments returned by the client. MCP permits the tool set to vary with authorization, so a documentation checklist is not a substitute for inspecting the granted surface.
- Compare benign approval behavior. With a virtual light or another non-safety-critical target, record whether the client shows the tool name, target devices, and arguments before execution; then verify what happens after denial or malformed input.
- Exercise revocation. Perform a benign state read, revoke access through Google Home or My Accounts, and confirm that subsequent discovery, history, and action requests fail. Avoid cameras, familiar-face data, locks, alarms, and safety-related devices.
- Escalate the endpoint mismatch. Request clarification through Google’s issue tracker before adopting either documented address for unattended use.
| Capability / Tool | Operation Scope | Risk Tier | Authorization / Confirmation | Failure Fallback Policy |
|---|---|---|---|---|
| list_structures | Query home spaces & room hierarchies | Low Risk | Not required (Autonomous) | Return cached local topology |
| list_devices | Enumerate registered devices & traits | Low Risk | Not required (Autonomous) | Degrade to known device roster |
| get_device_state | Poll real-time sensor/switch telemetry | Moderate | Not required (Autonomous) | Report last-known state with timestamp |
| execute_device_action | Mutate physical device state (e.g. locks, power) | High / Critical | Mandatory for security traits | Rollback transaction & notify user |
| batch_device_actions | Multi-step composite room automations | Elevated Risk | Preview confirmation prompt | Atomic abort if any critical step fails |
Illustrative deployment decision tree: a separate development Home and read-only tool inventory lead to approval and revocation tests; unattended physical actions remain deferred when arguments, logs, denial behavior, or endpoint status are unclear.
The practical gate is simple: if a client cannot show exactly which devices and arguments will be sent, preserve the approval record, report the outcome, and stop reliably after revocation, keep the connection read-only. A server-side block on door unlocking is important, but it is only one control in a system that can observe household activity and request physical change.
