Skip to main content
📖 The AI Tool Bible

Home Assistant MCP vs MCP Everything Server

A side-by-side look at pricing, capabilities, pros, cons, and our editorial scores.

 Home Assistant MCP logo
Home Assistant MCP
MCP Servers
MCP Everything Server logo
MCP Everything Server
MCP Servers
TaglineOpen-source MCP server that lets any LLM control and observe a Home Assistant smart home in real time.The kitchen-sink reference MCP server that exercises every corner of the Model Context Protocol
CategoryMCP ServersMCP Servers
PricingFree· Free and open source (Apache 2.0). Self-hosted; only cost is your own Home Assistant instance and the LLM client you connect to it.Free· Free and open source (MIT License). No cloud service or paid tier — you run it locally via npx, Docker, or your MCP client of choice.
Model——
Editorial score——
Use cases
Conversational smart-home control from Claude Desktop or CursorLLM-driven Home Assistant automationsReal-time device state monitoring via SSEVoice-agent frontends that call HA servicesBulk add-on and HACS package management through chatPrototyping custom home-lab AI assistantsNatural-language climate and lighting scenesCamera snapshot and motion event triaging
MCP client conformance testingRegression testing of stdio and Streamable HTTP transportsVerifying sampling round-trip behavior in a new agent hostDebugging elicitation UI in an IDE integrationReference reading for authoring a new MCP serverDemoing MCP primitives in workshops and talksSmoke-testing cancellation and progress-notification handlingValidating resource-subscription update delivery
Pros
  • Broad domain coverage — lights, climate, covers, media, locks, vacuums, cameras, and more mapped to MCP tools out of the box
  • Real-time SSE subscriptions let an LLM react to state changes and automation triggers, not just poll
  • Docker Compose setup and clear env-var config make it easy to run alongside an existing Home Assistant install
  • Exposes system-level surfaces most HA wrappers skip: add-on management, HACS package installs, automation CRUD
  • Token auth plus rate limiting on the bridge, so it isn't a trivially open control plane
  • Apache 2.0 licensed, TypeScript, 500+ GitHub stars and active commits — reasonable community traction for an MCP project
  • Only server that exercises the full MCP feature matrix in one place — tools, resources, prompts, sampling, elicitation, roots, logging, subscriptions, and Tasks
  • Maintained by the Model Context Protocol project itself, so behavior tracks the spec as it evolves (SEP-1686 Tasks, Streamable HTTP, etc.)
  • Runs anywhere an MCP client runs — npx, Docker, Claude Desktop, VS Code, Cursor, Windsurf — with stdio or HTTP transports
  • TypeScript source is short and readable, making it a de-facto reference for how each handler should be shaped
  • MIT-licensed, no telemetry, no signup, no cloud dependency
  • Includes progress notifications and cancellation flows that most tutorial servers skip, so client cancel/timeout logic can be exercised properly
Cons
  • Requires a working Home Assistant instance and long-lived access token — not useful without one
  • Self-hosted only; you own the reverse-proxy, TLS, and network exposure decisions
  • Model-agnostic by design, so quality of device control depends heavily on which LLM client you attach
  • Single-maintainer community project — issue triage and roadmap can be slower than vendor MCP servers
  • Broad tool surface can flood an LLM's context window if you don't scope subscriptions to specific domains
  • Explicitly not useful for end users — it does not do anything a human would actually want done
  • Feature drift means some primitives (SEP-1686 Tasks, elicitation) may not yet be implemented in every client, producing red herrings during testing
  • Documentation is a single features.md; there is no guided tour that maps each tool to the spec section it exercises
  • TypeScript-only reference — Python or Rust client authors have to translate patterns themselves
  • Sampling and elicitation flows depend on the client honoring them, so a silent client makes it hard to tell whether the server or the client is at fault
Websitegithub.comgithub.com
Pick Home Assistant MCP if
  • ✅ Broad domain coverage — lights, climate, covers, media, locks, vacuums, cameras, and more mapped to MCP tools out of the box
  • ✅ Real-time SSE subscriptions let an LLM react to state changes and automation triggers, not just poll
  • ✅ Docker Compose setup and clear env-var config make it easy to run alongside an existing Home Assistant install
  • ✅ Exposes system-level surfaces most HA wrappers skip: add-on management, HACS package installs, automation CRUD
Pick MCP Everything Server if
  • ✅ Only server that exercises the full MCP feature matrix in one place — tools, resources, prompts, sampling, elicitation, roots, logging, subscriptions, and Tasks
  • ✅ Maintained by the Model Context Protocol project itself, so behavior tracks the spec as it evolves (SEP-1686 Tasks, Streamable HTTP, etc.)
  • ✅ Runs anywhere an MCP client runs — npx, Docker, Claude Desktop, VS Code, Cursor, Windsurf — with stdio or HTTP transports
  • ✅ TypeScript source is short and readable, making it a de-facto reference for how each handler should be shaped