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

Beyond readOnlyHint/openWorldHint, the description discloses the access model that materially changes behavior: confirmed tier is free with no credentials and a hard 20-item cap, while suspected/all require x402 payment, an API key, or a wallet token on a paid plan. Ordering (newest update first) and the informational-not-advice disclaimer are also stated. Pagination/error behavior and the polling/dedupe nuance are left to the schema rather than the description.

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?

Purpose and signal types are front-loaded in the first sentence, followed by payload shape, then usage triggers, then access terms. The parenthetical pricing block is dense and partly duplicates the tier parameter description, but no sentence is fully wasted.

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 carries the return-shape burden and does so: one item per incident listing tier, exchange, headline, USD at risk, assets, evidence signals, timeline, and record links, plus sort order. Access gating and the free-tier cap are also covered, so an agent knows what it will get and what it will cost before calling.

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 100%, so all four parameters are already documented in the schema, including tier semantics and the since polling guidance. The description restates tier (suspected = unconfirmed, confirmed) and echoes the free-feed 20-item cap, adding little beyond the structured fields — baseline 3 is appropriate.

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 states a concrete verb+resource (exchange hack and drain alerts from an incident engine) and enumerates the signal types it covers (large outflows, withdrawal halts, researcher posts, exchange statements). It never names the near-duplicate sibling muhabbit_alert (singular), so the agent cannot tell from the description alone which of the two to open for a single incident.

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?

Explicit trigger phrases are given — 'is an exchange being hacked right now?' and 'any exchange incidents since T?' — which map cleanly onto the free default feed versus the since-parameterized query. There is no stated exclusion or named alternative for looking up a single known incident, so routing vs muhabbit_alert is left implicit.

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