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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds substantial behavior beyond them: the sources queried, region-level resolution, the shape of each warning (issuing service, validity window, level, official text in the publishing language), the meaning of an empty list, and the 15-minute cache with no third-party call when warm.

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 what the tool returns and which sources feed it, and the trailing sentences on empty-list semantics and caching earn their place. Slightly verbose with a stray fragment structure, but no filler.

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 enumerates the returned warning fields, explains the empty-list case, and discloses the cache behavior. It is nearly complete, missing only guidance on the coordinate inputs, which it cannot afford to omit at 0% schema coverage.

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% for the two required coordinates, so the description carries the full burden. 'For a point' only loosely implies latitude/longitude and gives no format, ordering, or coordinate-system detail to compensate for the undocumented parameters.

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 and resource ('Marine and weather warnings in force for a point') and specifies the aggregation scope ('from every official source at once') with named sources. It also differentiates itself from sibling warning/forecast tools by resolving MeteoAlarm warnings to the actual region rather than the whole country.

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?

'Check this before any passage or coastal activity' gives clear situational guidance for when to reach for the tool. However, it never names or contrasts with siblings like get_marine_bulletin or get_storm_risk, so there are no explicit exclusions or alternatives.

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