chore(internal): sync tool docs after merge [skip ci]

Author: github-actions[bot]

site/src/data/tools.json

@@ -1748,7 +1748,7 @@
   {
     "name": "ha_config_set_helper",
     "title": "Create or Update Helper",
-    "description": "Create or update Home Assistant helper entities and config subentries\n(30 types, unified interface).\n\nMUST call ha_get_skill_guide OR refer to your locally installed skills first.\n\nSIMPLE/FLOW helper create requires `name`; SIMPLE/FLOW helper update\nrequires `helper_id`. Config subentry create requires `entry_id` and\n`subentry_type`; config subentry update also requires `subentry_id`.\n\nSIMPLE types (structured params, WebSocket API): input_boolean, input_button,\ninput_select, input_number, input_text, input_datetime, counter, timer, schedule,\nzone, person, tag.\n\nFLOW types (pass `config` dict, Config Entry Flow API): template, group,\nutility_meter, derivative, min_max, threshold, integration, statistics, trend,\nrandom, filter, tod, generic_thermostat, switch_as_x, generic_hygrostat,\nhistory_stats, mold_indicator.\nNote: `tod` is the purpose-built \"is-current-time-in-range\" indicator\n(supports cross-midnight ranges, unlike `schedule`).\nNote: `otp` is a helper in the HA UI but is not offered here — its flow\nrequires a live TOTP code. Create it with ha_set_integration(domain=\"otp\"),\nas with any other helper-domain flow outside this list.\n\nCONFIG_SUBENTRY type (Config Subentry Flow API): config_subentry.\nPass `entry_id`, `subentry_type`, and `config`. Pass `subentry_id` to\nreconfigure an existing subentry; omit it to create a new subentry.\n\nFor flow-type updates, pass the existing entry_id as `helper_id`. Options flows\nreject the `name` key on update — to rename a flow helper, delete and recreate.\n\nBehavior notes:\n- UPDATE preserves type-specific fields not re-passed (rename never wipes\n  initial/icon/etc. for any simple helper).\n- Pass `action=\"create\"` or `action=\"update\"` to disambiguate intent.\n  For SIMPLE/FLOW helpers, omitted action falls back to the implicit\n  `helper_id`-presence discriminator. For config subentries, omitted\n  action falls back to the `subentry_id`-presence discriminator.\n- For flow-based helpers, config keys not declared by any step's\n  data_schema are silently ignored by HA; submit once and the\n  validation error returns the `data_schema` for that helper so\n  subsequent calls use the correct field names.\n- Validation errors raised by this tool carry the helper's\n  `data_schema` in the response context (and `menu_options` for\n  menu-rooted helpers like `template`/`group` when no sub-type is\n  chosen yet) so a follow-up call can self-correct without a\n  separate schema-discovery round-trip.\n- Flows that present more than one menu (e.g. an MQTT device\n  subentry reconfigure looping through its summary menu) take\n  `next_step_id` as a LIST of successive selections, consumed one\n  per menu encounter.\n\nEXAMPLES (menu-based types + tod, where first-call payload is non-obvious):\n- template sensor:\n    ha_config_set_helper(helper_type=\"template\", name=\"Room Temp\",\n        config={\"next_step_id\": \"sensor\",\n                \"state\": \"{{ states('sensor.x')|float }}\",\n                \"unit_of_measurement\": \"°C\"})\n- group (light):\n    ha_config_set_helper(helper_type=\"group\", name=\"Kitchen Lights\",\n        config={\"group_type\": \"light\",\n                \"entities\": [\"light.a\", \"light.b\"]})\n- tod (time-of-day indicator, cross-midnight OK):\n    ha_config_set_helper(helper_type=\"tod\", name=\"Quiet Hours\",\n        config={\"after_time\": \"22:00:00\", \"before_time\": \"07:00:00\"})\n- config subentry (create under an existing integration):\n    ha_config_set_helper(helper_type=\"config_subentry\",\n        entry_id=\"01HXYZ...\", subentry_type=\"conversation\",\n        config={\"name\": \"Local agent\", \"model\": \"gemma3:27b\"})\n\n``helper-selection.md`` ships in this response under\n``skill_content`` by default — decision\nmatrix for picking the right helper type plus worked examples\nand per-type field tables. For deeper helper-design guidance\nbeyond what ships here, call ha_get_skill_guide.",
+    "description": "Create or update Home Assistant helper entities and config subentries\n(30 types, unified interface).\n\nMUST call ha_get_skill_guide OR refer to your locally installed skills first.\n\nSIMPLE/FLOW helper create requires `name`; SIMPLE/FLOW helper update\nrequires `helper_id`. Config subentry create requires `entry_id` and\n`subentry_type`; config subentry update also requires `subentry_id`.\n\nSIMPLE types (structured params, WebSocket API): input_boolean, input_button,\ninput_select, input_number, input_text, input_datetime, counter, timer, schedule,\nzone, person, tag.\n\nFLOW types (pass `config` dict, Config Entry Flow API): template, group,\nutility_meter, derivative, min_max, threshold, integration, statistics, trend,\nrandom, filter, tod, generic_thermostat, switch_as_x, generic_hygrostat,\nhistory_stats, mold_indicator.\nNote: `tod` is the purpose-built \"is-current-time-in-range\" indicator\n(supports cross-midnight ranges, unlike `schedule`).\nNote: `otp` is a helper in the HA UI but is not offered here — its flow\nrequires a live TOTP code. Create it with ha_set_integration(domain=\"otp\"),\nas with any other helper-domain flow outside this list.\n\nCONFIG_SUBENTRY type (Config Subentry Flow API): config_subentry.\nPass `entry_id`, `subentry_type`, and `config`. Pass `subentry_id` to\nreconfigure an existing subentry; omit it to create a new subentry.\n\nFor flow-type updates, pass the existing entry_id as `helper_id`. Options flows\nreject the `name` key on update — to rename a flow helper, delete and recreate.\n\nBehavior notes:\n- UPDATE preserves type-specific fields not re-passed (rename never wipes\n  initial/icon/etc. for any simple helper). Flow-helper and config\n  subentry updates behave the same way: a field omitted from `config`\n  keeps its current value, and a field set to null is cleared where\n  the schema allows that field to be empty.\n- Pass `action=\"create\"` or `action=\"update\"` to disambiguate intent.\n  For SIMPLE/FLOW helpers, omitted action falls back to the implicit\n  `helper_id`-presence discriminator. For config subentries, omitted\n  action falls back to the `subentry_id`-presence discriminator.\n- For flow-based helpers, config keys not declared by any step's\n  data_schema are silently ignored by HA; submit once and the\n  validation error returns the `data_schema` for that helper so\n  subsequent calls use the correct field names.\n- Validation errors raised by this tool carry the helper's\n  `data_schema` in the response context (and `menu_options` for\n  menu-rooted helpers like `template`/`group` when no sub-type is\n  chosen yet) so a follow-up call can self-correct without a\n  separate schema-discovery round-trip.\n- Flows that present more than one menu (e.g. an MQTT device\n  subentry reconfigure looping through its summary menu) take\n  `next_step_id` as a LIST of successive selections, consumed one\n  per menu encounter.\n\nEXAMPLES (menu-based types + tod, where first-call payload is non-obvious):\n- template sensor:\n    ha_config_set_helper(helper_type=\"template\", name=\"Room Temp\",\n        config={\"next_step_id\": \"sensor\",\n                \"state\": \"{{ states('sensor.x')|float }}\",\n                \"unit_of_measurement\": \"°C\"})\n- group (light):\n    ha_config_set_helper(helper_type=\"group\", name=\"Kitchen Lights\",\n        config={\"group_type\": \"light\",\n                \"entities\": [\"light.a\", \"light.b\"]})\n- tod (time-of-day indicator, cross-midnight OK):\n    ha_config_set_helper(helper_type=\"tod\", name=\"Quiet Hours\",\n        config={\"after_time\": \"22:00:00\", \"before_time\": \"07:00:00\"})\n- config subentry (create under an existing integration):\n    ha_config_set_helper(helper_type=\"config_subentry\",\n        entry_id=\"01HXYZ...\", subentry_type=\"conversation\",\n        config={\"name\": \"Local agent\", \"model\": \"gemma3:27b\"})\n\n``helper-selection.md`` ships in this response under\n``skill_content`` by default — decision\nmatrix for picking the right helper type plus worked examples\nand per-type field tables. For deeper helper-design guidance\nbeyond what ships here, call ha_get_skill_guide.",
     "inputSchema": {
       "properties": {
         "helper_type": {
@@ -1903,7 +1903,7 @@
           "default": null
         },
         "config": {
-          "type": "Annotated[dict[str, Any] | None, JSON_STRING_COERCION, Field(description=\"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.\", default=None)]",
+          "type": "Annotated[dict[str, Any] | None, JSON_STRING_COERCION, Field(description=\"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.\", default=None)]",
           "default": null
         },
         "wait": {
@@ -2331,7 +2331,7 @@
   {
     "name": "ha_set_integration",
     "title": "Set Integration",
-    "description": "Manage an integration (config entry): enable/disable, add, update options, or reconfigure.\n\nModes (pick one):\n- Enable/disable: entry_id + enabled.\n- Add integration: domain (+ config) — drives the domain's config\n  flow, including menus and multi-step forms.\n- Update options: entry_id + config — drives the entry's options\n  flow (what the \"Configure\" button does in the HA UI).\n- Reconfigure: entry_id + reconfigure=True + config — drives the\n  existing entry's official reconfigure flow (host, port, credentials).\n  Call it without confirm_token for a read-only preflight; repeat with\n  the token it returns to apply.\n\nWHEN NOT TO USE:\n- Helpers (template, group, utility_meter, ...): use\n  ha_config_set_helper. The exception is `otp`, which is a helper in\n  the HA UI but is created HERE via domain=\"otp\" — its flow needs a\n  live TOTP code, so ha_config_set_helper deliberately omits it.\n- Config subentries: use\n  ha_config_set_helper(helper_type='config_subentry').\n- Removing an entry: use ha_remove_helpers_integrations.\n\nUse ha_get_integration() to find entry IDs, and\nha_get_integration(entry_id=..., include_schema=True) to inspect the\noptions fields before an update. Its supports_reconfigure field tells\nyou whether an entry qualifies for reconfigure=True; only integrations\nimplementing async_step_reconfigure do.\n\nCaveats: adding an integration runs its config flow exactly as the HA\nUI would (may pair devices, scan the network, create entities). Flows\nrequiring a browser step (OAuth) or an asynchronous provider step\nerror out at that step with a structured error instead of completing.\nReconfigure edits the settings a live integration connects with: a\nwrong host or credential takes it offline, and there is no automatic\nrollback — the returned rollback metadata describes repeating the\nofficial flow by hand with the previous values, which this tool cannot\nread back. The preflight does not validate config keys against the\nintegration's form; wrong field names surface on the confirm call.\n\nEXAMPLES:\n- Disable: ha_set_integration(entry_id=\"abc123\", enabled=False)\n- Add: ha_set_integration(domain=\"workday\", config={\"name\": \"Workday\"})\n- Update options: ha_set_integration(entry_id=\"abc123\", config={\"scan_interval\": 30})\n- Reconfigure preflight: ha_set_integration(entry_id=\"abc123\", reconfigure=True, config={\"host\": \"10.0.0.5\"})\n- Reconfigure apply: repeat that call adding confirm_token=\"sha256:...\"",
+    "description": "Manage an integration (config entry): enable/disable, add, update options, or reconfigure.\n\nModes (pick one):\n- Enable/disable: entry_id + enabled.\n- Add integration: domain (+ config) — drives the domain's config\n  flow, including menus and multi-step forms.\n- Update options: entry_id + config — drives the entry's options\n  flow (what the \"Configure\" button does in the HA UI). Like that\n  dialog it is a patch: omitted fields keep their current values, and\n  a field set to null is cleared where the integration's schema\n  allows that field to be empty.\n- Reconfigure: entry_id + reconfigure=True + config — drives the\n  existing entry's official reconfigure flow (host, port, credentials).\n  Call it without confirm_token for a read-only preflight; repeat with\n  the token it returns to apply.\n\nWHEN NOT TO USE:\n- Helpers (template, group, utility_meter, ...): use\n  ha_config_set_helper. The exception is `otp`, which is a helper in\n  the HA UI but is created HERE via domain=\"otp\" — its flow needs a\n  live TOTP code, so ha_config_set_helper deliberately omits it.\n- Config subentries: use\n  ha_config_set_helper(helper_type='config_subentry').\n- Removing an entry: use ha_remove_helpers_integrations.\n\nUse ha_get_integration() to find entry IDs, and\nha_get_integration(entry_id=..., include_schema=True) to inspect the\noptions fields before an update. Its supports_reconfigure field tells\nyou whether an entry qualifies for reconfigure=True; only integrations\nimplementing async_step_reconfigure do.\n\nCaveats: adding an integration runs its config flow exactly as the HA\nUI would (may pair devices, scan the network, create entities). Flows\nrequiring a browser step (OAuth) or an asynchronous provider step\nerror out at that step with a structured error instead of completing.\nReconfigure edits the settings a live integration connects with: a\nwrong host or credential takes it offline, and there is no automatic\nrollback — the returned rollback metadata describes repeating the\nofficial flow by hand with the previous values, which this tool cannot\nread back. The preflight does not validate config keys against the\nintegration's form; wrong field names surface on the confirm call.\n\nEXAMPLES:\n- Disable: ha_set_integration(entry_id=\"abc123\", enabled=False)\n- Add: ha_set_integration(domain=\"workday\", config={\"name\": \"Workday\"})\n- Update options: ha_set_integration(entry_id=\"abc123\", config={\"scan_interval\": 30})\n- Reconfigure preflight: ha_set_integration(entry_id=\"abc123\", reconfigure=True, config={\"host\": \"10.0.0.5\"})\n- Reconfigure apply: repeat that call adding confirm_token=\"sha256:...\"",
     "inputSchema": {
       "properties": {
         "entry_id": {
@@ -2347,7 +2347,7 @@
           "default": null
         },
         "config": {
-          "type": "Annotated[dict[str, Any] | None, JSON_STRING_COERCION, Field(description=\"Flow form data. With 'domain': input for the new integration's config flow. With 'entry_id' alone: input for the entry's options flow (updates its options). Multi-step flows consume keys per step; menu steps take 'next_step_id' — a string, or a list of successive selections for flows that present more than one menu (e.g. a menu revisited after each branch, ending in a finish option). The step's data_schema is returned on validation errors so field names can be corrected.\", default=None)]",
+          "type": "Annotated[dict[str, Any] | None, JSON_STRING_COERCION, Field(description=\"Flow form data. With 'domain': input for the new integration's config flow. With 'entry_id' alone: input for the entry's options flow (updates its options). Updating an existing entry — options or reconfigure — is a patch: a field you omit keeps its current value, and a field set to null is cleared where the integration's schema allows that field to be empty. Multi-step flows consume keys per step. 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 the field out of that step; a LIST of those objects supplies one per encounter when the flow presents a step more than once. Menu steps take 'next_step_id' — a string, or a list of successive selections for flows that present more than one menu (e.g. a menu revisited after each branch, ending in a finish option). The step's data_schema is returned on validation errors so field names can be corrected.\", default=None)]",
           "default": null
         },
         "reconfigure": {