Skip to main content
Glama

Get area-scoped HA snapshot

snapshot_get_area_snapshot
Read-onlyIdempotent

Retrieve all states, devices, and entities for one Home Assistant area in a single call. Use it to explore or control everything in a room without manually configuring snapshot arguments.

Instructions

Return states, devices and entities for one area in a single call.

Convenience wrapper that calls snapshot_get_snapshot with include=["states", "devices", "entities", "areas"] and area_id fixed to the given area; it adds no filtering beyond summary.

Use when: exploring or controlling everything in one physical area without composing snapshot_get_snapshot's include/area_id arguments by hand. Not for: a snapshot spanning several areas or other sections — call snapshot_get_snapshot directly; entity registry rows without state values — use areas_get_area_entities; live state values without registry context — use areas_get_area_states. Returns: same dict shape as snapshot_get_snapshot with include=["states", "devices", "entities", "areas"]. Limits: no pagination; every state/device/entity in the area is returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
area_idYesArea registry ID to scope the snapshot to; states, devices and entities outside this area are excluded.
summaryNoIf true, each state is reduced to entity_id/state/friendly_name. Set false for full attributes.

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 / area_id / description
      Added value: +"Area registry ID to scope the snapshot to; states, devices and entities outside this area are excluded."
    • addedInput schema / properties / summary / description
      Added value: +"If true, each state is reduced to entity_id/state/friendly_name. Set false for full attributes."
  2. Addedv0.18.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered. The description adds genuine extra context beyond that: it discloses the wrapper internals (fixed include list and area_id), states the only added filter is `summary`, and documents the no-pagination limit that every state/device/entity is returned.

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?

Front-loaded summary sentence, then clearly labeled Use when / Not for / Returns / Limits blocks. It is longer than a two-parameter tool strictly needs, but every section carries distinct information, so the length is largely earned.

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?

With rich annotations, a full output schema, and documented return shape ('same dict shape as snapshot_get_snapshot'), the description leaves no gap an agent needs to call this correctly.

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 baseline is 3, but the description adds meaning the schema cannot express: it explains that area_id is effectively pinned, that include is forced to four sections, and that `summary` is the sole filter knob. This clarifies what the two parameters actually control.

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+resource (return states/devices/entities for one area) and immediately positions itself as a wrapper over `snapshot_get_snapshot`. The agent can distinguish it from that sibling and from areas_get_area_entities/areas_get_area_states 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 Guidelines5/5

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

Explicit 'Use when' and 'Not for' sections, each naming the correct alternative (snapshot_get_snapshot for multi-area, areas_get_area_entities for registry rows, areas_get_area_states for live state). Routing is unambiguous.

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