getEarnHourlyYieldHistory

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

Annotations already carry the safety profile (readOnlyHint=true, openWorldHint=true), so the description needed only to add behavioral context beyond that, which it does with the FlexibleSaving-only constraint and the hard 7-day range limit. It does not disclose the pagination behavior implied by the cursor parameter or what happens when the range is exceeded, but for a read-only query tool the core behavioral constraints are covered.

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?

Two compact sentences with the purpose front-loaded and constraints following — no filler. The stray '-' before 'Maximum query range is 7 days' appears to be a leftover bullet-format artifact that slightly hurts readability, but the overall structure is efficient.

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?

For a 6-parameter tool with no output schema and 0% schema description coverage, the description delivers the two most load-bearing constraints but omits important call semantics: the unit/format of the integer time parameters (seconds vs milliseconds), how the cursor-based pagination flow works, and what productId refers to. An agent could make the simplest call correctly but would be guessing on pagination and time formatting.

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 0%, so the description is the only source of parameter meaning and must compensate. It indirectly explains category ('Only supports FlexibleSaving') and bounds startTime/endTime semantics (7-day max window), but it says nothing about limit, cursor, or productId, leaving three parameters semantically empty. This is only partial compensation for a 0%-coverage schema.

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 uses a specific verb-resource pair ('Query hourly yield details') and adds the scope constraint 'Only supports FlexibleSaving', which meaningfully distinguishes it from yield-history siblings such as getEarnYieldHistory, getTokenHourlyYield, and getHoldToEarnYieldHistory. It stops short of a 5 because 'details' is never defined — the agent is not told what fields or granularity a returned record contains.

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?

The description states clear conditions of use: the tool applies only to FlexibleSaving products and only to query windows within 7 days, which functions as an explicit exclusion of other product types and longer ranges. It does not name a fallback alternative (e.g., getEarnYieldHistory for non-hourly yields), so routing to a sibling still requires inference from tool names.

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