Skip to main content
Glama
homeassistant-ai

Home Assistant MCP Server

Official
by homeassistant-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Create or Update Area or Floor

ha_set_area_or_floor
Destructive

Create or update Home Assistant areas (rooms) and floors (building levels), assigning names, IDs, levels, icons, labels, and temperature or humidity sensors.

Instructions

Create or update a Home Assistant area or floor.

Pass kind='area' (with optional floor_id, picture, labels, temperature_entity_id, humidity_entity_id) or kind='floor' (with optional level). Provide name only to create a new entry; provide id to update an existing one. Cross-kind parameters (e.g., picture or labels under kind='floor') are rejected with VALIDATION_INVALID_PARAMETER.

EXAMPLES: ha_set_area_or_floor(kind="area", name="Kitchen") ha_set_area_or_floor(kind="area", id="kitchen", floor_id="ground_floor") ha_set_area_or_floor(kind="area", id="kitchen", labels=["site_home"]) ha_set_area_or_floor(kind="area", id="kitchen", temperature_entity_id="sensor.kitchen_temp", humidity_entity_id=None) ha_set_area_or_floor(kind="floor", name="Basement", level=-1) ha_set_area_or_floor(kind="floor", id="ground_floor", level=0)

If a Claude Desktop user gets a 4-minute timeout with no result on this call, read the target back before repeating it, and tell them to wait a few seconds before clicking the manual-approve button, as clicking it too quickly is known to cause hangs in Claude Desktop. This workaround is specific to Claude Desktop.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoExisting area_id or floor_id to update (use ha_list_floors_areas to find IDs)
iconNoMaterial Design Icon (e.g., 'mdi:sofa', 'mdi:home-floor-1'; null or empty string to remove; omit to leave unchanged)
kindYesWhich registry to operate on: 'area' for rooms, 'floor' for building levels
nameNoName (required when creating; optional when updating, e.g., 'Living Room', 'Ground Floor')
levelNoNumeric level when kind='floor' (0=ground, 1=first, -1=basement).
labelsNoLabel IDs when kind='area' (replaces the area's label set; empty list to clear). Omit to leave labels unchanged. Floors have no labels.
aliasesNoAlternative names for voice assistant recognition (e.g., ['lounge'], empty list to clear)
pictureNoPicture URL when kind='area' (null or empty string to remove; omit to leave unchanged).
floor_idNoFloor assignment when kind='area' (null or empty string to clear; omit to leave unchanged).
humidity_entity_idNoSensor the area reports humidity from, when kind='area' (a sensor.* entity with device_class humidity; null or empty string to clear). Omit to leave unchanged.
temperature_entity_idNoSensor the area reports temperature from, when kind='area' (a sensor.* entity with device_class temperature; null or empty string to clear). Omit to leave unchanged.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv8.7.0
    • removedInput schema / properties / floor_id / default
      Removed value: -null
    • changedInput schema / properties / floor_id / description
      Previous value: -"Floor assignment when kind='area' (use empty string to clear)."New value: +"Floor assignment when kind='area' (null or empty string to clear; omit to leave unchanged)."
    • addedInput schema / properties / humidity_entity_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Sensor the area reports humidity from, when kind='area' (a sensor.* entity with device_class humidity; null or empty string to clear). Omit to leave unchanged."
+}
    • removedInput schema / properties / icon / default
      Removed value: -null
    • changedInput schema / properties / icon / description
      Previous value: -"Material Design Icon (e.g., 'mdi:sofa', 'mdi:home-floor-1', empty string to remove)"New value: +"Material Design Icon (e.g., 'mdi:sofa', 'mdi:home-floor-1'; null or empty string to remove; omit to leave unchanged)"
    • removedInput schema / properties / picture / default
      Removed value: -null
    • changedInput schema / properties / picture / description
      Previous value: -"Picture URL when kind='area' (empty string to remove)."New value: +"Picture URL when kind='area' (null or empty string to remove; omit to leave unchanged)."
    • addedInput schema / properties / temperature_entity_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Sensor the area reports temperature from, when kind='area' (a sensor.* entity with device_class temperature; null or empty string to clear). Omit to leave unchanged."
+}
  2. Changed5 schema fields changedv8.6.0
    • changedInput schema / properties / floor_id / description
      Previous value: -"Floor assignment when kind='area' (use empty string to clear). Only valid when kind='area'."New value: +"Floor assignment when kind='area' (use empty string to clear)."
    • changedInput schema / properties / id / description
      Previous value: -"Existing area_id or floor_id to update (omit to create a new entry; use ha_list_floors_areas to find IDs)"New value: +"Existing area_id or floor_id to update (use ha_list_floors_areas to find IDs)"
    • addedInput schema / properties / labels
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Label IDs when kind='area' (replaces the area's label set; empty list to clear). Omit to leave labels unchanged. Floors have no labels."
+}
    • changedInput schema / properties / level / description
      Previous value: -"Numeric level when kind='floor' (0=ground, 1=first, -1=basement). Only valid when kind='floor'."New value: +"Numeric level when kind='floor' (0=ground, 1=first, -1=basement)."
    • changedInput schema / properties / picture / description
      Previous value: -"Picture URL when kind='area' (empty string to remove). Only valid when kind='area'."New value: +"Picture URL when kind='area' (empty string to remove)."
  3. First observedv7.14.2

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description adds genuinely useful behavior beyond them: the create-vs-update branch, per-kind parameter rejection with a concrete error code, and the Claude Desktop timeout/repeat-read workaround. It stops short of explaining that null/empty-string values clear fields or what permissions are needed, which matters for a destructive write.

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?

Purpose, the kind split, and the create/update rule are front-loaded and the examples earn their space. The trailing Claude Desktop timeout paragraph is long and somewhat tangential, blunting an otherwise tight definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the description covers the create/update branch, both kinds, cross-kind errors, and worked examples for an 11-parameter mutation tool. The remaining gap is the destructive/overwrite implications of passing null or empty-string values, which is never surfaced despite destructiveHint=true.

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 the per-parameter descriptions already carry the documented semantics (baseline 3). The description adds value by consolidating which optional parameters belong to kind='area' vs kind='floor' and by showing six concrete call shapes, which is more than the schema alone conveys.

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 description names a precise verb pair and resource ('Create or update a Home Assistant area or floor') and immediately splits the resource into its two kinds with their applicable parameters. An agent can distinguish this from ha_remove_area_or_floor and ha_list_floors_areas without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit decision rule ('Provide name only to create a new entry; provide id to update an existing one') and states that cross-kind parameters are rejected with VALIDATION_INVALID_PARAMETER, which is real routing guidance. It does not, however, name alternative tools for the lookup step or say when not to use this tool.

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