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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), but the description adds behavior they cannot express: a 0.001 USDC per-call cost, the x402 payment rails and accepted chains, and the guarantee that unsupported symbols are 'never billed'. Cost and billing semantics are exactly the kind of trait an agent needs before invoking and cannot get from annotations.

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?

Four sentences, front-loaded with the usage condition, then returns, then error handling, then price. Every sentence carries information, though the 400/supported-list clause partially duplicates the schema description.

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?

An output schema exists, so return-shape explanation is optional and the brief summary suffices; annotations carry the safety profile. Together with cost, payment rails, supported symbols and error semantics, the description gives an agent everything needed to call correctly.

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?

With a single parameter and 100% schema description coverage, the schema already documents the symbol and default. The description restates the supported set and the 400 fallback but adds no format or syntax detail beyond the schema, so this sits at the baseline for well-covered schemas.

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 capability: an on-chain DEX spot price for SOL/BTC/ETH, computed as the median of deep USDC pools on Solana, Ethereum and Base, plus the serving pools. The clause 'without choosing a venue' implicitly separates it from venue-specific siblings like get_sol_price or get_btc_price, but no sibling is named explicitly, so differentiation is inferred rather than stated.

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 opening sentence gives a clear selection condition ('needs a spot price without choosing a venue'), and the 400 behavior plus supported symbol list tell the agent when the call will fail. It stops short of naming the alternative tools to use when a venue-specific price is wanted, so the agent must infer the exclusion.

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