Google has started opening Google Home to AI agents through the Model Context Protocol, or MCP. Early access began this week for Google Home Premium Advanced subscribers in the United States. A compatible agent can discover devices, inspect their current state, look through historical events and issue supported commands. That turns a smart home from a collection of app-specific controls into something closer to a toolset that an assistant can reason about.
I find the interface more interesting than the individual examples. Turning off lights by voice is old news. The meaningful change is that the assistant does not have to be Google's own assistant. Google documents Home MCP as a standard endpoint that MCP-compatible clients can connect to, with examples including Antigravity, Claude Cowork and OpenClaw. In other words, the home is becoming infrastructure that an agent can use rather than a feature trapped behind one conversational interface.
The useful part is the tool boundary
Google's documentation exposes a small set of concrete tools. An agent can list homes, discover resources, read current device states, query historical events and execute home actions. That separation matters. A language model does not need to know the private implementation of every thermostat, camera or light. It can inspect a structured description of what is available, decide which tool fits the request, then make a constrained call.
This is roughly the same architectural idea that has made MCP interesting for developer tools and business systems. The model handles language and planning. The MCP server translates that intent into operations against a real system. Google Home makes the pattern unusually tangible because the output is no longer a database query or generated file. A successful tool call can change something in a room.
That also makes historical data useful. An assistant could answer a question such as what happened while someone was away by querying device history instead of trying to infer an answer from a conversation. TechCrunch reports that Google is positioning camera summaries, activity monitoring, device control and custom smart-home dashboards as early examples. The assistant gains context from the environment, not just from whatever the user remembered to type.
A useful assistant needs permission, not unlimited access
The obvious problem is that giving an AI access to a house is more consequential than giving it access to a weather API. Google's own documentation includes a prominent warning that connecting a real home allows an agent to control devices on the user's behalf and may produce unexpected or undesired behaviour. Home MCP applies rate limits and blocks sensitive operations such as unlocking doors. Access can also be revoked.
Those restrictions are not an awkward detail around the feature. They are part of the architecture an actually useful assistant needs. A capable agent should be able to inspect a thermostat without automatically gaining permission to open a lock. It should be possible to revoke access without uninstalling every device. And when several people share a home, one person's clever automation becomes everybody else's security boundary.
This is where agent engineering starts looking less like chatbot engineering. The difficult questions become scopes, authentication, auditability, confirmation rules and failure recovery. Natural language is merely the front door. Once an assistant can act, the system around the model has to decide what the model is allowed to touch and what happens when its interpretation is wrong.
It is open, but not frictionless
The early-access version is still aimed at people willing to configure infrastructure. Google's setup requires an active Premium Advanced subscription, a Google Cloud project, the Home API, OAuth credentials and an MCP-compatible client. TechCrunch reports that the initial rollout is limited to the United States and the $20-per-month Premium Advanced tier. Google has not publicly committed to a broader timetable.
There are technical limitations too. Google's documentation lists latency as a known issue and says creating or managing automations through Home MCP is not supported yet. That distinction is important. An agent can perform supported actions and inspect history, but this is not yet a universal natural-language replacement for the automation engine behind a mature smart home.
Still, interoperability changes the shape of the problem. If a common protocol can describe the tools, authentication and actions, developers do not need a bespoke integration between every assistant and every smart-home platform. The Verge describes the move as allowing third-party agents to interact with Google Home while Gemini remains the normal in-home assistant. That coexistence may be more realistic than expecting one AI provider to own every interface a person uses.
Assistants become interesting when the chat stops being the product
For years, an AI assistant mostly meant a text box with a model behind it. The model could explain how to automate something, but the actual automation lived somewhere else. MCP-style integrations shift some of the value away from the conversation itself. The assistant can inspect a system, call a defined operation, observe the result and continue from there.
A smart home is a good demonstration because the difference is easy to see. Asking an assistant whether a light is on requires current state. Asking what happened overnight requires history. Asking it to turn the light off requires authority to act. Those are three different capabilities, and none can be solved reliably by making the language model more eloquent.
This does not make the general-purpose personal assistant problem solved. The setup is still technical, access is restricted, latency exists, automations are incomplete and the permission model has to remain deliberately conservative. But it is a useful direction. The path from chatbot to assistant may depend less on making models sound more human and more on giving them boring, well-defined interfaces to the systems around us.