Smart home MCP servers compared: local and cloud options
Published October 28, 2026 · By Port OS Team · Drafted with AI
Choose a smart home MCP server around the devices you have and the system you want to maintain. A hosted provider connection, a Home Assistant server and a tool for one device brand solve different problems.
For a hosted connection to supported provider accounts, consider Port OS. If your devices already live in Home Assistant, start with its official MCP server. If your goal is changing Home Assistant configuration with an agent, inspect a community administration toolkit separately. Google Home MCP and Shelly-specific projects have their own account and device boundaries.
What this comparison covers
Port OS publishes this article and operates one of the services compared. This is a documentation-based comparison checked on October 28, 2026, not a head-to-head hardware benchmark. We did not test every service with physical devices, measure response times or rank implementations by popularity.
The sources linked below describe each project's current scope. Availability and requirements can change; confirm them before connecting your home.
| Approach | Where it runs | Main fit | Setup and access to check |
|---|---|---|---|
| Port OS | Hosted Port OS cloud service | Supported device-provider accounts without running a Home Assistant instance | Port OS account, supported provider connection and an authorized remote MCP client; alpha availability |
| Home Assistant MCP Server | Your Home Assistant instance | Giving an AI agent access to an existing Home Assistant setup | Configured LLM API, account permissions and connectivity from the agent |
| Community ha-mcp | An additional community server connected to Home Assistant | Agent-assisted configuration and administration | Installation, credentials and broad management-tool access; separate from the official integration |
| Google Home MCP | Google's hosted service | Devices and home data accessible through Google Home | Early Access approval, a Google Cloud project, OAuth and Google Home Premium Advanced, as listed in Google's guide |
| Shelly Cloud MCP project | A server process you run, using Shelly Cloud | Supported Shelly devices in a cloud account | Node.js, Shelly Cloud API access and an authorization key; this example is a community project |
1. Port OS: a hosted route to supported providers
Port OS connects an MCP-compatible assistant to supported device-provider accounts. Current alpha examples include Philips Hue lights, Sonos speakers and supported Roborock vacuums. The assistant discovers the controls returned for each device rather than assuming every model supports the same actions.
Choose it if you want the provider connections hosted for you and its available integrations cover your devices. You still depend on Port OS, internet connectivity and the relevant provider services. It is not a local-only home controller, and a listing in the waitlist catalog is not a working integration.
Start with the smart home MCP overview and device catalog. Port OS is in alpha; confirm current availability and costs with the service. Assistant and manufacturer subscriptions are separate.
2. Home Assistant's official MCP server: use your existing home platform
The official server integration exposes tools from the configured Home Assistant LLM APIs and uses OAuth with PKCE. A cloud-hosted agent needs a way to reach the Home Assistant instance. Check the integration's current API-selection and account settings instead of assuming a fixed tool list.
Home Assistant installation options let you choose how to run the home platform. You own that installation and its ongoing maintenance. Home Assistant Cloud offers a managed remote-access option; it is a separate service to evaluate alongside hardware, hosting and assistant costs.
This is a natural starting point when Home Assistant already has the devices you want to use. The Port OS versus Home Assistant comparison walks through that decision in more detail.
3. Community ha-mcp: inspect the administration scope
The ha-mcp project describes tools for editing automations, scripts and dashboards as well as device interaction. It is a community project, not Home Assistant's built-in MCP server. Installation and credential management add another component to maintain.
Consider this category when administration is the task. Review the actual tools and access you are granting. Do not assume that a comparison table in a community README still describes the official server accurately; check both projects' current documentation.
4. Google Home MCP: check eligibility before planning the setup
Google's Home MCP guide describes discovering homes and devices, reading state, requesting actions and accessing history. At this review it is labeled Early Access and lists approval, Cloud/OAuth setup and a Premium Advanced subscription among the requirements.
Confirm eligibility and device coverage first. Google Home MCP is distinct from Google's Developer MCP documentation tools. Port OS's Google Nest integration also does not imply that Port OS connects every device in Google Home.
5. Shelly-specific servers: match cloud or local access deliberately
The Shelly Cloud project used here documents device listing, light/switch controls and status reads through a Shelly Cloud account. You run its server and supply the cloud authorization key. It is not an example of local-only control.
For another Shelly server, check whether it talks directly to devices or through the cloud, which generations it supports, and whether it can control devices or only read energy data. “Shelly MCP” is a category, not a single compatibility promise. Port OS's Shelly integration is currently waitlist, so it is not an immediate substitute for a working Shelly server.
How to evaluate your shortlist
Use the same small task for each approach you are considering:
- Confirm that your exact device model and account are supported.
- Connect the client and inspect what access it receives.
- Find one named device and request a current state reading.
- Ask for one reversible action that the device exposes, then check fresh state and observe the device.
- Revoke the client's access and verify that a new request is denied.
Keep request acceptance separate from physical completion. Record stale or missing state as unknown. A simulator is useful for learning a tool flow, but it does not establish a vendor connection or hardware result.
Choose the option that fits your device coverage, maintenance preference and access requirements. If that is a hosted provider connection, see the Port OS setup path. If it is an existing Home Assistant installation, begin with the official server before adding another layer.