Most attempts to put a language model in charge of a house have failed in the same way. The model can talk about the house convincingly and cannot reliably do anything to it, because every integration was a bespoke lump of glue between one assistant and one system.
The Model Context Protocol is a standard way to close that gap: a common interface through which a model discovers what tools exist, what arguments they take, and what they return. Write the server once and any MCP-capable assistant can use it.
Why this matters here specifically
Home automation is unusually well suited to it. A house is already a collection of discrete, describable actions — set a light level, arm the alarm, check a door state, run a scene, read a temperature. That is almost exactly the shape of a tool definition.
What MCP adds is that the assistant is no longer guessing. It is handed a description of what is available and what each thing does. The failure mode shifts from "the model hallucinated a device that does not exist" to "the model called a real tool with real arguments and got a real answer".
What becomes possible
Questions nobody wrote a rule for. "Which rooms were coldest last week?" is not a dashboard anyone built. With tools for reading history and computing over it, it is answerable without a developer.
Actions expressed as intent. "We're having eight people over on Saturday evening" is not a scene. It is heating in rooms usually set back, lighting in the dining room, music zones grouped, the guest network's password rotated. A model with tools can compose that from parts.
Diagnostics in plain language. "Why did the hall light come on at 3am?" is a question that currently means reading logs. With tools exposing the event history, it becomes a question with an answer.
Genuine cross-system reasoning. The lighting system does not know what the calendar says. The calendar does not know what the heating is doing. A model with tools for both can act on the combination, which is exactly the layer that was always missing.
Where the caution belongs
Permissioning is the whole game. A tool that dims a lamp and a tool that unlocks the front door are the same shape and emphatically not the same risk. Read and write must be separated, anything touching locks, alarms or gates should require explicit confirmation, and the boundary should be enforced by the MCP server — not by asking the model nicely in a prompt.
Prompt injection is a live concern, not a theoretical one. If an assistant reads a calendar entry, an email or a device name, that text arrives from outside and may contain instructions. Guest-supplied text and device metadata are both routes in. Anything with physical consequences needs to sit behind a human decision.
Local, again. An assistant that can operate a house is only worth it if the house still operates when the line drops — and the model does not need somebody else's server to learn your routine. Local models are now good enough for this class of task.
Latency is real. A model deciding what to do takes noticeably longer than a keypad. Voice and conversation are where it belongs; the light switch by the door should remain a light switch by the door.
Where we are with it
We regard this as genuinely promising and still early. It solves a real structural problem — every assistant needing bespoke glue for every system — and it does so in a way that is well matched to how automation is already modelled.
We are building on it where a house has a clear use for conversational control, always with reads and writes separated and anything consequential gated behind confirmation. We are not putting it in front of a lock.
The useful framing is that MCP is plumbing, not intelligence. It does not make an assistant understand your house. It gives it an honest, bounded description of what the house can do, and a way to do it that can be logged, permissioned and revoked. That is the part that was missing.