skip to content
The Weighted Average

Agentic Engineering

Google Home MCP Makes a $400 Claude Stack

Home MCP plus annual Claude Pro costs $400 a year before devices. Test consent, latency and action results before delegating a household.

A glowing white table lamp stands beside a vase and books
A glowing white table lamp stands beside a vase and books. Photograph by Andy Bob

Google is opening its smart home to third-party AI agents through Home MCP, initially for US Premium Advanced users. Pairing the required annual Home subscription with annual Claude Pro creates a $400-a-year subscription stack before tax, devices, and implementation work—a useful pilot budget, not a universal price for connecting an agent.

The connector is another subscription boundary

The arithmetic combines two independent price sources. The Verge reports Home Premium Advanced at $200 annually or $20 monthly. Anthropic prices Claude Pro at $200 billed annually or $20 monthly. For a new customer choosing both annual subscriptions, $200 + $200 = $400. Buying the same two subscriptions monthly for a full year instead gives ($20 + $20) × 12 = $480, an $80 yearly difference. The lower total requires the annual commitments; it is not a monthly offer of the same flexibility.

That is a chosen stack, not Google’s minimum all-in tariff. The Home MCP guide requires an active Premium Advanced subscription and an MCP-compatible client, listing alternatives including Antigravity, Claude Cowork, and OpenClaw. It does not require every customer to buy Claude Pro. Someone who already pays for Pro faces only the additional Home subscription in this comparison, while another client can have different economics. Preserve those boundaries when presenting the cost to a household or customer.

What the payment enables is broader than natural-language light control. Google’s guide describes discovering homes and devices, inspecting current states, reading historical events, and issuing actions. Those capabilities could support troubleshooting and explanations that a simple switch does not provide. The value proposition should therefore be a particular problem—such as diagnosing an unreliable device—not a demonstration that another chatbot can repeat an existing voice command.

The setup also has a real engineering component. Google’s prerequisites include a Cloud project, API enablement, OAuth credentials, and a compatible client. That is developer work, not a consumer checkbox. Budget time for consent, credential handling, verification, and revocation. The retrieved pages do not provide a fixed implementation fee or a measured setup duration, so the subscription arithmetic deliberately excludes both rather than guessing a labor bill.

Availability is limited too. The Verge describes a US rollout over the coming weeks, and the official guide labels the service Early Access. A subscription purchase is therefore not proof that every account can use the integration immediately. Confirm access before buying devices for a promised demonstration. An early-access dependency belongs in the project schedule with a fallback, not in a sales commitment that assumes immediate universal availability.

The most important missing feature is stated plainly: the guide says creating and managing automations through Home MCP is not supported yet. Do not replace an established automation system on the strength of agent-control examples. An assistant that can issue an action now and a platform that can maintain a recurring household rule are different products. The latter still needs its own execution and reliability story.

Test the household, not the tool handshake

Start with a separate development home and low-consequence devices. Google explicitly recommends an additional home for testing as an alternative to connecting a shared household, and says other household members should be informed when an agent can access their home data and control devices. That is not decorative consent language. A person granting OAuth access may not be the only person affected by the resulting action or observation.

The safety boundary is also narrower than a blanket guarantee. Google says Home MCP enforces rate limits and prohibits sensitive actions such as unlocking doors, while warning that connected agents can still behave unexpectedly or undesirably. Keep consequential changes behind review and retain a manual control path. A server-side prohibition on one action does not establish that every permitted action is appropriate in every household context.

Use the Home MCP action reference to define what the client can request, then verify the resulting device state separately. A successful tool exchange is evidence that an interaction occurred, not sufficient evidence that the household’s intended outcome happened. For the pilot, record the request, reported result, observed state, and whether a person had to intervene. These are proposed acceptance criteria, not claims that Google has published a particular failure rate.

Google’s guide acknowledges occasional longer-than-expected latency and experimental traits that may not work as expected. Those caveats change the appropriate first workload. Retrospective analysis and supervised troubleshooting tolerate different delays from an action a person expects immediately. Keep existing controls for time-sensitive behavior until measured response times on the actual devices justify a change. No published latency guarantee in the retrieved guide supports treating the integration as a real-time control system.

The archive’s stateless MCP migration analysis distinguishes transport from application state. Home control makes that distinction physical. A reconnect, retry, or fluent explanation must not substitute for knowing the device’s current state. Builders should test interrupted requests and recovery in the development home, while avoiding assumptions that a protocol-level success guarantees a safe application-level retry.

The strongest case for adoption is useful diagnosis across device history and current state that saves the user repeated manual investigation. The strongest case against it is paying for another control layer that reproduces existing routines while adding credentials, latency, and supervision. The retrieved sources establish access and documented limitations, not measured household savings. Let the pilot resolve that uncertainty rather than inventing a payback period from the annual fee.

Today’s MLPerf lead makes the same distinction between accepted benchmark output and accepted work. Adopt Home MCP for a bounded, supervised use case when observed outcomes justify its subscription and maintenance costs. Expand only after consent, revocation, latency, and device-state checks work reliably. The $400 stack is easy to total; earning its place in a shared home is the harder calculation.

Sources