Skip to main content
Glama

Get energy sum statistics for recent days

statistics_get_energy_statistics
Read-onlyIdempotent

Fetch summed energy statistics for all energy sensors over the last N days. Auto-discovers energy statistic IDs and returns consumption totals by day, week, or month.

Instructions

Get sum statistics for every energy-related sensor over the last N days.

Auto-discovers 'sum' statistic IDs via WS recorder/list_statistic_ids, keeps only those whose unit is an energy/volume unit (kWh, MWh, Wh, m³, ft³, L, gal — instantaneous power sensors in 'W' are excluded since a 'sum' statistic on a power sensor is not a meaningful energy value), then fetches sum/change via WS recorder/statistics_during_period for the requested window. This is a convenience wrapper around statistics_get_statistics.

Use when: a quick overview of overall energy consumption trends is needed without first listing statistic IDs by hand. Not for: a hand-picked set of statistic IDs or non-energy sensors — use statistics_get_statistics directly. Returns: {"days", "period", "statistic_count", "data": {statistic_id: {"unit": ..., "rows": [{"start": <date>, "change": ..., "sum": ...}, ...]}}}, or {"message": "..."} when no energy statistic IDs are found. Errors: {"error": "days must be between 1 and 365"} for an out-of-range days; {"error": "..."} when either WS call raises or returns an unexpected shape.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoNumber of days back from now to include, between 1 and 365.
periodNoAggregation bucket size passed to the underlying statistics query, e.g. 'day', 'week', 'month'.day

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.25.1
    • addedInput schema / properties / days / description
      Added value: +"Number of days back from now to include, between 1 and 365."
    • addedInput schema / properties / period / description
      Added value: +"Aggregation bucket size passed to the underlying statistics query, e.g. 'day', 'week', 'month'."
  2. Addedv0.18.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/safe profile, but the description goes much further: it names the two WS calls used, explains the unit-filtering logic (excludes 'W' power sensors and why), describes the wrapper relationship, and documents error conditions. This is rich behavioral context beyond annotations.

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 with purpose first, then mechanism, then use/not-for, returns, errors. Information-dense with no wasted sentences, though the parenthetical unit explanation is somewhat verbose and could be tightened.

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?

Complete for a 2-param read tool with output schema: description covers purpose, routing, mechanics, returns shape summary, and error cases. An agent can invoke it confidently without further discovery.

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 coverage is 100%, so baseline is 3. The description adds meaning by stating the error for out-of-range days, clarifying the window as 'last N days' from now, and explaining that period is passed to the underlying statistics query, which adds slight value over 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?

States a specific verb (Get sum statistics) and resource (energy-related sensors over last N days), and explicitly distinguishes itself from the sibling statistics_get_statistics by describing its auto-discovery mechanism and energy-only filter.

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?

Has explicit 'Use when' (quick overview of overall energy consumption trends without listing statistic IDs by hand) and 'Not for' (hand-picked statistic IDs or non-energy sensors — use statistics_get_statistics directly) sections. This is textbook routing guidance.

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