Skip to main content
Glama
Sign In
Home Assistant MCP Server

Home Assistant MCP Server

by rilhia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Search entities

search_entities
Read-onlyIdempotent

Search Home Assistant entities by keyword across IDs, names, areas, devices, and classes. Returns compact summaries and supports domain, area, and state filters to narrow results.

Instructions

Keyword search across entity ids, friendly names, areas, devices and device classes. Returns a compact summary per entity so large installations do not exhaust context. Use domain and area filters to narrow results. Synonyms such as lamp, heating and blind are understood.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_entities"
  }
}

Input Schema

NameRequiredDescriptionDefault
areaNoArea name or id, matched case insensitively as a substring.
limitNoMaximum rows to return.
queryNoWords to look for, for example 'kitchen lamp' or 'battery'. Omit to list by filter only.
stateNoOnly entities currently in this state, for example 'on' or 'unavailable'.
domainNoEntity domain or comma separated domains, for example 'light' or 'sensor,binary_sensor'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the bar is lower. The description still adds real behavior: results are deliberately compact to avoid exhausting context on large installations, and synonym matching ('lamp', 'heating', 'blind') is performed on the query — neither of which is derivable from the annotations or schema.

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?

Four short sentences, front-loaded with what is searched before the return shape, then filtering, then a quirk about synonyms. No filler; the only mild weakness is that the synonym note sits last rather than being tied to the 'query' parameter explicitly.

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?

No output schema exists, and the description compensates by stating the return is a compact per-entity summary — exactly the detail an agent needs. All parameters are optional and schema-documented, and annotations cover safety; the only missing pieces are result ordering/ranking and whether output is paginated, which are minor for a read-only search.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all five parameters (area, domain, limit, query, state) are already documented in the input schema, setting the baseline at 3. The description reinforces that domain/area act as narrowing filters and that query is keyword-based with synonym expansion, but adds no format or edge-case detail beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Keyword search across entity ids, friendly names, areas, devices and device classes') and defines the searchable surface precisely. It implicitly separates itself from get_entity_details by promising a 'compact summary per entity' rather than full records, but never names that or any sibling explicitly.

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

Usage Guidelines3/5

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

The line 'Use domain and area filters to narrow results' gives one concrete usage tactic, so the intended workflow is implied. However, there is no when-not guidance (e.g. use get_entity_details for full attributes, list_areas for areas alone) and no named alternatives among the large sibling set.

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