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

Annotations already establish readOnly, idempotent, openWorld, so the bar is lower, yet the description still adds real context the schema cannot: the data is independently sourced from a third-party market API rather than a ledger read, and it is indicative/non-executable with no slippage or depth modelling. That sourcing and reliability caveat is exactly the kind of behavioral disclosure an agent cannot get from structured fields.

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?

Three tight sentences with the payload front-loaded and caveats following, no filler. The opening fragment 'Legacy-available.' is cryptic shorthand that costs a little clarity for its brevity.

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 and no parameters, the description does the heavy lifting well by enumerating what comes back (30-day daily series, spot price, 24h/30d deltas) and flagging the third-party sourcing. It is nearly complete, with the only gap being what 'Legacy-available' implies about availability or deprecation.

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?

The tool takes zero parameters, so the baseline is 4. The description spends its words on the return payload (daily observations, current price, 24h and 30d change) rather than parameters, which is the right allocation, though 'Legacy-available' is an unexplained qualifier that could confuse expectations.

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 resource (ASTEROID daily USD price observations) with explicit scope: last 30 days plus current price and 24h/30d change. It partially differentiates from siblings by ruling out the executable-quote path ('not a quote, not executable'), though it never names get_swap_quote, get_market_state, or get_token_stats directly.

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?

Usage is only implied: 'not a quote, not executable, no slippage or depth modelled' steers an agent away from treating this as execution data, but there is no explicit statement of when to call this versus get_swap_quote or get_market_state. The unexplained 'Legacy-available' prefix adds ambiguity rather than guidance.

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