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

Goes beyond the readOnlyHint/openWorldHint annotations with a concrete cost model ($0.002 USDC per successful call via x402, failed calls not charged) and payment rails, which materially affects whether and how an agent should call it. It does not cover refresh cadence, result size or pagination, so not a 5.

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-loaded with the resource and source, then fields, then filtering, then price — a sensible order with no filler sentences. Slightly dense in the field enumeration and cost clause, but every element carries information.

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?

An output schema exists, so return structure need not be re-explained; the description nevertheless flags the returned fields and the optional cancel time. With only two optional free-text filters and full schema coverage, nothing an agent needs to call this correctly is missing apart from update frequency, which is minor for a broadcast feed.

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 baseline is 3, but the description adds value the schema lacks: it lists plausible category values (attack, attempted attack, suspicious activity, warning) and location examples (Gulf of Aden, Singapore Straits) despite no enums being defined. This helps an agent compose valid free-text filters.

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?

Names a specific source (ICC IMB Piracy Reporting Centre) and a specific resource (current piracy and armed-robbery broadcasts), then enumerates the fields returned (broadcast time, IMB id, category, location, narration, cancel time). That is clearly distinct from adjacent siblings such as logistics_dark_fleet_ais_gap, logistics_sanctioned_vessel_check or logistics_airspace_notam_feed.

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 only guidance is 'Filter by location or category words', which tells the agent how to narrow results but not when to prefer this feed over a related tool or what preconditions exist. Usage is implied by the data type rather than stated, and no alternative or exclusion is named.

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