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

No annotations are provided, so the description carries the disclosure burden. It explicitly lists the data dimensions and the normal/actual/forecast comparison, notes that sun and moon are computed exactly rather than forecast, and reveals an aggregation cost: 'three upstream requests regardless.' It does not explicitly state read-only behavior, but the 'record' framing and absence of mutation language make that apparent.

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 three short paragraphs that front-load the normal/actual/forecast framing before listing the data and usage context. Every sentence contributes scope, data, or usage guidance, though the opening is poetic rather than purely operational. It is concise enough for an 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?

An output schema is present, so explaining return values is not required. The description covers the data dimensions, time horizons, aggregation behavior, and usage rationale, while the schema handles block identification and billing prerequisites. It could name sibling alternatives more explicitly, but 'One call covers every measure' partially compensates.

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 already describes block and npub in detail, and the description adds no parameter-specific guidance beyond reinforcing the block-as-ground concept. It does not explain dpop_token or add constraints beyond what the schema provides. With 67% schema description coverage, the description's lack of parameter detail is acceptable but not additive.

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 identifies the resource (a block/ground) and the delivered data: temperature, dew point, rain, wind, sunshine, day length, sun, and moon, each against normal, actual, and fortnight-ahead values. It differentiates itself from the many specialized siblings by emphasizing 'One call covers every measure.' It is slightly indirect because it relies on 'says' and 'record' rather than a direct verb like 'retrieves' or 'returns.'

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 positions the tool as the complement to heat/degree-day data: 'Growers read these together with the heat,' and it explains when high dew points or a dry August make degree-day totals insufficient. It also implies broad use instead of multiple specialized calls with 'One call covers every measure.' It does not name specific sibling tools or explicit exclusions, but the usage context is clear.

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