Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official

Get Entity History or Statistics

ha_get_history
Read-onlyIdempotent

Retrieve raw state changes or pre-aggregated statistics from Home Assistant to analyze past events and track long-term trends.

Instructions

Retrieve historical data from Home Assistant's recorder.

Sources:

  • "history" (default): Raw state changes, ~10 day retention, full resolution

  • "statistics": Pre-aggregated data, permanent retention, requires state_class

Shared params: entity_ids, start_time, end_time, limit, offset History params: minimal_response, significant_changes_only Statistics params: period, statistic_types

Default time range: 24h for history, 30 days for statistics

Use ha_get_history (default) when:

  • Troubleshooting why a value changed ("Why was my bedroom cold last night?")

  • Checking event sequences ("Did my garage door open while I was away?")

  • Analyzing recent patterns ("What time does motion usually trigger?")

Use ha_get_history(source="statistics") when:

  • Tracking long-term trends beyond 10 days ("Energy use this month vs last month?")

  • Computing period averages ("Average living room temperature over 6 months?")

  • Entities must have state_class (measurement, total, total_increasing)

WARNING: limit and offset apply per entity (not globally across all entities). All data is fetched from HA before slicing; limit/offset are client-side. With multiple entity_ids, offset must be 0 — use a single entity_id for offset > 0. Use has_more and next_offset from the response to paginate.

Example -- history (default):

ha_get_history(entity_ids="sensor.bedroom_temperature", start_time="24h")
ha_get_history(entity_ids=["sensor.temperature", "sensor.humidity"], start_time="7d", limit=500)
# Default order="desc" returns newest states first.
# To paginate oldest-first, use order="asc":
ha_get_history(entity_ids="sensor.temperature", start_time="7d", limit=100, offset=100, order="asc")

Example -- statistics:

ha_get_history(source="statistics", entity_ids="sensor.total_energy_kwh", start_time="30d", period="day")
ha_get_history(source="statistics", entity_ids="sensor.living_room_temperature",
               start_time="6m", period="month", statistic_types=["mean", "min", "max"])
ha_get_history(source="statistics", entity_ids="sensor.energy_kwh",
               start_time="30d", period="5minute", limit=100, offset=200)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax entries per entity. Default: 100, Max: 1000. For source="history": state changes. For source="statistics": aggregated rows. With multiple entity_ids, offset must be 0 and total rows returned can reach limit × len(entity_ids).
orderNoSort order for history entries. "desc" (default): newest first. "asc": oldest first (chronological, as returned by HA API). Ignored when source="statistics".desc
fieldsNoReturn only the specified top-level response keys to reduce response size. None = full response (default). History keys: success, source, entities, period, query_params. Statistics keys: success, source, entities, period_type, time_range, statistic_types, query_params, warnings.
offsetNoNumber of entries to skip per entity for pagination. Default: 0. Offset > 0 requires a single entity_id. Use with limit and has_more/next_offset in the response.
periodNoAggregation period: "5minute", "hour", "day", "week", "month", "year". Default: "day". Ignored when source="history"day
sourceNoData source: "history" (default) for raw state changes (~10 day retention), or "statistics" for pre-aggregated long-term data (permanent, requires state_class).history
end_timeNoEnd time: ISO datetime. Default: now
entity_idsYesEntity ID(s) to query. Can be a single ID, comma-separated string, or JSON array.
start_timeNoStart time: ISO datetime or relative (e.g., '24h', '7d', '30d'). Default: 24h ago for history, 30d ago for statistics
statistic_typesNoStatistics types: "mean", "min", "max", "sum", "state", "change". Default: all. Ignored when source="history"
minimal_responseNoReturn only states/timestamps without attributes. Default: true. Ignored when source="statistics"
significant_changes_onlyNoFilter to significant state changes only. Default: true. Ignored when source="statistics"

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, but the description adds significant behavioral context: data retention durations (10 days for history, permanent for statistics), client-side slicing of limit/offset, per-entity application of pagination, and the fact that order is ignored for statistics. This goes well beyond the annotations to fully disclose tool behavior.

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

Conciseness5/5

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

The description is well-structured with sections for sources, shared/history/statistics params, warnings, and examples. It is front-loaded with the core purpose, uses bullet points for readability, and every sentence provides useful information. Despite its length, it is concise and avoids redundancy.

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?

Given the tool's complexity (two data sources, pagination, multiple parameter interactions), the description covers all essential aspects: default time ranges, offset limitations, client-side slicing, order behavior, and examples for both modes. With an output schema present, no further detail on return values is needed. The description is fully complete for agent decision-making.

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

Parameters5/5

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

Although the input schema already has 100% description coverage, the description adds substantial meaning by explaining parameter behavior across sources, providing defaults, and offering examples that illustrate parameter combinations. It clarifies interactions like limit and offset per entity, and which parameters are ignored in each mode, adding value beyond the schema.

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 clearly states the tool retrieves historical data from Home Assistant's recorder, specifying two distinct sources ('history' and 'statistics') and their use cases. This distinguishes it from sibling tools like ha_get_state or ha_get_entity, which handle current state or entity configuration. The purpose is specific and actionable.

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?

The description provides explicit when-to-use guidance for each source, with concrete examples like 'Troubleshooting why a value changed' for history and 'Tracking long-term trends beyond 10 days' for statistics. It also includes warnings about limit/offset behavior, offset constraints with multiple entities, and pagination hints, making it clear when and how to use the tool correctly.

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