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

Annotations only declare readOnlyHint=true, so the description carries the meaningful burden and does so well: it discloses the threshold that defines an 'extreme' event, what fields accompany each event (peaks, receiving sides), the venues covered, the prediction semantics of the rates, and the data staleness bound. That is unusually rich operational context beyond 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?

The key payload (extreme events, threshold, exchanges) is front-loaded in a single dense sentence with no filler. It is slightly overpacked — three distinct facts (coverage, prediction semantics, freshness) are packed into trailing clauses — but every clause earns its place.

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 an output schema present, the description needn't explain return structure, and it supplies everything else an agent needs: data source set, freshness bound, the numeric threshold for inclusion, and the fact that rates are forward-looking predictions. Nothing material is missing for correct invocation.

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% for both optional params (lang enum with default, limit 1–20 default 10), so the schema already does the work. The description adds nothing about language selection or row limits, making baseline 3 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 names a specific resource (crypto perpetuals funding market) and precisely defines what is returned: open extreme events with |hourly rate| ≥ 0.1%/h, peaks and receiving sides, plus top pairs by hourly funding rate across five named venues. An agent can immediately distinguish it from funding_history (historical) and spread_pairs (spreads).

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 establishes a clear usage context — a real-time snapshot ('right now', 'data age ≤ ~5 min', 'rates are predictions for the next settlement') — which tells the agent this is the live/current-state tool. It does not, however, explicitly name an alternative such as funding_history for past data or state when not to use it.

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