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

There are no annotations, so the description must carry the full burden of behavioral disclosure. It mentions 'low-level API access' but does not disclose potential side effects, permissions, reversibility, or error handling. Given the generic nature of the tool, this is insufficient transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured with clear sections (Args, Returns, Examples). It avoids unnecessary verbosity while providing essential usage information, making it easy to parse.

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

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

For a generic service-call tool, the description provides sufficient context: what the tool does, how to use parameters, what to expect in the return value, and clear examples. It does not cover edge cases or failure modes, but given the broad scope ('any service'), the level of detail is adequate.

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

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

The description explains each parameter (domain, service, data) with examples, adding meaning beyond the bare schema (which only has titles). It clarifies how to structure the data dictionary, though it does not exhaustively list allowed service names or data fields, which is reasonable for a generic tool.

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

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

The description clearly states the purpose: 'Call any Home Assistant service (low-level API access)'. It identifies the verb (call) and the resource (Home Assistant service), and distinguishes itself from sibling tools that are more specific (e.g., list, get, update).

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

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

The description provides examples of usage but does not explicitly state when to use this tool versus more specific sibling tools. It implies it is a catch-all for services without dedicated tools, but this is not explicitly stated, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description must convey the tool's behavior. It states it returns a summary, which implies a read-only operation, but it does not explicitly mention that it is non-destructive, any side effects, or permissions required. Given the read-only nature, a 3 is appropriate as it covers the essential behavior but lacks explicit guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-organized. It includes the purpose, parameter descriptions, return structure, an example, and a best practice—all in a compact format with no unnecessary verbiage. The structure is clear and easy to parse.

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

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

The description covers the tool's purpose, arguments, return values, and a usage example, which is sufficient for a simple summary tool. It does not discuss error handling or edge cases, but these are not critical for the tool's primary function. The return structure is described in the 'Returns' section, making the output expectations clear.

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

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

Both parameters are explained in the description: 'domain' is described as 'The domain to summarize' with examples, and 'example_limit' as 'Maximum number of examples to include for each state.' This provides sufficient meaning beyond the raw schema, though the concept of 'state' is not elaborated further.

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

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

The description clearly states the tool's function: 'Get a summary of entities in a specific domain.' It uses a specific verb ('get') and resource ('summary of entities'), and is distinct from sibling tools like list_entities or get_entity by focusing on aggregated summary data rather than individual records.

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

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

The description provides a specific best practice: 'Use this before retrieving all entities to understand what's available.' This gives clear guidance on when to use the tool, though it does not explicitly mention when not to use it or compare with alternative tools. The example also demonstrates typical usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description is the sole source of behavioral disclosure. It mentions the action and return value but does not disclose side effects, required permissions, error behavior for invalid actions or missing entities, or whether the operation is reversible. For a mutation tool, this is a safety-relevant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a one-line summary, argument breakdown, return statement, examples, and domain-specific details. It remains scannable, though the domain-specific section slightly duplicates what the examples already show (e.g., brightness appears in both). No unnecessary filler.

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

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

For a tool with no annotations and no output schema, the description thoroughly covers parameter semantics but leaves important gaps: the return value is vaguely 'The response from Home Assistant', error and edge-case behavior is absent, and it does not clarify when to use this versus call_service_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.

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

Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains each argument, provides concrete entity_id examples, enumerates valid action values, defines params as an optional dictionary, and gives domain-specific parameter details (brightness, temperature, position, etc.) — far exceeding the bare schema.

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

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

The opening sentence clearly states the tool's function: 'Perform an action on a Home Assistant entity (on, off, toggle)'. The examples with entity_id and action values make the scope unmistakable, and the domain-specific parameters distinguish it from read tools like get_entity and the broader 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.

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

The examples and domain-specific parameter list imply usage contexts (lights, covers, climate, media players), but the description never explicitly compares this tool to sibling call_service_tool or states when to prefer one over the other. The usage guidance is mostly inferred rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the full disclosure burden and largely succeeds: it reveals the non-obvious parent-device inheritance behavior, case-insensitive matching, and the meaning of the lean parameter's token efficiency. It clearly describes the return structure. Only minor gaps remain (e.g., behavior for nonexistent areas, pagination), keeping it just short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a one-line summary followed by standard docstring sections (Args, Returns, Examples) that are easily scannable. It is slightly verbose for a tool description, but every section earns its place, and the examples are instructive without being padded.

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

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

For a 3-parameter query tool, the description is thorough: all parameters are documented with extra semantics, the return structure is specified, behavioral edge cases (inheritance, case folding) are covered, and actionable examples are provided. With an output schema available, nothing material is left unaddressed.

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

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

With 0% schema coverage, the description must compensate — and it does thoroughly. It adds case-insensitivity semantics to 'area', clarifies 'domain' as a secondary filter with an example, and explains 'lean' as producing 'token-efficient entity records.' The examples further demonstrate parameter composition, adding meaning well beyond the bare boolean/string types in the schema.

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

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

"Get all entities assigned to a specific Home Assistant area (room)" uses a specific verb+resource and clearly scopes the operation to area-based lookups, distinguishing it from siblings like get_entity (single entity), search_entities_tool, and domain_summary_tool. The opening line is immediately identifiable in purpose with no ambiguity.

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

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

The description provides solid functional context (case-insensitive matching, parent-device inheritance) but never explicitly guides tool selection versus overlapping siblings like search_entities_tool, list_entities, or domain_summary_tool. Usage is implied through the detailed behavior rather than stated — no when-to-use or when-not-to-use guidance or named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains optional field filtering, the meaning of detailed=True, and provides concrete examples. It does not discuss error behavior or permissions, but for a simple read-oriented getter the core behavior is transparently described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-sentence summary, followed by a compact Args section and three illustrative examples. Every sentence adds value, and the structure makes the tool's behavior immediately scannable.

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

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

For a tool with three parameters, no output schema, and no annotations, the description covers the main usage patterns and return behavior reasonably well. It could be more explicit about the exact shape of the response for a basic state check, but the examples and detailed flag explanation make it sufficiently complete 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.

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, and it does thoroughly. Each parameter is explained with type context and examples: entity_id is shown as 'light.living_room', fields as ['state', 'attr.brightness'], and detailed is described as returning all fields without filtering. 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.

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

The description opens with a specific verb and resource: 'Get the state of a Home Assistant entity with optional field filtering.' This clearly distinguishes it from sibling tools like list_entities or search_entities_tool, which operate over collections rather than a single entity.

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

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

The description implies usage for retrieving a single entity's state, and examples clarify common calls, but it does not explicitly state when to prefer this tool over alternatives like list_entities or get_entities_by_area, nor does it mention exclusions. Usage guidance is only implied, not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 discloses the return structure and offers practical advice (e.g., keep hours 24-72 for token efficiency), but it does not explicitly state that the operation is read-only, what happens on invalid entity IDs, or any rate limits. This partial disclosure warrants a middle score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized into Args, Returns, Examples, and Best Practices, with the core purpose front-loaded. It is slightly verbose in the return section, but every sentence adds useful context and the structure is easy to scan.

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

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

For a simple read tool with a 2-parameter schema, the description covers purpose, parameters, output structure, examples, and performance guidance. However, it omits error conditions and does not clarify how this tool differs from the sibling get_history_range, leaving a contextual gap.

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

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

With 0% schema description coverage, the description fully compensates by explaining entity_id and hours, including the default value and example usages. This goes far beyond the schema field names and provides clear operational semantics.

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

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' with a specific verb and resource, and the arguments define the scope. It does not explicitly contrast with the sibling get_history_range, so it cannot earn a 5.

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

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

The description provides 'Best Practices' about entity types and token efficiency, but it never states when to use get_history versus the alternative get_history_range or get_statistics. Without explicit exclusionary or alternative guidance, usage context remains unclear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries the burden of behavioral disclosure. The description does mention the return value type (a string) and provides an example format, which is helpful. However, it does not disclose any potential side effects (unlikely), authentication requirements, or error behavior. For a simple read-only tool, this is somewhat acceptable, but it could be more explicit about being a read-only, non-mutating operation. With no annotations, a score of 3 is reasonable as the description adds value by specifying the output format, but it lacks deeper 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one line stating the purpose and one line describing the return value with an example. Every sentence earns its place. It is front-loaded with the purpose, making it easy for an agent to quickly understand what the tool does.

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

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

The tool is extremely simple: no parameters, no complex logic, and it has an output schema. The description is complete enough for an agent to understand what it does and what it returns. However, it lacks any guidance on when to use it (e.g., 'Use to verify connectivity' or 'Use before version-specific calls'). Given the complexity is low, this is nearly complete, but a small piece of usage context would make it fully complete.

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

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

The tool has zero parameters, and schema description coverage is 100% (auto). The description doesn't need to explain parameters. It does add meaning by describing the return value and providing an example, which is beneficial given the tool's simplicity. With no parameters, the baseline is 4, and the description meets that baseline by clarifying the output.

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

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

The description clearly states the tool's purpose: to get the Home Assistant version. It uses a specific verb and resource, and it's distinct from the sibling tools (e.g., system_overview, get_error_log). The description could be improved by explicitly stating that it returns the core version string of Home Assistant, but the purpose is evident.

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

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 any specific context or prerequisites. For a simple version-check tool, some implied usage exists (e.g., checking compatibility before calling other tools), but it is not explicit. Given the sibling tools like system_overview or restart_ha, it might be useful to note that this tool is a lightweight way to confirm the Home Assistant instance is accessible and its version.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description must carry the burden of disclosing behavior. It states it returns a list of dictionaries with specific fields, which is useful. However, it does not mention that the operation is read-only (implied but not stated), any performance implications, or potential for large result sets. The description adds minimal behavioral context beyond the return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description has redundancy: the first sentence 'Get a list of all automations' is repeated by 'This function retrieves all automations'. The 'Examples' section is not an example but a restatement of behavior. The Returns section is informative, but the overall structure could be more efficient without losing meaning.

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

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, no nested objects) and availability of an output schema, the description provides sufficient coverage: it states exactly what it returns and the fields included. It lacks details like ordering or pagination, but these are likely irrelevant for a list of automations. The description is complete enough for an agent to understand the tool's function and output.

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

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

The tool has zero parameters and the schema coverage is 100% (vacuously). The description correctly omits parameter details since there are none. According to the calibration, a baseline of 4 is appropriate for 0 parameters, and the description does not need to compensate for anything missing.

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

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

The first sentence clearly states the verb ('Get a list') and the resource ('all automations from Home Assistant'). The second sentence reinforces the scope and includes specific fields ('IDs, entity IDs, state, and display names'). This distinguishes it from sibling tools like list_entities or list_dashboards, which target different resource types.

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

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

The description implicitly communicates that this tool is for automations, not other entities, which distinguishes it from sibling tools. However, it does not explicitly state when not to use it or provide alternative guidance. Given the simplicity of the tool, the implied context is adequate but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 discloses that search_query does not support wildcards, that default returns lean formatting, and that detailed=True returns all fields. It also notes that to get all entities, leave search_query empty. This is good behavioral context, though it doesn't mention pagination or rate limits, which are not critical for a list operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for Args, Returns, Examples, and Best Practices. It is front-loaded with the core purpose and then provides details. It is slightly verbose with the best practices section, but each sentence adds value. The examples are concise and illustrative.

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

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

Given the tool's complexity (5 optional parameters, no required ones) and the presence of an output schema, the description is fairly complete. It covers parameter semantics, return format (lean vs detailed), and usage guidance. It could mention the output schema's structure, but the output schema itself provides that. The description adequately prepares the agent for correct invocation.

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

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 each parameter's purpose: domain, search_query (with wildcard note), limit (default 100), fields, and detailed. It also provides examples showing parameter combinations. This adds significant meaning beyond the schema, though it could be more explicit about the fields parameter's format.

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

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 list of Home Assistant entities with optional filtering.' It specifies the resource (Home Assistant entities) and the action (list), and distinguishes it from siblings like search_entities_tool and domain_summary_tool by mentioning filtering and domain overviews.

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

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

The description provides explicit usage guidance: it includes best practices such as 'Prefer domain filtering over no filtering' and 'For domain overviews, use domain_summary_tool instead of list_entities.' It also explains when to use detailed=True and how to get all entities, which helps the agent choose between this and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the behavioral burden. It discloses the significant side effect of disrupting all operations and states the return type, which is key information for an agent deciding to invoke it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, containing only the essential elements: action, warning, and return. No redundant or extraneous text, and the structure is clear with a labeled warning and return.

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

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

The description covers the core behavior (restart), the side effect (temporary disruption), and the return (result). Given the tool's simplicity and lack of output schema, this is sufficiently complete without being verbose.

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

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

The input schema has zero parameters, so the description's silence on parameters is appropriate. According to the rubric, a baseline of 4 applies when no parameters exist, and no additional explanation is needed.

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

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

The description clearly states the tool's action ('Restart Home Assistant') using a verb+resource format, and it is distinct from all sibling tools which focus on dashboards, entities, and other specific operations.

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

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

The warning about temporary disruption implies a maintenance context, but there is no explicit statement of when to use this tool versus alternatives (e.g., when a restart is needed vs. other recovery actions). The guidance is implicit rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the burden of explaining behavior. It discloses the return structure, the lack of wildcard support, and the effect of leaving query blank, but does not explicitly state read-only nature, though it is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with sections for args, returns, and examples. It is somewhat detailed but each part adds value, making it appropriately concise without being overly verbose.

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

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

Given the tool's complexity and the lack of annotations, the description is remarkably complete. It covers functionality, parameters, return format, limitations, and alternatives, leaving little ambiguity for the agent.

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

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

The description adds significant meaning to both parameters: query is explained as matching against IDs, names, and attributes, and limit is defined as a maximum result count with a default. It also clarifies edge cases like blank query.

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

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

The description clearly states the tool's function: searching for entities by a query string. It also differentiates from sibling tools like list_entities by explicitly noting the alternative for retrieving all entities.

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

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

The description provides explicit guidance on when to use the tool, including a note about wildcard limitations and a clear alternative (list_entities) for fetching all entities. Examples illustrate typical usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 explains the return structure in detail (dictionary with keys) and notes that area distribution is included 'if available'. While it doesn't disclose any side effects or performance implications, for a read-only overview tool this is adequate; a slight deduction for not noting potential size or latency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Returns, Examples, and Best Practices sections, and it is appropriately sized for the complexity. It is not overly verbose, but the 'Examples' line is redundant with the 'Returns' section, which costs one point.

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

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

The tool has no parameters and an output schema is present, so the description's role is largely to explain the output semantics and usage context. It does both excellently: it enumerates all returned fields and gives clear guidance on when to use it. The output schema covers the structure, and the description adds the 'if available' nuance and the workflow suggestion.

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

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

The tool has zero parameters, so there are no param semantics to document. The description adds value by explaining the return structure, which the input schema cannot do. Baseline for 0 params is 4, and the description fully compensates by detailing what the output contains.

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

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

The description starts with a clear verb and resource: 'Get a comprehensive overview of the entire Home Assistant system.' It distinguishes from siblings by explicitly positioning it as the first call for exploration, and it lists the returned fields, making the purpose unmistakable.

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

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

The Best Practices section explicitly says to use it as the first call when exploring an unfamiliar instance and to then use domain_summary_tool for deeper dives. However, it doesn't explicitly state when not to use it or name alternatives beyond domain_summary_tool, though the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.