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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavioral context the annotations cannot: freshness.stale=false does not mean every source is usable, QC-failed sources must still be reported, model sea height is not breaking surf height, high tide is not necessarily slack current, and lightning must be phrased as observed/not detected rather than a safety guarantee. These are real data-quality and output-interpretation behaviors, not restatements of the hints.

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?

Purpose is correctly front-loaded in the opening sentence, but the body is a dense block that mixes usage, interpretation rules, activity-key taxonomy and caveats without grouping, and the units line is stated twice ('ft, s, kt, deg FROM, F' then 'ft, kt, s, F, mi; directions FROM'). Content is mostly substantive but the repetition and lack of structure make it harder to scan than it needs to be.

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?

With no output schema, the description carries the return-value burden and does so: hourly rows with tide/current and score reasons, 7 daily score rows, best windows, and source/freshness metadata. It also anticipates common misuse (per-activity fallback, unverified launch status, depth vs route clearance), leaving only finer return-field detail unspecified.

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?

Top-level schema description coverage is reported as 0%, so the description must carry weight, and it does: it defines units (ft, s, kt, deg FROM, F, mi), frames spot vs lat+lon as alternatives, and adds rules beyond the schema constraints such as 'omit boat unless the user supplied or confirmed it' and that kiteMinWindKt/kiteMaxWindKt are rider-supplied and never inferred. The nested properties do carry their own descriptions, which offsets the header-level 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 first sentence states a specific verb+resource (hourly forecast for a spot or lat+lon) and enumerates exactly what is returned: waves, swell/wind-wave split, wind, gusts, tide, current, precip/thunder, plus go/caution/nogo scores and daily rows. It also names a sibling and the condition that selects it (kitesurfing -> get_conditions with kiteStyle/kiteExperience), so an agent can place it against alternatives 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?

Gives concrete operating guidance (one call per spot for a time-window comparison, request only the hours needed) and routes kitesurfing to get_conditions, with a pointer to kiteboarding for screening. It stops short of explicitly contrasting this tool with close siblings such as compare_spots, get_activity_scores or get_surf_forecast, so it is clear context rather than full when/when-not coverage.

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