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

Adds real context beyond annotations (readOnly, openWorld): per-call cost of $0.002 USDC via x402 with payment chains, failed calls not charged, and the caveat that the two prices may be quoted minutes apart. This is exactly the kind of operational detail annotations can't carry, though it stops short of describing latency or caching.

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 sentences, front-loaded with purpose and source, then caveats, then billing. No filler; each clause conveys distinct 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?

Output schema exists, so return values need no prose. Data source, staleness caveat, explicit omissions, and payment terms are all covered, leaving nothing an agent needs missing before calling.

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?

Zero-parameter tool, so per the rubric the baseline is 4. The description appropriately spends no text on parameters and instead uses the space for data-source and cost semantics.

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?

States a specific verb+resource (Lido stETH vs ETH peg) plus the exact data source and the fields returned (stETH/ETH price, discount/premium %, total staked, market cap). The explicit exclusions (Curve pool balances, withdrawal queue) carve out scope against adjacent DeFi 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?

Usage context is only implied: it says what the tool reports and what it omits, but never states when an agent should pick this versus a sibling like crypto_curve_gauge_weights or crypto_defillama_tvl_oracle. No exclusions phrased as 'use X instead'.

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