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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds real context beyond them: data may carry 'unavailable states', source sample dates must be preserved, satellite clarity is a relative index not true dive visibility, and it returns source/freshness metadata. These caveats meaningfully affect interpretation of results.

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?

Front-loads the purpose and keeps to a few sentences, but the telegraphic unit string ('Units: ft, kt, s, F, mi; directions FROM.') reads awkwardly and is not clearly tied to specific fields. It is compact but not maximally clear.

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 does state that it returns data plus source/freshness metadata and lists units, which partially covers return semantics. However, it leaves the sole required parameter and the meaning of individual returned fields under-explained for a data-heavy tool.

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 coverage is 0% and there is one nested required parameter ('query.spot'). The description only says 'for a verified spot' without explaining the spot identifier format, how to obtain one, or the nested structure constraint, leaving the parameter effectively undocumented.

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?

States a specific verb+resource ('Red tide samples for a verified spot'), which is clearly scoped to a single data product. It doesn't explicitly distinguish itself from the many adjacent marine-biology siblings like get_algae_reports or get_fish_kills, so an agent must infer the difference.

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 phrase 'for a verified spot' implies a precondition, but there is no explicit when-to-use, when-not-to-use, or alternative routing against the closely related get_algae_reports/get_visibility tools. An agent has no guidance on tool selection.

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