Skip to main content
Glama

Get aggregated statistics for a time range

statistics_get_statistics
Read-onlyIdempotent

Retrieve aggregated recorder statistics for specified IDs over a time range to analyze energy, temperature, or other trends across hours, days, weeks, or months.

Instructions

Get aggregated recorder statistics for one or more IDs over a time range.

Calls WS recorder/statistics_during_period with start/end parsed into UTC timestamps, converts each row's epoch start back to an ISO string, and rounds numeric aggregates to 4 decimals.

Use when: analysing energy/temperature/etc. trends over hours, days, weeks or months using the recorder's pre-aggregated data. Not for: raw short-term state changes between two points in time — use history_get_state_history instead. Returns: {"period", "start", "end", "types", "data": {statistic_id: [{"start": <iso>, "sum": ..., "mean": ..., ...}, ...]}}. Errors: {"error": "..."} for an empty statistic_ids, an invalid period/types value, an unparsable start/end, a non-dict WS response, or when the WS call raises.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoEnd of the range, same formats as `start`. Omit to use the current time.
startYesStart of the range: a date ('2024-01-01') or datetime ('2024-01-01T00:00:00').
typesNoWhich aggregates to include per bucket, any of 'sum', 'mean', 'min', 'max', 'state', 'change'. Omit to use ['sum', 'mean', 'min', 'max'].
periodNoAggregation bucket size: one of '5minute', 'hour', 'day', 'week', 'month'.day
statistic_idsYesEntity or statistic IDs to fetch, e.g. ['sensor.energy_consumption']. Discover valid values with `statistics_list_statistic_ids`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.25.1
    • changedInput schema / properties / end / description
      Previous value: -"end date/time (defaults to now)"New value: +"End of the range, same formats as `start`. Omit to use the current time."
    • changedInput schema / properties / period / description
      Previous value: -"aggregation period — \"hour\", \"day\", \"week\", \"month\", \"5minute\""New value: +"Aggregation bucket size: one of '5minute', 'hour', 'day', 'week', 'month'."
    • changedInput schema / properties / start / description
      Previous value: -"start date/time, e.g. \"2024-01-01\" or \"2024-01-01T00:00:00\""New value: +"Start of the range: a date ('2024-01-01') or datetime ('2024-01-01T00:00:00')."
    • changedInput schema / properties / statistic_ids / description
      Previous value: -"list of entity IDs or statistic IDs, e.g. [\"sensor.energy_consumption\"]"New value: +"Entity or statistic IDs to fetch, e.g. ['sensor.energy_consumption']. Discover valid values with `statistics_list_statistic_ids`."
    • changedInput schema / properties / types / description
      Previous value: -"which aggregates to return — any of [\"sum\", \"mean\", \"min\", \"max\", \"state\", \"change\"]\n    defaults to [\"sum\", \"mean\", \"min\", \"max\"]"New value: +"Which aggregates to include per bucket, any of 'sum', 'mean', 'min', 'max', 'state', 'change'. Omit to use ['sum', 'mean', 'min', 'max']."
  2. Addedv0.18.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond them: it reveals the WS call made, that start/end are parsed to UTC, that epoch starts are converted to ISO, that numeric aggregates are rounded to 4 decimals, and it enumerates error conditions. The Returns block partially duplicates the output schema, which keeps this just below a 5.

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?

Well front-loaded: purpose first, then use/not-for routing, then return and error contract. Every line is scannable and earns its place, though the Returns paragraph overlaps the output schema and costs a little efficiency.

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?

For a 5-parameter read tool with full schema coverage and an output schema, this is complete: it covers purpose, routing, defaults, output transformation, and a full error taxonomy, leaving nothing an agent needs to call it correctly unstated.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description goes further by explaining cross-cutting parameter behavior (start/end parsed into UTC timestamps) and the rounding applied to results, adding meaning the schema does not carry.

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?

States a specific verb (get) and resource (aggregated recorder statistics) plus the scope (one or more IDs over a time range). It names the exact upstream WS command and distinguishes itself from history_get_state_history and statistics_list_statistic_ids, so an agent can route without opening sibling schemas.

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?

Contains an explicit 'Use when' clause (trend analysis over hours/days/weeks/months using pre-aggregated data) and an explicit 'Not for' clause that names the alternative tool (history_get_state_history) and the condition that selects it (raw short-term state changes).

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