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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds a genuinely non-obvious trait: the first call for an area may return 'preparing' and become 'ready' a few minutes later, implying polling. It also discloses the ten-year aggregation window and the geographic scope ('the area round the place'). It stops short of saying how long results are cached or whether 'preparing' responses consume quota.

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?

It is a single dense sentence stacking five distinct statistics, which is hard to parse and front-loads the payload rather than the action. The phrase 'as its page shows it' is vague filler that does not help an agent decide or invoke. The async caveat at the end is well placed, but the body could be a short list.

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 exists, so most of the long enumeration of return values is redundant effort, while the one thing that is not in structured data — the preparing/ready lifecycle and whether to re-call — is mentioned but not elaborated (no retry interval, no indication of how long results persist). With 100% schema coverage and a single optional parameter, the definition is serviceable but spends its words in the wrong place.

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%, with both month and bay_id fully documented including the default-to-every-month behavior and the find_anchorages provenance of bay_id. The description adds nothing about parameter syntax or how selecting one month interacts with the ten-year aggregation, so the baseline 3 applies.

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 the resource (wind climatology at a place) and enumerates the specific statistics returned: monthly counts of nights reaching 20 kt and 30 kt, per-year min/max, prevailing directions, and strongest gust over ten years. It is unmistakably a read of historical wind statistics rather than an anchorage search, though it never names the sibling tools it differs from.

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 statement of when to call this versus get_bay_evidence or find_anchorages, and no prerequisites or exclusions. The only actionable guidance is the async note ('first call can answer preparing, then ready a few minutes later'), which tells the agent to retry but not when this tool is the right choice.

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