hass-mcp-extensions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Several tools overlap in purpose (e.g., get_error_log vs get_core_log, call_service_tool vs entity_action, list_entities vs search_entities_tool), though descriptions help differentiate. Still, the boundaries are not always clear for an agent.
Naming Consistency3/5
Most tools follow a verb_noun pattern with snake_case, but some use noun_verb (e.g., entity_action) or have inconsistent suffixes like '_tool'. The pattern is recognizable but not fully consistent.
Tool Count3/5
28 tools is on the higher side for a single server, but given the breadth of Home Assistant, it is justifiable. Some redundancy suggests it could be streamlined.
Completeness3/5
Core operations are covered (read entities, call services, manage automations/scenes, logs), but missing delete operations for automations/scenes and no tool to create a scene from scratch. Gaps exist but are not critical.
Average 4.2/5 across 28 of 28 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It describes the return format and shows service examples (turn_on, reload) that imply state changes, but does not explicitly state that calls can be destructive, require permissions, or have side effects. The 'low-level' warning partially compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with sections for args, returns, and examples. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, return format, and examples. However, missing behavioral context (destructive potential, permissions) and usage guidelines given the generic nature of the tool. The output schema exists but return description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It provides examples but no additional semantics: no allowed domain values, no service validation, no details on data structure beyond a single example. The description adds minimal value beyond the schema field names.
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?
Clearly states 'Call any Home Assistant service (low-level API access)' with a specific verb ('Call') and resource ('Home Assistant service'). The low-level designation distinguishes it from sibling tools like entity_action or domain_summary_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions 'low-level API access' implying direct use, but does not specify when not to use it or name alternative tools for common cases (e.g., entity_action for entity control, list_entities for discovery).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether the update is destructive, requires permissions, or has side effects. The agent is left uninformed about the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for purpose, then a clear bullet-like list of parameters with an example. Every sentence contributes value, and the structure is easy to parse.
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?
Given the nested objects and lack of output schema, the description covers the entities parameter well with an example. However, it omits details about return values, partial vs full replacement, and permissions, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds comprehensive meaning: it specifies scene_id as a numeric ID from get_ha_config_item, name as display name, and entities as a mapping with a concrete example. This fully compensates for the schema's lack of documentation.
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?
The description states 'Update a stored scene's entity states', which is a specific verb+resource. It clearly distinguishes from sibling tools like 'create_or_update_automation' or 'entity_action' by focusing on scene updates. However, it does not explicitly differentiate from potential similar scene tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or exclusions. Without this, an agent lacks context for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly indicates a read operation ('Fetch') and mentions WebSocket, but does not disclose potential size of the returned config or error handling behaviors. Adequate for a simple fetch, but could add more context.
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?
The description is concise with a clear structure: one sentence explaining the purpose, followed by an args section. It front-loads the key information and only includes essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what is returned. It does not mention the format or structure of the dashboard config. Parameter documentation is good, but missing output context makes it partially incomplete.
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 description coverage is 0%, so the description must compensate. It explains that url_path is a dashboard slug and clarifies the default None for Overview, adding meaning beyond the schema's 'anyOf' type definition.
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 clearly states the verb 'Fetch' and the resource 'full Lovelace dashboard config', and it specifies the method 'via WebSocket'. It distinguishes from siblings like 'get_lovelace_view' by indicating it retrieves the entire dashboard, not a single view.
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 description explains how to use the url_path parameter with examples (None for Overview, slug for custom dashboard), but it does not explicitly state when to use this tool versus alternatives like 'get_lovelace_view' or 'save_lovelace_dashboard'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains matching logic (path-first, then title, case-insensitive) but does not specify read-only nature, error handling (e.g., not found), or permissions. The term 'Fetch' implies read-only, but additional context would improve transparency.
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?
The description is concise with two sentences and an Args section. The first sentence states purpose efficiently. The structure is clear, though the example syntax (Numpy-style docstring) could be slightly more compact for agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not describe the return format or structure of the fetched view. It also omits behavior on missing views or errors. For a simple fetch tool, it is adequate but not fully complete.
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 description coverage is 0%, so the description compensates well. It explains that view_name is matched against view['path'] then view['title'] (case-insensitive), and url_path is a dashboard slug or None for Overview. This adds substantial meaning beyond schema titles.
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 starts with a clear verb-resource phrase 'Fetch a single view from a Lovelace dashboard by title or path.' It distinctly identifies what the tool does and differentiates from sibling tools like 'get_lovelace_dashboard' (which retrieves the entire dashboard) and 'save_lovelace_dashboard'.
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 description explains parameter matching order and the default dashboard for url_path, but does not explicitly state when to use this tool versus alternatives among siblings. Usage is implied through parameter details, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves automations with specific fields, implying a read-only operation. However, it does not disclose whether disabled automations are included, rate limits, or permissions required, leaving gaps in behavioral context.
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?
The description is relatively short and front-loaded with the purpose. It includes a 'Returns' section and example, but could be slightly more concise by removing redundant phrasing like 'A list of automation dictionaries, each containing'.
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?
Given the tool's simplicity (0 params, no nested objects), the description is complete. It specifies the return fields and provides an example. An output schema exists, so explicit return value documentation is not necessary.
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?
The tool has no parameters (schema coverage 100%), so the description does not need to add parameter semantics. Baseline for 0 params is 4, and the description adequately covers the absence of parameters.
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 clearly states 'Get a list of all automations from Home Assistant', specifying the verb and resource. It distinguishes from sibling tools like 'create_or_update_automation' and 'list_entities' by focusing on automations and their specific fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention filtering, prerequisites, or exclusions, leaving the agent without context for selection among siblings like 'list_entities' or 'entity_action'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the action and return of response but omits side effects (e.g., state changes, error handling, permission needs). It adequately covers the basic behavior but lacks depth.
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?
The description is well-structured, starting with purpose, then args, returns, examples, and domain parameters. It is front-loaded and organized, though somewhat lengthy; however, each section adds necessary value given the sparse schema.
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?
For a simple 3-parameter tool with no output schema, the description covers inputs thoroughly with examples and domain-specific info. It lacks details on output format or error cases, but overall it is sufficient for the tool's straightforward nature.
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?
Since the input schema has no descriptions (0% coverage), the description adds significant value: it explains entity_id and action, provides examples, and lists domain-specific parameters per entity type. This compensates well for the schema deficiency.
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 clearly states the tool's purpose: perform standard actions (on, off, toggle) on Home Assistant entities. It specifies the verb 'perform an action' and resource 'entity', and distinguishes from siblings like call_service_tool by focusing on common actions.
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 description implies usage through examples and domain-specific parameters but does not explicitly state when to use this tool versus alternatives like call_service_tool. No exclusions or prerequisites are provided, leaving the agent to infer appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses it is a read operation and specifies input constraints, but does not address error cases, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, well-structured with a summary line and Args list, contains no unnecessary words, and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains input but does not describe the output format or possible errors. For a read tool without an output schema, some guidance on return structure is expected.
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 descriptions are missing (0% coverage). The description adds crucial meaning: item_type enum values and clarifies item_id is numeric (not entity_id), compensating for the empty schema.
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 uses a specific verb ('Get') and resource ('stored HA config item'), and lists the valid item types. It clearly distinguishes from siblings by specifying retrieval by numeric ID.
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 description implies use when a numeric ID of a config item is known, but does not explicitly state when to use this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return format and provides best practices, but it does not explicitly state that the tool is read-only, nor does it discuss potential high response sizes or rate limits. The behavioral disclosure is adequate but not comprehensive.
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?
The description is well-structured with sections (Args, Returns, Examples, Best Practices). It is front-loaded with the purpose. Slightly verbose in the best practices, but each part adds value.
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?
Given the tool has an output schema, the description explains the return structure completely. Parameters are well-documented. Best practices and examples cover usage scenarios. There are no gaps for a 2-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section explaining both parameters: entity_id (the entity ID) and hours (number of hours, default 24). Examples show correct usage. Since the schema has 0% coverage, the description fully compensates by providing clear parameter semantics.
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?
The description clearly states 'Get the history of an entity's state changes', specifying the verb and resource. It distinguishes from siblings like get_logbook by focusing on state changes, though it does not explicitly differentiate from get_logbook which also records state changes.
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 'Best Practices' section provides guidance on reasonable hour ranges and when to use this tool (discrete state changes) vs. not (continuously changing sensors). However, it does not name alternative tools explicitly, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a non-destructive read operation ('Fetch logs'), but lacks details on authorization, rate limits, or potential side effects. The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences for purpose and one line per parameter. Every word is useful, and the main action is front-loaded.
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?
Given the presence of an output schema, the description does not need to explain return values. It covers both parameters adequately for a simple fetch tool. Minor omission: no mention of error scenarios, but not critical for this use case.
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?
With 0% schema description coverage, the description adds value by providing an example for 'slug' and explaining 'tail' behavior ('return only the last N lines'). This compensates for the lack of schema descriptions, though default values could be explicitly noted.
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 clearly states the verb 'Fetch', the resource 'logs for a Supervisor add-on', and the output format 'as plain text'. It distinguishes from siblings like 'search_addon_logs' which implies searching rather than fetching.
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 description does not provide explicit guidance on when to use this tool versus alternatives like 'search_addon_logs' or 'get_core_log'. It only states what it does, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It explains default lean formatting, the note that search_query does not support wildcards, and the behavior of detailed=True. This adequately discloses behavior without contradictions.
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?
The description is well-structured with sections (Args, Returns, Examples, Best Practices) and is front-loaded with the purpose. While somewhat verbose in docstring style, every sentence adds value and the organization aids readability.
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?
Given 5 parameters, no annotations, but an output schema, the description covers filtering, limits, detailed vs lean, and best practices. The return type is described, and the output schema provides additional structure, making it sufficiently complete for a list tool.
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?
With 0% schema coverage, the description compensates by explaining each parameter (domain, search_query, limit, fields, detailed) including the search_query limitation and default values. Examples clarify usage, adding significant value beyond the schema.
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?
The description clearly states the tool retrieves a list of entities with optional filtering. It differentiates from siblings implicitly via best practices (e.g., for domain overviews use domain_summary_tool) but does not explicitly contrast with search_entities_tool.
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?
The Best Practices section provides clear guidance on when to use lean format, prefer domain filtering, and when to use domain_summary_tool instead. Examples illustrate common use cases. It does not fully contrast with all siblings, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It correctly indicates read-only behavior and warns about potential NULL timestamp columns. However, it lacks information about error handling (e.g., invalid SQL), query timeouts, maximum query size, or impact on the system. While it covers the core behavioral trait, several aspects remain unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief summary sentence, followed by use cases, restrictions, key tables, and timestamp details. Every sentence adds value, and there is no redundant or vague language. It is easy to scan and front-loaded with the most critical information.
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?
Given that an output schema exists (expected based on context), the description does not need to detail return values. It provides essential context about tables, restrictions, and a timestamp caveat, which covers the most important aspects for an agent to use the tool effectively. However, it omits details like result size limits or pagination, which could be relevant for large queries.
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?
The single parameter 'sql' has no schema description (0% coverage), so the description must compensate. It does so by explaining what a SELECT statement is and giving examples of valid queries and table structures. However, it does not explicitly describe the parameter format (e.g., that it expects a string) beyond its name. The added value is moderate but not comprehensive.
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 explicitly states 'Run a read-only SQL SELECT against the Home Assistant recorder (MariaDB).' It gives concrete use cases like fetching Zigbee action events and checking state history, making the purpose very clear. Although no title is provided, the verb+resource specificity is high and sufficiently distinguishes from sibling tools that are more focused on specific queries (e.g., get_history, get_logbook).
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?
The description notes that only SELECT statements are allowed and provides examples of when to use the tool ('ad-hoc queries'). It also lists key tables and timestamp nuances. However, it does not explicitly state when not to use this tool (e.g., in favor of more specific tools like get_history for state history) or mention prerequisites like database permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the return values including error handling, implying a read-only operation. It does not mention permissions or side effects, but for a zero-parameter tool, this is largely sufficient.
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?
Description is well-structured with sections for description, returns, examples, and best practices. It is concise but the examples section is minimal. No redundant information.
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?
Given zero parameters and no annotations, the description covers the output schema and usage advice thoroughly. It is complete for the tool's complexity.
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?
No parameters exist; schema coverage is 100% vacuously. Baseline for 0 parameters is 4. Description adds value by explaining the output, which indirectly clarifies that no input is needed.
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?
Description clearly states 'Get the Home Assistant error log for troubleshooting', specifying the verb and resource. While it doesn't explicitly differentiate from siblings like get_core_log or get_addon_logs, the focus on errors and troubleshooting provides adequate purpose clarity.
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?
Best practices explicitly state when to use this tool ('when troubleshooting specific Home Assistant errors') and provide guidance on analyzing the log. However, it lacks explicit exclusions or mentions of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the return type (a string with the version) and provides an example. Since there are no annotations, the description carries the full burden, and it does so adequately for a simple read-only tool. No additional behavioral traits are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with just two short sentences. Every sentence is informative, and the important information (what it returns) is front-loaded. No unnecessary words.
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?
The tool is very simple with no parameters and a single output. The description fully explains what the tool does and what it returns. The output schema exists but is not needed for understanding. The description is complete for this tool.
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?
There are no parameters, so the input schema is fully covered. The description adds no parameter details since none exist, matching the baseline of 4 for zero-parameter tools.
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 clearly states the tool's purpose: getting the Home Assistant version. It specifies the verb 'get' and the resource 'Home Assistant version', which is unambiguous. No sibling tools perform the same function, so there is no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the tool is simple, there are siblings like 'get_ha_config_item' that might also return version info, but no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the direct SSH-to-MariaDB method and specifies different behavior for event.*_action vs other entities. No contradictions.
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?
Description is well-structured with main action, implementation detail, behavior specifics, and parameter list. It is not overly terse but efficient for the information provided.
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?
Given the presence of an output schema and the description covering behavior, parameter details, and use case differentiation, it is reasonably complete for a data-fetching tool among 26 siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described with examples and constraints (entity_id example, hours default/max) that add value beyond the bare schema which has 0% description coverage.
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?
The description clearly states the tool fetches logbook entries for an entity with full event attributes. It differentiates by mentioning the direct DB query vs the HTTP API, but does not explicitly contrast with siblings like get_history.
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?
The description explicitly explains why to use this tool (avoids large payloads of the HTTP API) and provides context for its use. However, it does not list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool runs `ls -la` over SSH and is restricted to specific root directories, which gives the agent key behavioral context. No annotations are provided, so the description carries the full burden; it does not mention error handling or performance, but the output schema likely covers the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for the main purpose and a structured Args section. It is front-loaded with the core action and uses no filler, making it easy for the agent to parse quickly.
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?
For a tool with a single parameter and a straightforward operation, the description is complete enough. It provides the path argument details and a usage restriction, and the output schema (not shown) likely documents the return structure. Some may want more detail on allowed roots, but overall sufficient.
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?
With 0% schema description coverage, the description compensates by specifying that 'path' must be an absolute directory path and gives an example ('/config'). It also mentions the restriction to allowed roots, adding meaningful context beyond the schema's simple type string.
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 clearly states the tool's purpose: 'List a directory on the Home Assistant host over SSH (``ls -la``).' It also specifies the exact command used and the required argument, distinguishing it from siblings like read_ha_file by referencing restricted roots.
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 description mentions the restriction to allowed roots and references read_ha_file for context, providing some guidance on usage boundaries. However, it does not explicitly state when to use this tool over other siblings, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden. It includes an explicit warning that the tool 'Temporarily disrupts all Home Assistant operations', which is important behavioral context. However, it does not discuss permissions, confirmation, or success/failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only one sentence and a warning notice. It is front-loaded and every part earns its place.
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?
Given the simplicity of the tool (no parameters, output schema exists), the description is nearly complete but does not explain the return value format or whether the operation is synchronous. The warning adds value but a bit more detail on the result would be beneficial.
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?
There are zero parameters, and the schema coverage is 100%. The description does not need to add parameter details. The baseline for zero-parameter tools is 4, and the description meets that.
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 clearly states 'Restart Home Assistant', which is a specific verb and resource. It distinguishes from sibling tools as none others are restart-related.
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 description includes a warning about disruption but does not provide explicit guidance on when to use or when not to use this tool versus alternatives. The context of siblings does not include similar tools, but the lack of when-not-to-use limits the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool is write-oriented ('overwrite') and returns a raw response. However, it lacks details on side effects (e.g., no backup before overwrite), error cases, or authentication needs, which are important for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a one-line purpose statement, followed by clear Arg definitions, and a return note. Every sentence adds value, no filler.
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?
Given the tool has two parameters, no output schema, and no annotations, the description covers the essential aspects: purpose, param semantics, and return type. It lacks error handling or rate limit details, but for a CRUD-like operation this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates. For automation_id, it explains the purpose and provides an example. For the config object, it lists required keys ('alias', 'trigger', 'action', 'mode') and explicitly states that 'id' must not be included, adding critical constraints beyond the schema.
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 explicitly states the tool creates or overwrites automation configs via the HA REST API. It clearly distinguishes between creating (new automation_id) and updating (existing automation_id), setting it apart from read-only sibling tools like list_automations.
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?
The description provides clear usage guidance: use a new automation_id to create, pass an existing one to update. It also specifies required fields in the config and warns not to include an 'id' field. However, it does not explicitly mention when not to use the tool or compare to alternatives for related operations (e.g., deleting automations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the action (fetch as plain text) and parameter effects, but does not mention any side effects, rate limits, or limitations (e.g., log size, snapshot nature). It is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the main purpose, and efficiently explains parameters in two clear paragraphs. No extraneous information.
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?
Given there is an output schema (not shown), the description adequately covers what the tool does and how to use it. It mentions the replacement for get_error_log, which adds context. It is complete for a simple fetch tool, though could note output format or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool description fully explains both parameters: tail (return last N lines after grep) and grep (case-insensitive substring filter). This adds significant meaning beyond the schema structure.
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 clearly states it fetches the Home Assistant Core log as plain text, and distinguishes itself from the upstream get_error_log tool. The verb 'Fetch' is specific, and the resource is clearly identified.
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?
The description mentions it replaces get_error_log, implying when to use it for core log retrieval. It also explains the parameters tail and grep, which help with usage. However, it does not explicitly state when to prefer this over other log tools like get_addon_logs or search_addon_logs, though the differentiation is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It explains the tool is read-only ('look up'), describes the return structure, and parameter requirements. It does not explicitly state non-destructiveness or permission needs, but the lookup nature is clear.
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?
Well-structured in paragraphs: purpose, usage, parameters, return keys. Front-loaded with core info. Slightly verbose but still efficient and clear; each sentence adds value.
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?
No output schema, but description lists all 11 return keys, covering the tool's complexity. It explains parameter matching and usage context thoroughly, making it self-contained for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates fully. It explains entity_id with an example, and device_name with case-insensitive matching behavior. It also clarifies the exclusive-or constraint, adding substantial meaning beyond the schema.
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 clearly states the tool's purpose: 'Look up device registry info for a device,' listing specific fields (integration, manufacturer, model, connections). It distinguishes from sibling tools like get_entity or list_entities by focusing on registry information versus state.
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?
Provides explicit usage context ('useful for determining network/protocol... for re-pairing or debugging') and parameter constraint ('pass exactly one of entity_id or device_name'). However, it does not explicitly exclude using it for state retrieval or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It covers case-insensitive lookup, device-based area inheritance, and the lean parameter's effect on output verbosity. The description of the return structure is also provided, offering good transparency overall.
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?
The description is well-structured with Args and Returns sections and examples, making it easy to scan. While it is slightly verbose for a simple tool, its organization earns a high score; a minor trim could improve conciseness.
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?
Given the presence of an output schema (implied by the Returns section), the description is complete. It explains all three parameters, the return structure, and edge cases like inheritance. For a tool of this complexity, no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the description must fully explain parameters. It does so effectively: area is defined, domain is described as an optional filter, lean is explained as a token-efficiency option, and examples illustrate usage. This adds crucial meaning beyond the bare schema.
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 clearly states the tool's purpose: 'Get all entities assigned to a specific Home Assistant area (room).' This is a specific verb+resource combination that distinguishes it from sibling tools like list_entities or domain_summary_tool, which operate at different granularities.
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?
The description provides helpful context on when to use the tool, including case-insensitive matching and area inheritance behavior. However, it does not explicitly mention when not to use it or suggest alternative tools for broader queries, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the read-only nature and optional filtering behavior. It does not cover error cases (e.g., missing entity) or response format, but for a simple read operation, it's adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with separate Args and Examples sections. Every sentence adds value; no superfluous text.
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?
While the tool is simple and the description covers parameters and usage, it lacks details about the return structure or error handling. Given no output schema, additional context on the response format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having 0% description coverage, the tool description provides clear parameter documentation: entity_id is required, fields is an optional list, detailed is a boolean. The examples illustrate usage. This adds significant meaning beyond the bare schema.
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 clearly states the tool retrieves the state of a Home Assistant entity with optional field filtering. It uses specific verb 'Get' and resource 'entity', distinguishing it from siblings like list_entities or search_entities_tool.
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?
The description implies usage for fetching a single entity's state, and the examples provide concrete contexts (basic state, filtered fields, detailed). However, it does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility. It discloses the overwrite behavior and notes that the raw HA response envelope is returned, allowing inspection of success. It could mention potential destructive consequences or authentication needs, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences (including the Args section) with no wasted words. The purpose is front-loaded, and the parameter documentation is compact yet informative.
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?
Given the tool has 2 parameters (1 required), no output schema, and a nested config object, the description is complete. It explains both parameters, the return value, and refers to a companion tool for obtaining the config. No additional information is necessary for correct usage.
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 description coverage is 0%, but the description adds meaning: config is described as 'the complete dashboard config dict (as returned by get_lovelace_dashboard)', and url_path is explained as 'Dashboard slug, or None for Overview'. This significantly aids understanding beyond the bare schema types.
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 states 'Save (overwrite) an entire Lovelace dashboard config' — a specific verb and resource. This clearly distinguishes it from sibling tools like get_lovelace_dashboard (retrieval) and get_lovelace_view (view-specific).
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?
The description provides clear context: it explains that the config should be the complete dict as returned by get_lovelace_dashboard, and that url_path can be a slug or None for Overview. However, it does not explicitly state when not to use this tool or compare it to alternative mutation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the return structure (total_count, state_distribution, examples, common_attributes) and provides examples, disclosing the tool's read-only nature. It does not mention any side effects, permissions, or rate limits, but the disclosed behavior is sufficient for correct use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: main purpose, Args, Returns, Examples, Best Practices. Each sentence adds value without redundancy. It is appropriately sized for a 2-parameter tool.
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?
Given the low complexity, existence of output schema, and complete description of purpose, parameters, return values, and usage guidance, the tool is fully documented. No gaps remain for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains 'domain' with examples (e.g., 'light', 'switch') and 'example_limit' with meaning ('Maximum number of examples to include for each state') and default. Every parameter is clearly described.
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 clearly states 'Get a summary of entities in a specific domain', specifying the verb and resource. Examples further clarify the scope. This distinguishes it from sibling tools like list_entities or search_entities_tool by focusing on aggregation rather than listing.
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?
The description includes a 'Best Practices' section explicitly advising to use this tool before retrieving all entities in a domain to understand what's available. This provides clear context but does not mention when not to use or alternatives beyond the implicit suggestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses SSH-based reading, directory restrictions, and parameter behaviors (tail, grep). It could mention read-only nature but still provides good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a structured Args section, no wasted words. Efficient and front-loaded.
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?
Given the simple tool and presence of output schema, the description covers purpose, restrictions, and all parameters adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter is explained with examples and behavior: path with example path, tail with line count after filter, grep with case-insensitive filter. Schema coverage is 0%, making this essential.
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 clearly states 'Read a file from the Home Assistant host over SSH' and specifies restricted directories, distinguishing it from siblings like list_ha_dir.
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?
The description lists allowed directories and explains optional parameters tail and grep, providing clear context for use, but lacks explicit when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses case-insensitive filtering and token-limit avoidance. It does not explicitly state read-only nature or further behavioral traits, but the output schema mitigates need for return value details. Slight room for improvement in listing side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a clear purpose sentence, a note about token limits, and parameter docs. No unnecessary words, front-loaded, well-structured.
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?
Given the tool's complexity (3 params, output schema exists), the description covers purpose, usage hint, and parameter details comprehensively. No annotations, but the description compensates fully. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning to all three parameters beyond the schema: slug has an example, grep explains case-insensitive filtering, tail clarifies default behavior. Schema description coverage is 0%, so this is essential and well-done.
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 clearly states 'Fetch add-on logs and filter lines by a case-insensitive substring,' providing a specific verb and resource. It distinguishes from siblings like get_addon_logs by emphasizing filtering and avoiding token limits.
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?
The description implicitly suggests usage when logs are large to avoid token limits, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. However, the context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses: extracts event_type from state_attributes.shared_attrs via JSON_UNQUOTE, returns one row per event, and auto-converts device name to entity slug. No contradictions.
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?
Well-structured with intro, comparison, tech detail, and Args section. Slightly long but every sentence adds value. Could be more concise, but not wasteful.
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?
Given 3 params, no annotations, and output schema present, description covers purpose, behavior, and all parameters adequately. Output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, but description adds extensive meaning: explains device_name format and conversion, minutes default/max, action example and optionality. Far exceeds schema.
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?
Describes specific action: fetch recent Zigbee action events for a device from recorder DB. Clearly distinguishes from siblings like get_logbook by stating efficiency and internal extraction method.
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?
Explicitly compares to logbook API, advising it's more efficient for this purpose. Provides guidance on action filter. Could mention when not to use, but overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return structure (dictionary with count, results, domains) and gives examples. Notes that query matches IDs, names, and attributes. With no annotations provided, the description adequately covers behavior, though it could mention potential errors or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Args, Returns, Examples), is front-loaded with purpose, and every sentence adds value. No unnecessary words.
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?
Given the presence of an output schema, the description adequately outlines the return format. It covers the main use case and differentiates from list_entities. However, it could mention that the tool is read-only (though no annotations exist) or provide more detail on result fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains both parameters: query as a string matching entity fields, noting wildcard limitation; limit with default 20. This adds significant meaning beyond the bare schema.
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 clearly states 'Search for entities matching a query string', specifying the action and resource. It distinguishes from siblings like list_entities by noting that leaving query blank or using that tool returns all entities. Examples further clarify the purpose.
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?
Explicitly states that wildcards are not supported and suggests using list_entities for all entities. Provides default limit (20) and examples, giving clear guidance on when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the return values and structure, but with no annotations, it does not explicitly state that this is a read-only, non-destructive operation. It implies a safe overview query but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-line summary, followed by a bullet list of return keys, examples, and best practices. It is concise yet informative, with no wasted words.
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?
Given the tool has no parameters and a simple return structure, the description is complete. It includes all necessary information for an agent to understand input, output, and usage context, especially with the best practices linking to a sibling tool.
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?
There are no parameters (schema is empty), so the description appropriately has no parameter details. With 0 parameters, baseline is 4.
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 clearly states the tool's purpose: 'Get a comprehensive overview of the entire Home Assistant system'. It lists specific return fields, distinguishing it from sibling tools like domain_summary_tool which dives into specific domains.
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 'Best Practices' section explicitly provides usage guidance: 'Use this as the first call when exploring an unfamiliar Home Assistant instance', 'Perfect for building context', and suggests using domain_summary_tool for deeper dives, effectively differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![home-assistant-mcp MCP server](https://glama.ai/mcp/servers/LoganInTX/home-assistant-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LoganInTX/home-assistant-mcp)

Score Badge

Copy to your README.md:

[![home-assistant-mcp MCP server](https://glama.ai/mcp/servers/LoganInTX/home-assistant-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LoganInTX/home-assistant-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/LoganInTX/home-assistant-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server