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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description still adds real behavioral context: stale=false does not mean every source is usable, kiteboarding launch status is unverified and no overall kite score is implied, lightning is 'flashes observed' never a safety guarantee, and several interpretation traps (model sea height vs breaking surf height, MLLW gauges not establishing channel depth) are disclosed.

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 payload list is correctly front-loaded, but the text repeats itself: the kiteboarding paragraph appears twice and the activity-key list ('kite, surf, skim...') appears verbatim twice, adding no new information. Length is partly justified by tool complexity, yet those verbatim repeats are dead weight in an otherwise dense description.

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 and a nested query object, the description must describe what comes back, and it does: contents, units (ft, kt, s, F, mi, directions FROM), source/freshness metadata, and the caveats needed to interpret those returns. Nothing essential for correct invocation is missing.

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 counted schema coverage is 0% at the top level, so the description must carry parameter meaning, and it largely does: view=summary vs full, 'omit boat unless the user supplied or confirmed it', supplying kiteStyle/kiteExperience/kiteMinWindKt/kiteMaxWindKt, and 'never infer the rider wind range'. It adds rules the schema lacks, though the kite parameter block is duplicated rather than expanded.

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?

Opens with a specific verb+resource ('The full conditions bundle for a named spot') and enumerates every payload it returns (waves, wind, tide, scores, 7-day hourly, tides, windows, alerts, hazards, lightning, briefing). It also names a sibling it is not ('For an arbitrary lat/lon use get_point_conditions'), so an agent can separate it from get_point_conditions and the individual get_tides/get_hazards tools.

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?

Explicit routing: 'Start here for a current spot question with view=summary', 'Prefer view=summary unless you need every hour', 'Avoid duplicate hazard/tide calls unless a needed detail is absent', and the lat/lon alternative is named. Both when-to-use and when-not-to-use are stated.

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