dual_stacking_get_rewards

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

With no annotations, the description carries the behavioral burden and does a reasonable job: it identifies this as a retrieval operation, explains that rewards are returned in satoshis and BTC, describes the rollback lookup behavior, and notes the mainnet-only constraint. It stops short of covering error conditions, wallet prerequisites, or other operational details, but the core behavioral context is present.

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 description is front-loaded with the core operation and uses short, readable sentences. The final earning_opportunities tip is related but not strictly necessary for invoking this tool correctly, so the text is slightly less tight than it could be.

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 simple getter with three fully documented parameters and no output schema, the description supplies the key context an agent needs: what is returned, the rollback meaning, and the mainnet restriction. It could be more complete by mentioning wallet/config prerequisites or error behavior, but it is largely sufficient.

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%, so the schema already defines cycle, address, and rollback. The description adds a small amount of meaning by clarifying that rollback defaults to the most recent snapshot offset, but it does not materially expand parameter semantics beyond the 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 states a specific verb and resource: get earned sBTC rewards for a specific Dual Stacking cycle. This clearly distinguishes the tool from broader siblings like get_stacking_rewards and from adjacent Dual Stacking tools such as dual_stacking_status or dual_stacking_enroll.

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 implied by the purpose and by the mainnet-only note, but the description does not explicitly say when to call this instead of dual_stacking_status, get_stacking_rewards, or claim_stacking_rewards. The earning_opportunities tip is related but not an alternative-tool routing rule.

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