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

Annotations already cover read-only/idempotent/safe, so the description earns credit for adding real caveats: unavailable/QC-failed sources must be reported even when freshness.stale=false, fresh does not mean every source is usable, and a point depth cannot prove route clearance. These are substantive limits beyond the annotation set, though they are tangled with unrelated tool guidance.

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 purpose sentence is front-loaded and final, but the body is a sprawling block that mixes units, kiteboarding, lightning, tide and surf guidance belonging to sibling tools. Large portions do not earn their place in this tool's definition and obscure the core behavior.

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 burden and does state it 'Returns data and source/freshness metadata' plus interpretation rules, which is adequate for a single-point lookup. It remains thin on what fields come back and on input param detail.

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 0%, and the only parameter is a nested lat/lon object. The description adds the meaningful context that the coordinate must be a Florida point (matching the schema's 24-31 / -88--78 bounds), but it never describes lat/lon ordering or format, so it only partially 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 opening sentence states a specific verb+resource ('Actual NOAA ENC chart depth and optional DEM depth at a Florida coordinate, with charted hazards, channel context and restriction zones'), so an agent can tell it is a point depth-plus-context lookup. It only implicitly differentiates from siblings via 'A point check does not prove clearance along a route,' which gestures at check_route_conditions without naming it.

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 one genuine routing hint: a point check does not prove route clearance, implying check_route_conditions for route work. The rest of the guidance ('for kitesurfing use get_conditions...', lightning phrasing, activity keys) is about OTHER tools and does not tell the agent when to use get_depth versus nearby lookups like get_hazards or find_anchorages.

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