Agentic AI Wiki
AI Blog / Four reads and one write — Google Home MCP gated the half nobody was worried about
AI Blog

Four reads and one write — Google Home MCP gated the half nobody was worried about

Google blocked the thing everyone asked about: an agent connected through Home MCP cannot unlock your door. But four of the five tools are reads, and list_home_history hands a third-party agent a queryable record of motion, presence and door events over any window — with no equivalent gate, because nobody has written down what a sensitive read is. Actuation is bounded, legible and reversible. The read side is none of those.

By Agentic AI Wiki 13 min read

Google blocked the thing everybody asked about: an agent connected through Home MCP cannot unlock your door. Four of the server's five tools are reads, and one of them hands a third-party agent a queryable log of motion, presence and door events over any window it asks for — with no equivalent gate, because nobody has written down what a sensitive read is. The actuation risk is the one that is bounded, legible and mostly reversible. The read risk is none of those.

At a glance

The whole surface, in the shape that decides how you reason about it.

ToolDirectionWhat it returns or does
list_homesReadWhich homes and structures the agent can reach
list_home_resourcesReadDevices, area layout, traits, attributes, command schemas
list_home_statesReadLive connectivity and current trait states
list_home_historyReadPast state changes and event logs over a chosen time range
run_home_actionsWriteParameterized action commands against target devices
The five tools of the Google Home MCP server A third-party agent connects through an OAuth token to the Home MCP server, which exposes five tools. Four are reads — list_homes, list_home_resources, list_home_states and list_home_history — and one is a write, run_home_actions. The write is behind a gate carrying rate limits and a block on sensitive actions such as unlocking a door. The event-history read has no equivalent gate, because no list of sensitive reads exists. Four reads, one write — and the gate is on the write. Your agent Claude, Antigravity, Hermes, OpenClaw… Home MCP server reached with an OAuth token from a Cloud project you set up list_homes which homes you can reach list_home_resources devices, areas, traits, command schemas list_home_states live connectivity and trait states list_home_history past state changes and event logs four reads run_home_actions parameterized commands on a device one write No gate nobody has written down a sensitive read Gate rate limits; unlocking a door is blocked
The control that exists sits on the one tool that changes the world. The four that describe it have none.

What Google shipped on 16 September

Home MCP is an MCP server for the Google Home ecosystem, opened in early access on 16 September 2026. An agent that speaks MCP can discover the structures on the account, enumerate devices and their command schemas, read live state, query event history, and execute commands — across Nest doorbells and thermostats and anything in Works with Google Home or Matter.

Three things about the shape of the launch are worth keeping.

  • It is explicitly for agents Google does not control. Google's own examples name Google Antigravity, Claude, Hermes and OpenClaw. This is not a Gemini feature with an MCP wrapper; it is a first-party surface designed to be driven by third-party models.
  • It is gated behind money and friction. Early access is for Google Home Premium Advanced subscribers in the US, in English — $20 a month or $200 a year — and setup requires standing up a Google Cloud project, enabling the Home API, creating OAuth consent and client credentials, publishing the app, and handing the MCP configuration to your agent.
  • There are safety limits, and they are on the write. The server enforces rate limits and blocks sensitive actions; the example Google gives is that an agent may not unlock a door.

That last decision is correct and deserves credit. Unlocking is the single action where a model error and a physical-security failure are the same event, and declining to expose it at all is better than exposing it behind a confirmation prompt that a tired person will approve. Google drew the line at the right place on the write side.

The write side is not where most of the surface is.

The 4:1 ratio is the story

Which Home MCP tool carries which control A matrix of the five Home MCP tools against four properties: rate limiting, a named sensitive-action block, how bounded the returned data is, and whether the call can be reversed. Only run_home_actions has a named block and is usually reversible. Every read is unreversible by nature, and list_home_history returns an arbitrary window rather than a bounded snapshot. Which tool carries which control Rate limited Named block Bounded return Reversible list_homes Yes None defined Small and fixed No — it is a read list_home_resources Yes None defined The whole home No — it is a read list_home_states Yes None defined Live snapshot No — it is a read list_home_history Yes None defined Any time window No — it is a read run_home_actions Yes Unlocking blocked Runtime traits Usually Strong Partial Absent
One row has a control in the column where it matters. The others are held up by the rate limiter.

Actuation is the risk people can picture, and that is exactly why it is the manageable one. Turning on a light is bounded — there is a finite set of devices, each with a finite set of commands, each of which can be undone by issuing the opposite command. It is legible: you notice. It is attributable: the state changed at a timestamp with a caller attached. And the worst cases are enumerable, which is what let Google write a blocklist in the first place.

Now take list_home_history against the same four properties.

It is not bounded

A state read tells you the house as it is right now. An event-history query over a chosen range tells you the house as it has been — which lights came on at what hour, when the front door opened, when motion stopped, which days nobody was home. A single call with a wide window returns a behavioural record that no single snapshot could reconstruct. The volume difference between "read the thermostat" and "read six weeks of door events" is not a factor of two.

It is not reversible

A wrong actuation can be corrected. A read cannot be un-read. Once six weeks of presence data are in an agent's context window, they are in whatever that agent does next: a summary, a memory write, a trace in an observability backend, a model provider's logs, a debugging export. The relevant boundary is not the MCP call; it is every system downstream of it, none of which Google can see.

It has no blocklist, and could not easily have one

"Do not unlock the door" is writable because unlocking is a named action. There is no equivalent name for the read that matters. "Do not tell the agent when the house is empty" is not a command to block — it is an inference the agent draws from event data that is individually innocuous. Every event in the log is boring. The pattern is the sensitive object, and pattern is not something a server-side allowlist can refuse.

This is the general asymmetry, not a Google-specific one. Every agent integration into a system of record has a write surface someone thought hard about and a read surface that shipped because reads feel safe. Reads feel safe because in a pre-agent world the reader was a person with a screen and a limited appetite. The reader is now a process that will happily pull the maximum the API allows, summarise it, and carry the summary somewhere else.

The action space is discovered, not declared

There is a second structural point in this design that matters more the further it spreads. run_home_actions executes parameterized commands, and the parameters come from command schemas that list_home_resources reports at runtime, per device, per trait.

So the set of actions available to the agent is not a property of the MCP server. It is a property of what you plugged in this afternoon. Buy a Matter-compatible blind, pair it, and your agent's action space has grown without a deploy, a review, or a version bump anywhere in your stack.

For anyone trying to put policy around this, that is the whole problem. You cannot write an allowlist of actions ahead of time, because you do not know the actions ahead of time. What you can write is a policy over traits — categories of capability — plus a default-deny for any trait the policy has not seen before. That is a meaningfully different control design from "here are our twelve approved tools", and it is the one this surface forces. The same issue appears whenever a tool catalogue is dynamic; tool-catalogue lifecycle is the operational form of it.

The optimistic reading is that this is how physical environments have always worked and software is only now catching up. The realistic reading is that an ambient-authority grant — one OAuth token, all devices, all history — is being handed to a long-lived process whose capability set changes when someone buys a lamp.

Event history is untrusted input

The risk that actually reaches production first is not a malicious agent. It is a correct agent reading poisoned data, and a home is unusually good at producing it.

  • Device names are attacker-supplied strings. Anyone who can add or rename a device on the account controls text that lands in the agent's context. A guest, a contractor, a previous tenant, a compromised third-party integration. A device named to look like an instruction is the oldest trick in the MCP anti-pattern catalogue, and here the naming surface belongs to a consumer app with no adversarial-input review.
  • Camera and doorbell events are model output. An event summary describing what a camera saw is itself generated text. Feeding one model's description into another model's context is a supply chain, and the upstream model has no notion that its output will be read as a fact by something with tool access.
  • The history is the reconnaissance. If an injected instruction ever does land, the same connection that carries it also carries the schedule of the household. That combination — untrusted text plus a behavioural record plus an actuation tool — is the full loop, and telemetry as untrusted input is the pattern it belongs to.

None of this requires anyone to have done anything wrong. It is what happens when a data source built for a phone app becomes a data source for a program that acts.

The strongest objection

Google already has this data. Nest cameras, doorbells and thermostats have been streaming event history into Google's infrastructure for a decade, and the Home app shows you the same timeline on a phone. Adding an MCP endpoint does not create a privacy exposure; it re-exposes one you already accepted when you bought the doorbell.

That is true about the data and wrong about the exposure, for one reason: the recipient changed. Every pre-existing control on that history — Google's retention policy, its access controls, its legal-process posture, its published commitments — applies to Google. None of them travel with a copy of the data that has been handed to an agent operated by a different company under a different privacy policy and, quite possibly, a different jurisdiction.

And the grant is coarse. A person authorising this is consenting to "my agent can use my home", which sounds like the light-switch story. What the token actually confers is a standing, revocable-only-wholesale right to read the behavioural history of everyone who lives there. Those are different consents, and the consumer OAuth screen is not a good instrument for distinguishing them — see delegated access and consent records for why the record of what was granted matters as much as the grant.

The objection does land in one place, and it is worth conceding: this is not a new capability so much as a newly convenient one. The fix is correspondingly modest. Not "do not ship it" — separate the scopes.

What to do

If you are connecting an agent to your home this week

  • Use a separate Google account for the integration where you can, with the minimum set of devices shared into it. The unit of blast radius here is the account, so make the account small. This is blast radius applied to a house.
  • Assume the history is the sensitive part and behave accordingly. Ask for narrow windows. Do not leave a long-running agent with standing permission to query it unprompted on a schedule.
  • Know where the transcript goes. If your agent's provider retains conversations for abuse monitoring or training, your door-event log is in scope of that policy, not Google's.
  • Rename your devices boringly. It costs nothing, and it removes the cheapest injection surface in the system.
  • Check who else is on the account. A home is multi-person and an OAuth grant is not. Everyone whose presence the sensors record is a data subject here, and none of them saw the consent screen.

If you are designing an agent surface over a system of record

  • Scope reads as carefully as writes. Historical queries deserve their own scope, their own rate limit, and their own consent string. "Read current state" and "read six months of history" should not be the same permission, and today, in almost every product, they are.
  • Return windows, not firehoses. A server-side cap on the width of a history query is a one-line control that survives every downstream mistake. Make the agent ask again for more, and log that it did.
  • Write policy over capability categories, not tool names. If your action set is discovered at runtime, name-based allowlists are decoration. Default-deny unknown categories — see MCP tool design.
  • Publish what the blocklist contains. "Sensitive actions are blocked" is unauditable. A named, versioned list is a thing operators can build on and researchers can check, and it is the difference between a safety property and a safety claim.

If you take one thing from this launch, make it the question you ask of your own integrations: which of my read tools returns something whose aggregate is more sensitive than any of its rows? That is the tool with no gate on it, and you almost certainly have one.

FAQ

Can an AI agent unlock my door through Home MCP?

No. Google enforces rate limits and blocks sensitive actions, and unlocking a door is the example it gives of a blocked action. The blocklist applies to the write tool, run_home_actions.

What does Home MCP cost and who can use it?

Early access is for Google Home Premium Advanced subscribers in the US, in English, with access rolling out over subsequent weeks. That tier is $20 a month or $200 a year. Setup also requires a Google Cloud project with the Home API enabled and OAuth credentials created.

Which agents can connect?

Any MCP-capable client. Google's own examples name Google Antigravity, Claude, Hermes and OpenClaw, which is the notable part: the surface is designed for agents Google does not operate.

If the actuation is gated, what is left to worry about?

The reads. list_home_history returns past state changes and event logs over a time range you choose, which is a behavioural record of the household. It is rate limited, but there is no sensitive-read blocklist, a read cannot be undone, and the data leaves Google's control the moment it enters a third-party agent's context.

Why can't Google just block the sensitive reads too?

Because the sensitive object is a pattern, not a row. Each individual event — a light on, motion detected, a door opened — is innocuous, and "when is the house empty" is an inference over the set. A server cannot refuse an inference; it can only cap the window, which is why a width limit is the control that would actually help.

Is this worse than the Google Home app I already use?

The data is the same; the recipient is not. Google's retention, access control and legal commitments govern Google's copy. They do not follow a copy handed to an agent run by another company under another policy, and the OAuth grant does not separate "control my devices" from "read my household's history".

Further reading

On this wiki:

Sources: