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

With no annotations, the description carries the full burden and does well: it discloses ordering (newest first), the upstream data source (DefiLlama hacks dataset), and the fields returned. It also flags a real classification quirk — NEAR Intents is filed under BSC by DefiLlama but counted here — which is exactly the kind of caveat annotations would otherwise cover. It omits any statement about read-only safety, rate limits, or pagination limits.

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 scope, output fields, and filter semantics are front-loaded in the first sentence, with the use cases closing it out. It is dense but every clause adds information; the parenthetical example is slightly long but justifies itself by explaining an upstream data quirk.

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?

For a 4-parameter, optional-only read tool with no output schema, the description covers what is returned, how results are ordered, and what the filters mean. Missing only the collection-vs-single-item routing relative to get_incident and any note on default/maximum result counts.

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 the baseline is 3; the description earns above that by defining the semantics of the relevance enum beyond the schema's terse 'Default near' — 'near' means hacks on NEAR/Aurora/NEAR protocols, 'related' means NEAR Catalog projects hacked on another chain. That distinction is not derivable from the schema alone.

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 and resource — security incidents from DefiLlama's hacks dataset — and enumerates the returned fields (date, amount lost and returned, technique, chains, source). That is far more specific than a tautology, but it never contrasts itself with the sibling get_incident, so an agent must infer that 'list' returns a collection while 'get_incident' returns 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?

It gives two concrete triggering scenarios: 'before integrating a protocol' and answering 'has X been exploited'. There is no when-not guidance and no explicit routing to get_incident for a single known incident, which keeps it short of a 5.

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