Hass-MCP

by voska

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose. Entity action vs call_service are differentiated by abstraction level. Query tools (get_entity, list_entities, search, domain_summary) serve different scopes. History and statistics tools are clearly separated for raw vs aggregated data and relative vs absolute time ranges.
Naming Consistency4/5
Most tools follow a consistent snake_case verb_noun pattern (e.g., get_entity, list_entities, search_entities_tool). Exceptions like 'entity_action' and 'domain_summary_tool' deviate from the predominant pattern, causing minor inconsistency.
Tool Count5/5
With 16 tools, the server covers a broad but focused set of capabilities for Home Assistant: entity control, querying, history, statistics, system management, and error logs. The count is well-proportioned—neither sparse nor bloated.
Completeness4/5
The tool set covers primary Home Assistant workflows: entity control, state retrieval, history/statistics, automation listing, and system operations. Minor gaps exist, such as no tools for creating or modifying automations/scripts, but the core monitoring and control use cases are well supported.
Average 4.3/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 carries the transparency burden. It discloses that search_query doesn't support wildcards, defaults (limit=100), and that returning 'lean formatting' by default vs detailed. But it doesn't mention pagination behavior, potential errors, or output structure beyond 'entity dictionaries'. The disclosure is adequate but not thorough.
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 structured into Args, Returns, Examples, and Best Practices sections. It is front-loaded with the core purpose. While somewhat lengthy, every section provides valuable information without being excessively verbose. It could be slightly streamlined but is well-organized.
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 (not provided), the description adequately covers return format and usage scenarios. It includes best practices and comparisons to an alternative tool. It addresses all 5 parameters and provides examples. However, it doesn't mention pagination or maximum limits for the limit parameter, leaving minor gaps.
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's 'Args' section explains each parameter with details (e.g., 'Does not support wildcards' for search_query, default values, types). It adds significant meaning beyond the schema's type/default-only information, though it could be more concise for some parameters.
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 a list of Home Assistant entities with optional filtering', specifying both the verb and resource. It mentions an alternative (domain_summary_tool) for domain overviews, providing some sibling differentiation. However, it does not explicitly distinguish from other similar siblings like search_entities_tool or get_entities_by_area, so it loses a point for full differentiation.
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 that advises when to use this tool vs domain_summary_tool, and provides guidance on preferring domain filtering and using lean format. It also tells how to get all entities by leaving the search query empty. However, it doesn't cover all sibling tools (e.g., search_entities_tool) so it's not fully comprehensive.
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?
The description explains the return value and provides examples, but does not disclose potential side effects (e.g., destructive mutations), authentication needs, or error handling. Given no annotations, more transparency about the generic nature and risks would improve score.
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 separate sections for description, args, returns, and examples. It is moderately concise; the examples are useful and not overly verbose.
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?
The description provides a good overview of purpose, parameters, return value, and examples. For a tool that calls arbitrary services, it covers the necessary context without requiring additional information from output schema or annotations.
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 well by explaining each parameter (domain, service, data) and giving concrete examples. It adds meaning beyond the schema's title-only definitions.
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 'Call any Home Assistant service (low-level API access)' with specific verb and resource. It distinguishes from sibling tools like get_entity or list_entities which are higher-level or more specific operations.
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 as a low-level access for arbitrary service calls, but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not-to-use guidance is provided.
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 that the tool returns a list of automation dictionaries with specific fields, but does not mention any potential side effects, permissions, or limitations. It provides basic behavioral context but not comprehensive 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 fairly concise and front-loaded, but includes a Returns section and example that partially repeat information. It earns its place with clear structure, though minor redundancy exists.
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's simplicity (no parameters, output schema exists), the description covers the basic functionality and return format adequately. It is complete enough for an agent to understand the tool's purpose and output.
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?
Input schema has zero parameters; baseline is 4. Description does not add parameter information as there are none, but this is consistent and sufficient.
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' with a specific verb and resource. It distinctly identifies the tool's purpose, and among siblings like list_entities, it uniquely addresses automations.
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?
No explicit instructions on when or when not to use this tool versus alternatives. While the tool is simple and self-explanatory, the description lacks guidance on context or prerequisites, making it adequate but not proactive.
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 should disclose behavioral traits. It describes the operation as getting state with optional filtering, but does not mention that it is read-only, nor any permissions or side effects. Adequate but not exhaustive.
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 a clear purpose sentence followed by args and examples. It is slightly verbose but each part adds value.
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 no output schema, the description does not explicitly describe the return value format. However, it implies the state is returned, and for a simple get tool this is mostly complete. Could be improved by stating return structure.
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%, yet the description provides detailed docstring for each parameter (entity_id, fields, detailed) and examples. This adds significant value 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 'Get the state of a Home Assistant entity with optional field filtering', using a specific verb and resource. This distinguishes it from sibling tools like call_service_tool 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and args, but does not explicitly state when to use this tool versus alternatives like get_history or list_entities. Implicit guidance is present, but no explicit differentiation.
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 explicitly warns that it 'Temporarily disrupts all Home Assistant operations,' providing critical behavioral insight. With no annotations, this disclosure is valuable, though it could mention authentication or reversibility.
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 three lines, front-loading the purpose and warning. Every sentence adds value, making it efficient.
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?
Despite its brevity, the description covers the core purpose and the main behavioral warning. An output schema exists, so return details are likely covered there. Some might want more detail about the disruption nature, but overall it's adequate for a simple 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?
No parameters exist, so the baseline score is 4. The description adds no parameter details, which is acceptable since none are needed.
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', specifying the exact verb and resource. It is distinct from siblings like get_version or get_error_log, which have different purposes.
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 on when to use this tool versus alternatives. The description lacks context about prerequisites, expected outcomes, or situations where restart is appropriate.
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 provided, so description carries full burden. Discloses optional params and domain-specific details, but does not mention side effects, permissions, or async behavior. Adequate for basic actions.
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?
Well-structured with clear sections, examples, and domain-specific info. Front-loaded purpose, no redundant sentences.
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?
Covers main actions, examples, and domain-specific params. Could mention error handling or constraints, but overall complete for typical use.
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%, description compensates fully. Explains entity_id, action values, and provides extensive domain-specific parameter details (brightness, color_temp, etc.) for params.
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?
Description clearly states verb 'Perform an action' and resource 'Home Assistant entity', with specific action values (on, off, toggle). Distinguishes from siblings like call_service_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?
Provides examples and domain-specific parameters, giving strong implicit guidance. Does not explicitly state when not to use or compare to alternatives, but examples clarify typical usage.
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 of behavioral disclosure. The description mentions that the tool returns 'raw state-change history' and warns about token usage, but it does not explicitly disclose behavioral traits such as mutation risk, authentication needs, rate limits, or data freshness. The description adds some value beyond annotations (which are absent) but is 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 front-loaded with the purpose, followed by comparisons, parameter explanations, return shape, examples, and best practices. It is structured and each section adds value. However, it is slightly verbose with repeated ISO-8601 details; could be more concise without losing clarity.
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 the tool has an output schema (true) and the description references the return shape ('Same shape as get_history: entity_id, states, count, first_changed, last_changed'), the description is sufficiently complete. It covers parameters, usage, alternatives, and examples. It is well-rounded for a history retrieval 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 input schema has 0% description coverage, so the description must explain parameters. It does so thoroughly: entity_id is 'the entity to fetch history for', start_time includes format 'ISO-8601 start' with examples and note about UTC, and end_time is 'ISO-8601 end. Defaults to now (UTC).' This adds significant 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: 'Get raw state-change history for an entity over a date/time range.' It specifies the verb (Get), the resource (raw state-change history), and the scope (over a date/time range). The description also distinguishes itself from the sibling tool `get_history` by noting that `get_history_range` takes an explicit window instead of 'N hours from now', which helps the agent differentiate between the two.
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 description provides explicit usage context: 'Useful for inspecting what happened on a specific day or correlating with an external event.' It also includes best practices: 'Bound the window — wider ranges return more data and more tokens. For aggregated long-term data, prefer get_statistics_range.' This gives clear guidance on when to use this tool and when to use an alternative.
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 full burden. It discloses the return structure (count, results, domains), states the search scope (IDs, names, attributes), and mentions the lack of wildcard support. It does not reveal case-sensitivity or pagination, but overall provides adequate behavioral transparency for a read-only search tool.
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 clear sections (Args, Returns, Examples) and uses concise language. It is appropriately sized for the information conveyed, though minor redundancy exists in examples. Overall efficient and scannable.
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 provides complete coverage of parameters and return structure. It addresses the query behavior and limits, and notes a key limitation (no wildcards). It lacks details on matching semantics (exact vs partial) and ordering, but is sufficient for typical use.
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 description coverage is 0%, so the description fully compensates. It adds detailed meaning for both parameters: query explanation includes matching scope and wildcard limitation with alternative, and limit explains its purpose and default value. This significantly aids correct parameter usage.
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 searches for entities matching a query string. It differentiates from the sibling tool list_entities by explicitly noting that to get all entities, one can leave query blank or use list_entities. This distinguishes from other entity-related tools.
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 context on when to use the tool, specifically when a query string is available. It gives an alternative (list_entities) for listing all entities and notes that wildcards are not supported. Examples illustrate common use cases, but it does not explicitly exclude other scenarios or compare with other search-oriented siblings like get_entities_by_area.
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 fully carries the burden of behavioral disclosure. It explains area resolution behavior (inheritance from parent device), case-insensitivity, and the lean parameter effect. The return structure is also described, providing 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise and front-loaded with the main purpose. It includes structured parameter explanations and examples, which are helpful but add length. Could be slightly tighter, but overall well-organized.
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 3 parameters, no annotations, and an output schema, the description covers all necessary aspects: area matching behavior, optional filtering, return dictionary structure, and usage examples. It is complete for an agent to correctly invoke the 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 input schema has 0% description coverage, but the description explains all three parameters: area (mandatory, case-insensitive), domain (optional filter), and lean (default true, token-efficient). This adds significant meaning beyond the schema types and defaults.
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 gets all entities assigned to a specific Home Assistant area (room). It specifies the verb 'get', the resource 'entities by area', and distinguishes from siblings like 'list_entities' and 'search_entities_tool' by focusing on area-based filtering.
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 context with examples and explains the case-insensitive area lookup. It implicitly tells when to use this tool (filter by area) but does not explicitly mention when not to use it or suggest alternatives like search_entities_tool for name-based search.
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?
Since no annotations exist, the description fully describes behavior: filters combine with AND, stats are computed over filtered output, case-insensitive matching for level, integration, search_term. Return structure is detailed. No side effects mentioned but tool is read-only. Could mention error conditions more broadly.
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 Args, Returns, Examples, Best Practices. Purpose is front-loaded. Slightly lengthy but all sections are informative and earn their place.
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?
Covers purpose, all parameters, return format, usage guidance, and examples. No gaps given the tool's complexity and presence of output schema in description.
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 has 0% description coverage, so description provides all semantics: level specifies exact values, integration matching pattern, search_term as substring, lines for tail. Examples demonstrate usage. Completely compensates for schema lack.
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 Home Assistant error log for troubleshooting. It specifies the action ('get') and resource ('error log') and distinguishes itself from sibling tools like get_entity or call_service_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?
Best practices are provided, such as filtering server-side to save tokens and combining integration with level='ERROR'. The AND semantics of filters are explained. However, no explicit when-not-to-use or alternatives are mentioned.
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, but the description discloses behavior: returns a string version. It is read-only and non-destructive, which is clear from context. Example output is given.
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?
Extremely short: two sentences. Front-loaded with purpose. No unnecessary words. Every 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?
Given no parameters and a simple return value (string), the description is complete. Output schema exists, and description provides an example. No missing information.
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, so schema coverage is 100%. Description doesn't need to add parameter info; baseline of 4 for zero 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 the Home Assistant version', using a specific verb and resource. It distinguishes itself from sibling tools which are action-oriented or entity-related.
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?
While no explicit when-not or alternatives are given, the purpose is so straightforward that usage context is implicit. The tool is for retrieving version info, distinct from other 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, description carries full burden. It describes the tool as a read-summary operation with no side effects, and specifies the exact return structure (total_count, state_distribution, examples, common_attributes). No contradictions or missing critical behavioral details.
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?
Description is well-structured with a main sentence, Args, Returns, Examples, and Best Practices sections. Every section is informative and concise, 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 simple tool with 2 parameters and an output schema, the description fully covers input semantics, output structure, and usage guidance. No missing elements.
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 has 0% description coverage, so description compensates by explaining 'domain' with examples and 'example_limit' with purpose and default context. The Args section adds meaning beyond type and default.
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?
Description clearly states the tool gets a summary of entities in a specific domain, using a specific verb and resource. It distinguishes from sibling tools like list_entities and get_entity by focusing on summary statistics.
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?
Includes a Best Practices section advising to use this before retrieving all entities, which provides clear context for when to use it. Does not explicitly contrast with sibling tools but implies an alternative.
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 full burden. It details output structure, parameter semantics, and includes caution about usage. No mention of destructive effects or auth, but appropriate for a read-only history tool.
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?
Well-structured: purpose, args, returns, examples, best practices. Front-loaded with action, no wasted sentences. Every part earns its place.
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?
Complete for a history retrieval tool: covers input, output, usage recommendations, and efficiency. Output schema exists but description already details return fields, making it self-sufficient.
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 has 0% description coverage, but the description explains each parameter clearly: entity_id as target, hours with default and example. Examples add practical clarity.
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 the history of an entity's state changes', specifying the precise verb and resource. It distinguishes from sibling get_history_range by using hours-based retrieval.
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 best practices on hour limits, ideal use cases (discrete state changes), and data interpretation. Does not explicitly exclude alternatives or mention get_history_range, but context is 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 that it uses HA's recorder statistics and returns aggregated buckets (mean/min/max). Discloses that it survives short-term retention window. Does not explicitly state read-only nature, but purpose implies no modification. No annotations to contradict.
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?
Concise yet informative. Front-loaded with main purpose, then structured bullet points for usage, Args, Returns, Examples. Every sentence adds value. No unnecessary repetition.
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 output schema exists, the description still provides a summary of return structure (entity_id, period, start_time, end_time, statistics). Covers all needed context: what it does, when to use, parameters, and returns. No gaps.
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 has 0% description coverage, but the description compensates by explaining each parameter: entity_id requires a state_class, hours defaults to 24, period with allowed bucket sizes. Provides examples. Adds meaning beyond 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?
Clearly states it gets long-term aggregated statistics for an entity over the last N hours. Distinguishes from sibling get_history by specifying use cases for older data or aggregated values. Includes examples and mentions HA recorder statistics.
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 provides three conditions when to use instead of get_history: for data older than 10-day window, for aggregated values, and for high-frequency sensors. Also implies when not to use (short-term or raw history).
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 that it uses aggregated bucket data that survives the short-term retention window, indicating behavior for old data. It doesn't mention idempotency or rate limits, but the read-only nature is clear from context and sibling names.
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 Args, Returns, and Examples sections. Each sentence adds value, though the description is slightly longer than minimal. The examples are particularly helpful.
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 4 parameters, no annotations, and an output schema existing, the description covers all parameter semantics, return structure, and retention behavior. Examples complete the picture, making the tool's usage fully understandable.
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 has 0% description coverage, yet the description explains all four parameters in detail: entity_id (must be statistics-tracked), start_time (ISO-8601), end_time (ISO-8601, defaults to now), and period (enum of five values). Examples further clarify usage.
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?
Description clearly states 'Get long-term aggregated statistics for an entity over a date/time range' with a specific verb and resource. It distinguishes itself from the sibling tool `get_statistics` by emphasizing the explicit date window and retention behavior.
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 mentions 'Same data source as get_statistics, but with an explicit window' and provides a concrete use case example ('what was my power usage from Jan 1 to Jan 31?'). Also explains that it works for older data due to retention, helping the agent choose correctly.
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 must convey behavioral traits. It implies a read-only operation via 'Get' and the return of data without mentioning side effects, which is sufficient but could explicitly state no system modification.
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?
Description is well-structured with a clear purpose, return structure, examples, and best practices. All sections are concise and front-loaded, wasting no 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 zero parameters, an existing output schema, and a simple read operation, the description fully covers the tool's purpose, return structure, and usage context. No gaps remain.
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?
Tool has zero parameters and 100% schema coverage. The description appropriately omits parameter details, adding no extra burden. Baseline is 3 but the absence of parameters means the description is optimal.
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?
Description clearly states 'Get a comprehensive overview of the entire Home Assistant system', using a specific verb and resource. It distinguishes itself from siblings like domain_summary_tool by positioning itself as a high-level overview.
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?
Best Practices explicitly say to use this as the first call for unfamiliar instances and to follow up with domain_summary_tool for deeper dives. This provides clear when-to-use and alternative guidance.
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:

[![hass-mcp MCP server](https://glama.ai/mcp/servers/voska/hass-mcp/badges/card.svg)](https://glama.ai/mcp/servers/voska/hass-mcp)

Score Badge

Copy to your README.md:

[![hass-mcp MCP server](https://glama.ai/mcp/servers/voska/hass-mcp/badges/score.svg)](https://glama.ai/mcp/servers/voska/hass-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/voska/hass-mcp'

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