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

Goes beyond the annotations: the readOnly/idempotent profile is already in annotations, but the description adds the safety caveat 'Coordinates are geographic locations, not safe navigation routes,' plus units (ft, kt, s, F, mi), direction convention (FROM), and the fact that source/freshness metadata is returned. It does not discuss pagination or response size.

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 identity statement, then usage, then the map use case, then units/caveats — a logical order. The map-panel sentence is the most expendable but still conveys a distinct entry point. No filler or repetition.

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 covers the return payload (lat/lon, kind, region, NOAA stations, source/freshness metadata), the downstream id handoff, and unit conventions. The remaining gap is that the region/homeZone filtering inputs are not described, which matters for a nested-object parameter.

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 reported at 0% and the single parameter is a nested query object. The description only illuminates one of its three fields ('include=status adds the current-hour go/caution/nogo band per activity'). The region filter and homeZone are never mentioned in prose, though the region enum values do live in the schema.

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?

Specific verb+resource: 'Every named Florida spot the app scores, with its lat/lon, kind, region and the NOAA stations used for it.' The title enumerates spot kinds (inlets, beaches, sandbars, reefs, offshore), so scope is clear. It does not, however, explicitly distinguish itself from siblings like find_beaches, find_inlets, list_sandbars, or find_reefs, leaving the agent to infer that this is the master list versus a filtered one.

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 a concrete use case ('Use this for a map of verified coastal spots: the MCP app panel renders an interactive Florida map') and chains to downstream tools ('Use the returned id with conditions, forecast, tides, hazards and briefing tools'). It states when to use it but offers no when-not or explicit alternative (e.g., versus find_beaches for a single spot kind).

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