Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official

Get Entity History or Statistics

ha_get_history
Read-onlyIdempotent

Retrieve past Home Assistant entity states or aggregated statistics to troubleshoot changes, analyze event sequences, and track long-term trends.

Instructions

Get 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. Administrators can optionally enable recorder workload guardrails in Advanced settings. When enabled, oversized entity/time workloads are rejected before the recorder query is issued; narrow the time range or entity list to stay within the budget. Calendar statistics may first read HA's configured timezone so the estimate follows local calendar boundaries.

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="3d", 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv7.14.2

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable behavioral context beyond that: data retention differences, client-side limit/offset slicing ('All data is fetched from HA before slicing'), per-entity pagination behavior, the has_more/next_offset pattern, optional recorder workload guardrails, and timezone considerations for calendar statistics. No annotation contradiction exists.

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 long but tightly organized with headers, bullet lists, and code examples that each carry information. It front-loads the core purpose and source distinction, then progressively adds usage guidance, warnings, and examples. For a 12-parameter tool with two modes, the length is appropriate and nothing is redundant.

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, the description covers all essential decision points: which source to choose, default time ranges, pagination mechanics, source-specific parameters, and operational warnings. Since an output schema exists, return-value details are not required, and the description still mentions response keys and pagination fields via the fields parameter.

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?

Even though schema description coverage is 100%, the description adds meaningful semantics: it groups parameters into Shared/History/Statistics, explains defaults ('24h for history, 30 days for statistics'), provides relative time examples, and clarifies limit/offset are per-entity rather than global. The code examples further map parameters to real usage patterns.

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 opens with a specific verb and resource: 'Get historical data from Home Assistant's recorder.' It then clearly distinguishes the two operational modes, 'history' (raw state changes) and 'statistics' (pre-aggregated data), so an agent understands exactly what the tool returns. This is well differentiated from current-state tools like ha_get_state by emphasizing historical/recorder data.

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 with concrete scenarios: 'Use ha_get_history (default) when: Troubleshooting why a value changed...' and 'Use ha_get_history(source="statistics") when: Tracking long-term trends beyond 10 days...'. It also gives exclusions, such as statistics requiring state_class and offset > 0 requiring a single entity_id, making selection unambiguous.

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

Deploy Server

Other Tools