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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds two genuinely useful behaviors — results are dated by the FIRST report of a story, and unknowns are stated explicitly rather than guessed — but says nothing about pagination, response size, or latency for a 30-day multi-market scan.

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?

A single ~110-word run-on sentence that stuffs a long taxonomy of cause sources (whale tracker, tape, open interest, chart structure) into the middle. The purpose is front-loaded, but the enumeration of return contents is bloated for a description and the live-verdict hint is buried at the very end.

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 does earn credit for sketching the return shape (causes plus shares, one sentence per move, explicit unknowns). But for a 6-parameter, zero-required tool it leaves the roles of 'n', 'days' and 'symbol', and the response's structure/ordering, unresolved.

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 only 33% ('at' and 'tf' documented), so the description must carry the rest and only partly does: it explains that 'at' plus 'pct' together yield a live verdict, which the schema never states for 'pct'. But 'n', 'days' and 'symbol' are never explained in either place — only a default 30-day window is implied by the title.

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 opening clause is specific: it returns every abnormal jump or drop in the last 30 days for any market type, annotated with causes and their shares. That is a concrete resource with scope, though the rest of the sentence dissolves into an output-field enumeration and never contrasts the tool with siblings like get_catalysts or get_liquidations.

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?

One usage mode is spelled out explicitly: pass 'at' (ms) with 'pct' for a live verdict on a move happening now. Beyond that the agent must infer when to reach for this versus the cause-specific siblings (get_catalysts, get_liquidations, get_open_interest) that its own text advertises; no when-not or alternative routing is given.

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