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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds provenance ('Sourced from the NDBC active-station inventory'), which usefully signals that decommissioned stations are excluded, plus the filter axes available. It does not mention pagination behavior or result shape, but the limit parameter partly covers truncation.

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?

Two sentences, zero filler; the inventory/scope statement comes first and the routing/authority claim second. The em-dash enumeration of station classes earns its length by clarifying scope.

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 annotations covering only the safety profile, the description adequately conveys what the call returns (station records, ids) and why you'd call it. Minor gap: no note on ordering beyond proximity or on what fields a station record carries, which an agent may want when parsing results.

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 100%, so all ten parameters are already documented, including the near_latitude/near_longitude sorting hint. The description's filter list (bounding box, name, owner, type, measurements) mirrors the schema rather than adding format or interaction detail, so baseline 3 applies.

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 (list active NDBC stations) and enumerates the station classes it covers (moored buoys, C-MAN, DART, partner platforms). It also explicitly differentiates itself from siblings by framing itself as the id source that ndbc_latest_obs consumes, so an agent can separate it from ndbc_station_history without opening schemas.

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 an explicit use case ('which buoy is nearest X') and a concrete downstream dependency (finding the station id that ndbc_latest_obs needs), naming the sibling tool. This is the when-and-why, not just a restatement of capability.

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