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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description goes further by disclosing the shape of each record: one story per event, source desks, a 0-100 score, named coins, implied direction, and the measured historical price impact for that event kind. It omits ordering and how limit interacts with the feed, which keeps it from 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?

A single dense sentence that front-loads the resource definition before the field inventory; nothing is wasted. It is long and list-heavy enough that parsing takes effort, but every clause 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?

With no output schema, the description correctly takes on the job of explaining return contents (story, desks, score, coins, direction, historical impact). Defaults for min_score live in the schema. The gap is pagination/ordering and the absence of any guidance on combining filters.

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 75%, so baseline is 3. The description reinforces that scoring is 0-100 and that events carry named coins and implied direction, which helps interpret symbol and min_score, but it adds nothing about limit (no description in the schema) or the fact that kind accepts a fixed vocabulary without a schema enum.

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 the resource precisely (dated events that move a coin, arriving as they land) and enumerates the event categories: listings, delistings, filings, macro prints, hacks, ETF and regulation headlines. An agent knows exactly what this returns. It stops short of naming a sibling such as get_what_moved_it or get_economic_calendar to differentiate, which keeps it at 4.

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?

'As they land' implies a real-time catalyst feed, which is a useful usage cue, and the score/direction fields suggest it is for triaging event-driven setups. However, there is no explicit when-to-use, when-not-to-use, or routing to alternatives from the large sibling set (e.g. get_what_moved_it for retrospective price moves).

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