Get Home Assistant config summary

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is fully covered structurally. The description adds modest value by naming the returned facts and noting a single-instance scope, but says nothing about cost or latency, and it refers to an 'integration count' without acknowledging that the tool can instead return the full component list. With annotation coverage this strong, a 3 is warranted.

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?

A single sentence with zero filler, front-loading the key framing 'core facts about the instance.' It is efficient though terse, and the field list would read better as a scannable enumeration than a comma-spliced series. Nothing here is 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?

For a one-optional-boolean read tool with full annotation coverage, an enumerated description of returned fields (the only documentation of output, since no output schema exists) is close to sufficient. The gap is routing: complexity is low, but with 40+ siblings the description does not say where this config snapshot fits relative to check_config or get_system_health.

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 100% and there is only one optional boolean, so the baseline of 3 applies. The description's mention of a loaded integration 'count' slightly undercuts the parameter's purpose, since include_components expands that count into a potentially long enumerated list, an expansion only the schema explains. No additional parameter meaning is contributed by the prose.

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 enumerates exactly what the tool returns (version, location name, time zone, unit system, run state, safe mode, integration count), which is far more specific than the name alone. It stops short of distinguishing this from adjacent siblings such as get_system_health, check_config, or get_home_overview, so an agent must infer the boundary. It is also a noun phrase rather than a verb+resource statement, though the intent is unambiguous.

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?

There is no explicit when-to-use guidance: nothing says to call this before or after check_config, or how it differs from get_system_health or get_home_overview. No prerequisites or exclusions are stated. Usage must be inferred entirely from the returned-field list.

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