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

With no annotations present, the description carries the full burden and does add useful traits: it is free, it returns an AQHI value on the 1–10+ scale plus a risk level, and it resolves to the nearest station rather than an exact postal code match. It does not state what happens for invalid or non-Canadian postal codes, coverage gaps, or whether results are cached/stale beyond 'latest', leaving meaningful behavioral gaps.

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 efficient sentence that covers cost, return values, scale, and resolution method. Leading with 'FREE.' is slightly off-target front-loading since the resource identification is more important, but nothing is padded or redundant.

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-parameter, no-output-schema lookup tool, the description supplies what an agent needs: what is returned, what the scale means, cost, and that lookup is by nearest station to a Canadian postal code. Only minor edge-case behavior (invalid or out-of-country postal codes) is missing, which is a small gap for this complexity level.

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 the schema only tells the agent the parameter is a string named 'postal_code'. The description adds real meaning by specifying it is a Canadian postal code used to locate the nearest station. It still omits format guidance (e.g., A1A 1A1) and validation behavior, so it partially but not fully compensates for the coverage gap.

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 names a specific resource (AQHI score and risk level) and scope (latest reading at the station nearest a Canadian postal code). 'Latest' implicitly distinguishes it from the sibling aqhi_forecast, though it never names that sibling explicitly. An agent can tell what the tool returns without opening the schema.

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 word 'Latest' implies this is for current conditions rather than a forecast (aqhi_forecast), which is useful implied guidance. However, there is no explicit when-to-use statement, no mention of when to prefer sites_check or region_watch, and no prerequisites such as 'only for Canadian addresses'.

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