Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official

Manage Energy Dashboard Preferences

ha_manage_energy_prefs
Destructive

Read, update, add, or remove Home Assistant Energy Dashboard preferences (grid, solar, battery, gas, water, device consumption, tariffs). This tool provides the sole access to this otherwise inaccessible configuration.

Instructions

Manage the Home Assistant Energy Dashboard preferences.

The Energy Dashboard configuration (grid/solar/battery/gas/water energy sources, individual device consumption sensors for electricity and water, cost tariffs) is stored in .storage/energy and not otherwise reachable via REST, services, or helper flows — this tool is the only way for agents to inspect or modify it.

WHEN TO USE:

  • mode='get' / 'set': inspect or replace the full Energy Dashboard config. Use 'set' for bulk edits or anything touching multiple top-level keys at once.

  • mode='add_device' / 'remove_device': add or remove a single device-consumption entry. The tool performs a fresh read-modify-write internally; the caller does NOT manage config_hash. Use water=True to target the water meter list instead of electricity.

  • mode='add_source': append a single entry to energy_sources (grid, solar, battery, gas, or water). Same atomic read-modify-write semantics.

WHEN NOT TO USE:

  • To create the underlying statistics themselves — they must already exist as HA entities before being referenced here; create them via the relevant integration's config flow first.

CAVEATS:

  • energy/save_prefs has per-key FULL-REPLACE semantics. Passing {"device_consumption": [<one entry>]} deletes every other device the user had configured — silently, with no error. mode='set' requires a fresh config_hash for optimistic locking; convenience modes hide this entirely.

  • config_hash accepts both a single str (full-blob lock) and a dict[_PrefsKey, str] keyed by top-level keys (per-key lock, taken from the config_hash_per_key field of the mode='get' response). The per-key form lets an agent submit only the top- level key it wants to change — set-equality between config keys and dict keys is enforced, and any key outside the canonical set (typo, etc.) on either side is rejected with VALIDATION_FAILED rather than silently dropped (so an empty submission cannot succeed as a no-op). A per-key submission still fully replaces that key's value as the save endpoint requires. Mismatch on any locked key returns RESOURCE_LOCKED with the offending keys in the response's top-level mismatched_keys (create_error_response flattens the context dict onto the response root).

  • dry_run=True skips the hash check entirely for both forms; the per-key form is therefore silently accepted on dry runs even if its keys would mismatch the current state.

  • A local shape check runs before every write; malformed payloads are rejected with a shape_errors list.

  • After a successful write, the tool calls energy/validate and returns any residual issues as post_save_validation_errors in the response. These reflect semantic problems (missing stats, unit mismatches) that shape checks can't catch; the save persists regardless — correct the config and write again if needed.

  • The underlying save endpoint is admin-only. Non-admin tokens will receive an authorization error from Home Assistant.

  • Convenience modes are NOT idempotent: 'add_device' on an existing stat_consumption returns RESOURCE_ALREADY_EXISTS; 'remove_device' on a missing entry returns RESOURCE_NOT_FOUND. 'add_source' rejects duplicates by (type, stat_energy_from) for solar/battery/gas/water (RESOURCE_ALREADY_EXISTS); grid entries are appended without a duplicate check (multiple grid variants are legitimate, and grid has no single canonical uniqueness key) — the caller is responsible for de-duplicating grid sources.

  • Convenience modes do NOT bypass the local shape check on dry_run: dry_run=True still raises RESOURCE_ALREADY_EXISTS (duplicate add_device / add_source), RESOURCE_NOT_FOUND (missing remove_device), or VALIDATION_FAILED (post-mutator shape error) when the proposed mutation is not applicable. The mutator and shape check both run before the dry-run short-circuit.

read get inspect energy dashboard preferences prefs electricity price prices pricing tariff tariffs rate rates cost costs kwh peak off-peak offpeak contract utility bill grid solar battery gas water consumption number_energy_price entity_energy_price stat_energy_from

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYesOperation mode. Primitives: 'get' reads the current prefs; 'set' writes a full prefs payload (per-top-level-key full-replace). Convenience modes: 'add_device' / 'remove_device' / 'add_source' perform a single read-modify-write atomically — no config_hash from the caller, the tool fetches it fresh internally.
nameNoOptional display name for mode='add_device'. Only used when adding a new device entry; ignored otherwise.
waterNoIf True, mode='add_device' / 'remove_device' targets 'device_consumption_water' instead of 'device_consumption'. Default False.
configNoFull prefs payload for mode='set'. Must contain the top-level keys you intend to replace: 'energy_sources', 'device_consumption', 'device_consumption_water'. Any top-level key present in this payload REPLACES the existing list entirely; any omitted key is preserved. Call with mode='get' first, mutate the returned config, then pass the whole object back. Ignored by convenience modes.
sourceNoSingle energy_sources entry for mode='add_source'. Must contain 'type' (one of grid|solar|battery|gas|water) and the type-specific required fields (e.g. solar/battery/gas/water require 'stat_energy_from'). Every source type also accepts an optional 'name' (display label in the energy graphs); battery additionally accepts 'stat_soc' (state-of-charge statistic). Note: HA Core's voluptuous schema for grid sources requires the full field set (cost_adjustment_day, stat_energy_to, stat_cost, entity_energy_price, number_energy_price, entity_energy_price_export, number_energy_price_export, stat_compensation) — the local shape check is narrower, so a minimal {'type': 'grid'} passes locally but surfaces in post_save_validation_errors after writing. Pass the unused fields as None to satisfy the server. Required for mode='add_source'; ignored otherwise.
dry_runNoIf True, no write is performed. For mode='set': runs a local shape check on the proposed config AND calls the server's energy/validate against the CURRENT persisted state (Home Assistant's validate endpoint cannot validate an unsubmitted payload). For convenience modes: simulates the mutation against a fresh read and reports what would change without writing — but still raises RESOURCE_ALREADY_EXISTS (duplicate add_device, or duplicate add_source for solar/battery/gas/water), RESOURCE_NOT_FOUND (missing remove_device), or VALIDATION_FAILED (post-mutator shape error) when the proposed mutation is not applicable. Default False.
config_hashNoHash from a previous mode='get' call. REQUIRED for mode='set' unless dry_run=True. Two forms: str (full-blob lock) or dict (per-key lock, taken from the config_hash_per_key field of mode='get'). Pass the dict form as a native object, NOT a JSON-encoded string — a stringified dict is treated as a full-blob token and will report RESOURCE_LOCKED; clients that can only send strings should use the str full-blob form. See the tool docstring for fail-closed semantics. Ignored by convenience modes.
included_in_statNoOptional 'parent' statistic for mode='add_device'. Set this to a statistic that already INCLUDES this device's consumption (e.g., a whole-home or circuit-level meter that this device feeds into). The Energy Dashboard will subtract this device's reading from the parent so the parent's contribution is not double-counted. Ignored otherwise.
stat_consumptionNoStatistic entity_id for mode='add_device' / 'remove_device' (e.g. 'sensor.fridge_energy'). Required for those modes; ignored otherwise.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. First observedv7.14.2

TDQS

A4.9/5.0
Behavior5/5

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

Extremely rich disclosure beyond the annotations: per-key FULL-REPLACE semantics with silent deletion of other devices, config_hash locking forms and fail-closed behavior, dry_run skipping the hash check, non-idempotency of convenience modes (RESOURCE_ALREADY_EXISTS/RESOURCE_NOT_FOUND), local shape checks, post-save validation persisting regardless of errors, and admin-only auth. All of this aligns with destructiveHint=true and idempotentHint=false with no contradiction.

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 earns its length given the tool's complexity (5 modes, locking, validation, dry-run edge cases). It is well-structured with clear headers and front-loaded purpose. The trailing keyword list adds noise for a human reader, though it likely serves retrieval indexing; a slightly stronger edit would trim it.

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 highly complex tool, nothing an agent needs to call it correctly is missing: mode selection, locking semantics, error conditions, prerequisites (statistics must pre-exist), auth requirements, and post-write validation behavior are all covered. Since an output schema exists, the description correctly avoids re-explaining return values and even references response fields like mismatched_keys where relevant.

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?

Despite 100% schema coverage (baseline 3), the description adds substantial meaning beyond the schema: the stringified-dict config_hash gotcha ('a stringified dict is treated as a full-blob token and will report RESOURCE_LOCKED'), the HA Core voluptuous full-field requirement for grid sources, the double-counting semantics of included_in_stat, and dry_run's unusual behavior of still raising validation errors. The schema describes what parameters are; the description explains how they behave.

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 first line names a specific verb and resource ('Manage the Home Assistant Energy Dashboard preferences') and immediately enumerates what those preferences are: grid/solar/battery/gas/water sources, device consumption sensors, and cost tariffs. It further distinguishes the tool by stating it is 'the only way for agents to inspect or modify' this config, which is not reachable via REST, services, or helper flows.

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 WHEN TO USE and WHEN NOT TO USE sections map each mode to its intended scenario ('Use 'set' for bulk edits...', 'mode='add_device' / 'remove_device': add or remove a single device-consumption entry'). The exclusion is concrete: the tool must not be used to create statistics, which should be created 'via the relevant integration's config flow first'. The claim that this is the only path to the energy config implicitly differentiates it from all dashboard-related siblings.

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