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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: that results come with source/availability metadata and that an empty result set must not be read as confirmed safe conditions. That is a real behavioral caveat not present in annotations.

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 core purpose and the empty-report caveat are front-loaded and well placed. However, the units/directions sentence and the metadata sentence are generic boilerplate that is only marginally relevant to a notices feed, diluting an otherwise tight description.

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, no annotation gaps filled beyond safety hints, and 0% schema description coverage on a nested query object, an agent gets no help on filtering (bbox format, category vocabulary) or on what a notice record looks like. The description is incomplete for a tool whose only entry point is an undocumented nested 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?

There is one parameter object (query) with nested bbox and category properties, and schema description coverage is 0%. The description says nothing about how to format bbox, what category values are accepted, or what happens when query is omitted. The 'Units: ft, kt, s, F, mi; directions FROM' sentence is about data values, not parameters, so it does not compensate.

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 description names a specific verb+resource: USCG local notices to mariners from a published agency dataset. It is distinguishable from sibling tools like get_marine_alerts or get_hazards by naming the issuing agency and dataset. It stops short of explicitly contrasting with those siblings.

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 caveat 'Empty reports do not establish safe conditions' implies this tool is not a safety guarantee, which is useful. But there is no explicit guidance on when to call this instead of get_marine_alerts, get_hazards, or check_route_conditions. Usage must be inferred from the name.

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