getDoubleWinLeverage

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

Annotations already mark the call as read-only and open-world, and the description adds substantial behavioral context: Earn permission requirement, 1 req/s UID rate limit, price ordering and tick-size constraints, the fact that returned leverage/expireTime are consumed by a later Stake order, and the need to re-query after expiration. No contradiction with readOnlyHint.

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 compact and front-loaded: purpose first, applicability second, then permission/rate limit, then constraint notes. No sentence is redundant with the input schema or annotations; every line adds 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?

For a four-parameter read-only query with no output schema, the description provides enough for an agent to call it correctly: scope, parameter constraints, authentication, rate limiting, and how the response fields are used in the follow-up order. The absence of a return-value schema is offset by the explicit mention of leverage and expireTime.

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 must compensate. It does so with the relationship constraint lowerPrice < initialPrice < upperPrice and the requirement that prices be exact multiples of priceTickSize, plus the mention that leverage/expireTime are returned and used for the Stake order. Individual parameter meanings are mostly inferable, though productId and initialPrice are not explicitly defined.

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 opens with a specific verb and resource: 'Query the leverage for a Double Win RFQ product with user-selected price range.' It also names the product type (RFQ) and, in the next line, contrasts fixed-range products, so an agent can distinguish it from the many sibling Earn/RFQ tools.

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 explicitly states applicability ('Only applicable for RFQ products (isRfqProduct=true)') and directs users away to alternatives: 'For fixed-range products, obtain leverage from Get Product Extra Info or the WebSocket topic earn.doublewin.offers.' It also gives the required Earn permission and a concrete rate limit.

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