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

Annotations already cover the read-only/idempotent/non-destructive profile, so the description rightly focuses on semantic caveats: 'No records does not mean sharks are absent', 'source checked time is not observation time', and 'returns data and source/freshness metadata'. These are genuinely useful behavioral disclosures an agent would otherwise miss, even if some of the jellyfish/man-of-war material reads as boilerplate.

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 text is bloated and repetitive: 'No records does not mean sharks are absent' appears twice in near-identical form, units and NOAA Chesapeake sea-nettle forecast notes are irrelevant to this tool, and the important scoping sentence is buried mid-paragraph. Front-loading is poor and several sentences do not earn their place.

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 usefully states that it returns data plus source/freshness metadata, and it sets expectations about absence of records and observation-date fidelity. Combined with the parameter coverage, an agent has enough to call it correctly, though the disjointed organization makes it harder to extract.

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%, so the description must carry the load and largely does: bbox is described as the spatial narrowing mechanism and limit is documented with default 20 and maximum 100, matching the schema constraints. It doesn't explain the bbox string format (lat/lon ordering), which is the one real 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 specifies the resource (published Florida shark research occurrences) and the fields returned (observation dates, location uncertainty, source credits, licenses). It distinguishes itself from live tracking and beach warnings, and from the sibling get_jellyfish_observations by being acoustic detections/tag releases. The verb is implied rather than stated and the rambling dilutes the signal, but an agent can identify the tool.

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?

It gives concrete usage for parameters ('use bbox to narrow the published sample', limit default 20 / max 100) and a clear negative scope (not live tracking, not beach warnings). However it never names an alternative tool or states the condition under which an agent should reach for this versus get_jellyfish_observations or get_observations, leaving routing to inference.

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