Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official

Get System Overview

ha_get_overview
Read-onlyIdempotent

Fetch a categorized Home Assistant system overview—version, location, entities, notifications, and repairs—with adjustable detail and domain filters for efficient AI analysis.

Instructions

Get AI-friendly system overview with intelligent categorization.

Returns comprehensive system information at the requested detail level, including Home Assistant base_url, version, location, timezone, entity overview, and active persistent notifications (if any). Use 'minimal' (default) for most queries. Domain counts and states_summary are always complete regardless of entity pagination. Standard/full modes paginate entities (default 200 per page) — use offset to fetch more. Use 'domains' filter to narrow scope.

Use fields= to project the response to only the keys you need — a significantly smaller payload when fetching a single sub-section (e.g. fields=["system_info"] returns just that section instead of the full overview).

When (and only when) the ha-mcp settings-UI sidecar is running (stdio mode, e.g. Claude Desktop / Claude Code), the response includes a settings_url field — the local URL to the tool-configuration page. Hand this URL to the user when they ask how to enable or disable tools or change server settings. settings_url is emitted regardless of fields= projection (so it stays discoverable even when callers minimize the response) but only when the sidecar URL file actually exists.

In standalone HTTP / Docker modes, when an HTTP settings prefix is advertised, there is no sidecar URL file and the server can't know its externally reachable host. The response instead carries a settings_url_hint string telling the user where the page is mounted and how to find or construct the full URL. Hand whichever of the two fields is present to the user.

The response also carries an ha_mcp_update object {current, latest, update_available} reporting whether a newer ha-mcp release is available (PyPI for pip/Docker, the Supervisor add-on store for the add-on) — proactively tell the user when update_available is true. Emitted regardless of fields=; omitted only for the unknown version and when HA_MCP_DISABLE_UPDATE_CHECK is set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax total entities across all domains (default: unlimited for minimal, 200 for standard/full). Counts and states always complete. Use with offset for pagination.
fieldsNoReturn only the specified top-level response keys to reduce response size (e.g. ["system_info", "domains"]). None = full response (default). Available keys: success, system_summary, domain_stats, area_analysis, ai_insights, pagination, partial, warnings, device_types, service_availability, system_info, notification_count, notifications, repair_count, dismissed_repair_count, repairs, repairs_error, tool_discovery, settings_url, settings_url_hint, read_only_mode, read_only_mode_hint, ha_mcp_update. Note: ``settings_url`` (stdio mode), ``settings_url_hint`` (standalone HTTP/Docker mode), the ``read_only_mode`` / ``read_only_mode_hint`` pair (only while Read Only Mode is on), and ``ha_mcp_update`` (when an update check applies) are emitted regardless of ``fields=`` projection so the settings page, the active mode, and a newer ha-mcp release stay discoverable; see the tool description.
offsetNoNumber of entities to skip for pagination (default: 0)
domainsNoFilter to specific domains (e.g. 'light,sensor' or ['light','sensor']). None = all domains. Useful to avoid context window overload.
detail_levelNo'minimal': 10 entities/domain, top-5 states (default); 'standard': 200 entities/page, top-10 states (use offset for more); 'full': 200 entities/page + entity_id + state + full states. Use 'domains', 'limit', or max_entities_per_domain to control sizeminimal
include_stateNoInclude state field for entities (None = auto based on level). Full defaults to True.
include_entity_idNoInclude entity_id field for entities (None = auto based on level). Full defaults to True.
include_notificationsNoInclude active persistent notifications (default: True). Set False to skip.
max_entities_per_domainNoOverride default entity cap per domain (minimal=10, standard/full=unlimited). 0 = no limit on entities or states.
include_dismissed_repairsNoInclude user-dismissed/ignored repairs (default: False). Matches the HA Repairs UI which hides dismissed items by default. To dismiss/ignore a repair, call ha_call_service with ws_command="repairs/ignore_issue" and data={"domain": ..., "issue_id": ..., "ignore": true}.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv8.4.1
    • changedInput schema / properties / fields / description
      Previous value: -"Return only the specified top-level response keys to reduce response size (e.g. [\"system_info\", \"domains\"]). None = full response (default). Available keys: success, system_summary, domain_stats, area_analysis, ai_insights, pagination, partial, warnings, device_types, service_availability, system_info, notification_count, notifications, repair_count, dismissed_repair_count, repairs, repairs_error, tool_discovery, settings_url, settings_url_hint, read_only_mode, read_only_mode_hint, ha_mcp_update. Note: ``settings_url`` (stdio mode), ``settings_url_hint`` (HTTP/Docker/OAuth mode), the ``read_only_mode`` / ``read_only_mode_hint`` pair (only while Read Only Mode is on), and ``ha_mcp_update`` (when an update check applies) are emitted regardless of ``fields=`` projection so the settings page, the active mode, and a newer ha-mcp release stay discoverable; see the tool description."New value: +"Return only the specified top-level response keys to reduce response size (e.g. [\"system_info\", \"domains\"]). None = full response (default). Available keys: success, system_summary, domain_stats, area_analysis, ai_insights, pagination, partial, warnings, device_types, service_availability, system_info, notification_count, notifications, repair_count, dismissed_repair_count, repairs, repairs_error, tool_discovery, settings_url, settings_url_hint, read_only_mode, read_only_mode_hint, ha_mcp_update. Note: ``settings_url`` (stdio mode), ``settings_url_hint`` (standalone HTTP/Docker mode), the ``read_only_mode`` / ``read_only_mode_hint`` pair (only while Read Only Mode is on), and ``ha_mcp_update`` (when an update check applies) are emitted regardless of ``fields=`` projection so the settings page, the active mode, and a newer ha-mcp release stay discoverable; see the tool description."
  2. First observedv7.14.2

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses non-obvious behaviors beyond annotations: settings_url only appears when the sidecar is running and is emitted regardless of fields= projection; settings_url_hint appears in HTTP/Docker modes; ha_mcp_update is omitted under unknown version or HA_MCP_DISABLE_UPDATE_CHECK; counts/states_summary are complete regardless of pagination. This is rich, actionable behavioral context that annotations alone do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence adds unique information, and it is front-loaded with the core purpose and default behavior before edge cases. The structure is coherent (main purpose, pagination, fields projection, settings_url, update object). It slightly overexplains settings_url variants, but the added detail is operationally relevant for the agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 10 optional parameters, an output schema, and complex conditional behavior. The description covers mode-dependent fields, override behavior, user handoff instructions, and update-check logic. The output schema covers return values, so the description reasonably focuses on conditions and side effects. Nothing needed for correct invocation appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter. The description adds context for fields= and detail_level and mentions offset/domains, but most parameter semantics are already in the schema. Baseline 3 applies; the description doesn't need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get'), a clear resource ('system overview'), and adds 'AI-friendly ... with intelligent categorization', which sets it apart from sibling getters like ha_get_system_health and ha_get_entity. It names the main contents (base_url, version, location, timezone, entity overview, notifications), so an agent can tell exactly what this tool returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is abundant: 'Use minimal (default) for most queries', 'Use fields= to project the response', 'Use domains filter to narrow scope', and 'Use with offset for pagination'. It also directs user-facing handling of settings_url and ha_mcp_update. This clearly tells the agent when and how to use the tool, including alternatives like pagination controls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/homeassistant-ai/ha-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server