Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official

Create or Update Helper

ha_config_set_helper
Destructive

Create or update Home Assistant helper entities and config subentries across 30 types with a single unified interface, covering simple helpers, flow-based helpers, and integration subentries.

Instructions

Create or update Home Assistant helper entities and config subentries (30 types, unified interface).

MUST call ha_get_skill_guide OR refer to your locally installed skills first.

SIMPLE/FLOW helper create requires name; SIMPLE/FLOW helper update requires helper_id. Config subentry create requires entry_id and subentry_type; config subentry update also requires subentry_id.

SIMPLE types (structured params, WebSocket API): input_boolean, input_button, input_select, input_number, input_text, input_datetime, counter, timer, schedule, zone, person, tag.

FLOW types (pass config dict, Config Entry Flow API): template, group, utility_meter, derivative, min_max, threshold, integration, statistics, trend, random, filter, tod, generic_thermostat, switch_as_x, generic_hygrostat, history_stats, mold_indicator. Note: tod is the purpose-built "is-current-time-in-range" indicator (supports cross-midnight ranges, unlike schedule). Note: otp is a helper in the HA UI but is not offered here — its flow requires a live TOTP code. Create it with ha_set_integration(domain="otp"), as with any other helper-domain flow outside this list.

CONFIG_SUBENTRY type (Config Subentry Flow API): config_subentry. Pass entry_id, subentry_type, and config. Pass subentry_id to reconfigure an existing subentry; omit it to create a new subentry.

For flow-type updates, pass the existing entry_id as helper_id. Options flows reject the name key on update — to rename a flow helper, delete and recreate.

Behavior notes:

  • UPDATE preserves type-specific fields not re-passed (rename never wipes initial/icon/etc. for any simple helper). Flow-helper and config subentry updates behave the same way: a field omitted from config keeps its current value, and a field set to null is cleared where the schema allows that field to be empty.

  • Pass action="create" or action="update" to disambiguate intent. For SIMPLE/FLOW helpers, omitted action falls back to the implicit helper_id-presence discriminator. For config subentries, omitted action falls back to the subentry_id-presence discriminator.

  • For flow-based helpers, config keys not declared by any step's data_schema are silently ignored by HA; submit once and the validation error returns the data_schema for that helper so subsequent calls use the correct field names.

  • Validation errors raised by this tool carry the helper's data_schema in the response context (and menu_options for menu-rooted helpers like template/group when no sub-type is chosen yet) so a follow-up call can self-correct without a separate schema-discovery round-trip.

  • Flows that present more than one menu (e.g. an MQTT device subentry reconfigure looping through its summary menu) take next_step_id as a LIST of successive selections, consumed one per menu encounter.

EXAMPLES (menu-based types + tod, where first-call payload is non-obvious):

  • template sensor: ha_config_set_helper(helper_type="template", name="Room Temp", config={"next_step_id": "sensor", "state": "{{ states('sensor.x')|float }}", "unit_of_measurement": "°C"})

  • group (light): ha_config_set_helper(helper_type="group", name="Kitchen Lights", config={"group_type": "light", "entities": ["light.a", "light.b"]})

  • tod (time-of-day indicator, cross-midnight OK): ha_config_set_helper(helper_type="tod", name="Quiet Hours", config={"after_time": "22:00:00", "before_time": "07:00:00"})

  • config subentry (create under an existing integration): ha_config_set_helper(helper_type="config_subentry", entry_id="01HXYZ...", subentry_type="conversation", config={"name": "Local agent", "model": "gemma3:27b"})

helper-selection.md ships in this response under skill_content by default — decision matrix for picking the right helper type plus worked examples and per-type field tables. For deeper helper-design guidance beyond what ships here, call ha_get_skill_guide.

create update new add helper input_boolean input_button input_number input_text input_datetime input_select counter timer schedule zone person tag template group utility_meter derivative min_max threshold integration statistics trend random filter tod generic_thermostat switch_as_x generic_hygrostat history_stats mold_indicator

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
iconNoMaterial Design Icon (e.g., 'mdi:bell', 'mdi:toggle-switch')
modeNoDisplay mode: 'box'/'slider' for input_number, 'text'/'password' for input_text
nameNoDisplay name for simple/flow helper creation. Required when creating a helper without helper_id. Optional on helper update. Ignored for helper_type='config_subentry', which uses entry_id/subentry_type/subentry_id instead. For flow-based helper updates (template, group, utility_meter, ...), this is typically ignored because options flows don't expose renaming. Rename a flow helper by deleting and recreating instead.
stepNoStep/increment value for input_number or counter
waitNoWait for helper entity to be queryable before returning. Default: True. Set to False for bulk operations.
actionNoExplicit intent: 'create' a new helper or 'update' an existing one. When omitted, falls back to the implicit discriminator: presence of helper_id => update, absence => create. Pass 'create' or 'update' to disambiguate (e.g. so a typo in helper_id surfaces as a clear 'helper not found' error instead of being mistaken for a create call).
configNoConfig dict for flow-based helper types and helper_type='config_subentry' (template, group, utility_meter, derivative, min_max, threshold, integration, statistics, trend, random, filter, tod, generic_thermostat, switch_as_x, generic_hygrostat, history_stats, mold_indicator). Ignored for simple helper types. On update it is a patch: a field you omit keeps its current value, and a field set to null is cleared where the schema allows that field to be empty. A field two steps declare gets your one value both times; pass step_values={'<step_id>': {'<field>': <value>}} to give a step its own value, or to leave it out of that step; a LIST of those objects supplies one per encounter when the flow presents a step more than once. Field set is delivered as data_schema on the first validation error.
fridayNoSchedule time ranges for Friday. List of {'from': 'HH:MM', 'to': 'HH:MM'} dicts. Optional 'data' dict for additional attributes.
labelsNoLabels to categorize the helper
mondayNoSchedule time ranges for Monday. List of {'from': 'HH:MM', 'to': 'HH:MM'} dicts. Optional 'data' dict for additional attributes (e.g. {'from': '07:00', 'to': '22:00', 'data': {'mode': 'comfort'}})
radiusNoRadius in meters for zone (default: 100)
sundayNoSchedule time ranges for Sunday. List of {'from': 'HH:MM', 'to': 'HH:MM'} dicts. Optional 'data' dict for additional attributes.
tag_idNoTag ID for tag. On create, omit to auto-generate a unique uuid4 hex (HA's tag/create requires this field; the tool fills it in for you). On update, the tag's existing tag_id is required (passed via helper_id).
area_idNoArea/room ID to assign the helper to
initialNoInitial value for applicable helper types. For input_boolean, input_select, input_number, input_text, and input_datetime: setting `initial` — even to false/0 — disables last-state restore and forces that value on every HA restart; omit unless you want the helper to reset to that value on every restart instead of restoring its last state. For counter, `initial` is just the starting value — restore-on-restart is controlled separately by `restore` (default True).
optionsNoList of options for input_select (required for input_select)
passiveNoPassive zone (won't trigger state changes for person entities)
pictureNoPicture URL for person entity
restoreNoRestore state after restart (counter, timer). Defaults to True for counter, False for timer
tuesdayNoSchedule time ranges for Tuesday. List of {'from': 'HH:MM', 'to': 'HH:MM'} dicts. Optional 'data' dict for additional attributes.
user_idNoUser ID to link to person entity
categoryNoCategory ID to assign to this helper. Use ha_config_get_category(scope='helpers') to list available categories, or ha_config_set_category() to create one.
durationNoDefault duration for timer in format 'HH:MM:SS' or seconds (e.g., '0:05:00' for 5 minutes)
entry_idNoParent config entry ID when helper_type='config_subentry'. Use ha_get_integration() to find entry IDs.
has_dateNoInclude date component for input_datetime
has_timeNoInclude time component for input_datetime
latitudeNoLatitude for zone (required for zone)
saturdayNoSchedule time ranges for Saturday. List of {'from': 'HH:MM', 'to': 'HH:MM'} dicts. Optional 'data' dict for additional attributes.
thursdayNoSchedule time ranges for Thursday. List of {'from': 'HH:MM', 'to': 'HH:MM'} dicts. Optional 'data' dict for additional attributes.
helper_idNoREQUIRED when updating an existing helper. Bare ID ('my_button') or full entity ID ('input_button.my_button'). Omit to create a new helper.
longitudeNoLongitude for zone (required for zone)
max_valueNoMaximum value (input_number/counter) or maximum length (input_text). Also accepts shorthand 'max'.
min_valueNoMinimum value (input_number/counter) or minimum length (input_text). Also accepts shorthand 'min'.
wednesdayNoSchedule time ranges for Wednesday. List of {'from': 'HH:MM', 'to': 'HH:MM'} dicts. Optional 'data' dict for additional attributes.
descriptionNoDescription for tag
helper_typeYesType of helper entity to create or update
subentry_idNoExisting config subentry ID to reconfigure when helper_type='config_subentry'. Omit to create.
MandatoryBPSNo
subentry_typeNoIntegration-defined subentry type when helper_type='config_subentry'.
BestPracticeKeyNoRead-receipt for the home-assistant-best-practices skill; required when strict best-practices mode is enabled. Not a secret or credential: the current value is an attestation phrase published openly at the top of the skill content served by ha_get_skill_guide. Read that content, then pass the value back verbatim — this round-trip is the server's designed protocol confirming the practices were read before writing.
device_trackersNoList of device_tracker entity IDs for person
unit_of_measurementNoUnit of measurement for input_number (e.g., '°C', '%', 'W'). Also accepts shorthand 'unit'.
show_advanced_optionsNoWhen helper_type='config_subentry', ask older Home Assistant versions to expose advanced flow options. No-op on HA 2026.6+; pending removal before HA 2027.6.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. Changed1 schema field changedv8.4.1
    • changedInput schema / properties / config / description
      Previous value: -"Config dict for flow-based helper types and helper_type='config_subentry' (template, group, utility_meter, derivative, min_max, threshold, integration, statistics, trend, random, filter, tod, generic_thermostat, switch_as_x, generic_hygrostat, history_stats, mold_indicator). Ignored for simple helper types. Field set is delivered as data_schema on the first validation error."New value: +"Config dict for flow-based helper types and helper_type='config_subentry' (template, group, utility_meter, derivative, min_max, threshold, integration, statistics, trend, random, filter, tod, generic_thermostat, switch_as_x, generic_hygrostat, history_stats, mold_indicator). Ignored for simple helper types. On update it is a patch: a field you omit keeps its current value, and a field set to null is cleared where the schema allows that field to be empty. A field two steps declare gets your one value both times; pass step_values={'<step_id>': {'<field>': <value>}} to give a step its own value, or to leave it out of that step; a LIST of those objects supplies one per encounter when the flow presents a step more than once. Field set is delivered as data_schema on the first validation error."
  2. Changed2 schema fields changedv8.3.0
    • changedInput schema / properties / config / description
      Previous value: -"Config dict for flow-based helper types and helper_type='config_subentry' (template, group, utility_meter, derivative, min_max, threshold, integration, statistics, trend, random, filter, tod, generic_thermostat, switch_as_x, generic_hygrostat). Ignored for simple helper types. Field set is delivered as data_schema on the first validation error."New value: +"Config dict for flow-based helper types and helper_type='config_subentry' (template, group, utility_meter, derivative, min_max, threshold, integration, statistics, trend, random, filter, tod, generic_thermostat, switch_as_x, generic_hygrostat, history_stats, mold_indicator). Ignored for simple helper types. Field set is delivered as data_schema on the first validation error."
    • changedInput schema / properties / helper_type / enum
      Previous value: -[
      -  "counter",
      -  "config_subentry",
      -  "derivative",
      -  "filter",
      -  "generic_hygrostat",
      -  "generic_thermostat",
      -  "group",
      -  "input_boolean",
      -  "input_button",
      -  "input_datetime",
      -  "input_number",
      -  "input_select",
      -  "input_text",
      -  "integration",
      -  "min_max",
      -  "person",
      -  "random",
      -  "schedule",
      -  "statistics",
      -  "switch_as_x",
      -  "tag",
      -  "template",
      -  "threshold",
      -  "timer",
      -  "tod",
      -  "trend",
      -  "utility_meter",
      -  "zone"
      -]New value: +[
      +  "counter",
      +  "config_subentry",
      +  "derivative",
      +  "filter",
      +  "generic_hygrostat",
      +  "generic_thermostat",
      +  "group",
      +  "history_stats",
      +  "input_boolean",
      +  "input_button",
      +  "input_datetime",
      +  "input_number",
      +  "input_select",
      +  "input_text",
      +  "integration",
      +  "min_max",
      +  "mold_indicator",
      +  "person",
      +  "random",
      +  "schedule",
      +  "statistics",
      +  "switch_as_x",
      +  "tag",
      +  "template",
      +  "threshold",
      +  "timer",
      +  "tod",
      +  "trend",
      +  "utility_meter",
      +  "zone"
      +]
  3. First observedv7.14.2

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructiveHint=true annotation, the description discloses rich behavioral traits: update patch semantics (omitted fields keep current value, null clears), silent ignoring of undeclared config keys (with the submit-once-then-read-data_schema recovery protocol), the rename trap ('Options flows reject the name key on update — to rename a flow helper, delete and recreate'), and the multi-menu `next_step_id`-as-list behavior. It also explains that validation errors carry data_schema and menu_options in the response context for self-correction. No contradiction with the 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?

Long (~550 words) but structurally justified for a 30-type, 43-parameter tool. It is front-loaded: purpose, prerequisite, type taxonomy, required-parameter patterns, then behavior notes, then examples. The main blemish is minor redundancy — update-preservation semantics and the rename-delete-recreate rule appear in both the description and the schema's `config`/`name` descriptions, and the MUST-call instruction is stated twice.

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 the most complex tool in its family, the description covers everything needed for a correct first call: required arguments per operation type (name vs helper_id vs entry_id/subentry_type/subentry_id), update semantics, silent-failure handling, error self-correction protocol, routing to alternatives, and worked examples for the non-obvious first-call payloads (template, group, tod, config subentry). With an output schema present and annotations covering safety, nothing essential is missing.

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 98% and the schema itself is exemplary (e.g., `initial` restore-disable semantics, `tag_id` auto-generation, `config` patch rules, `name` flow-update note). The description adds the cross-cutting semantics the schema cannot express: the SIMPLE/FLOW/CONFIG_SUBENTRY taxonomy that maps which parameters apply to which type, entry_id doubling as helper_id for flow updates, and the action-fallback discriminator. This is meaningful added value, though individual parameter meaning was already well covered.

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 opening sentence 'Create or update Home Assistant helper entities and config subentries (30 types, unified interface)' states a specific verb pair, a concrete resource, and the scope in one line. It also distinguishes itself from siblings by explicitly routing the excluded `otp` case to ha_set_integration and clarifying that this is the create/update counterpart to list/remove tools like ha_config_list_helpers and ha_remove_helpers_integrations.

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 states a hard prerequisite ('MUST call ha_get_skill_guide OR refer to your locally installed skills first'), names the one alternative for an excluded case (ha_set_integration(domain='otp')), and points to the helper-selection.md decision matrix shipped in skill_content. It also gives precise when-to guidance for the `action` parameter, explaining the implicit helper_id/subentry_id presence discriminators and when to disambiguate explicitly.

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