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

Beyond the annotations, the description discloses refusal semantics ('refuses, with no charge, when live price feed, ≥2 chains cannot be fetched'), the settlement artifact produced (ProofOfSettledOutcome, kind 30120, data/proof_settled_outcomes.jsonl), and the x402 cost of $0.03 USDC per call. That is exactly the kind of preconditions and pricing context an agent needs before invoking a paid, open-world tool.

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 value proposition and the sibling differentiation are front-loaded, and the pricing parenthetical is correctly relegated to the end. However, the refusal sentence is grammatically broken ('when live price feed, ≥2 chains cannot be fetched') and the settlement-proof fragment is dropped in without a connective, costing some readability.

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 one-parameter tool with no output schema, the description covers what is produced (a comparable price plus the highest-deviation pair), cost, failure behavior, and positioning. Nothing material an agent needs to invoke it correctly is missing — the only soft gap is that it implies a plain 'read' while annotations set readOnlyHint=false, which the settlement-proof artifact plausibly explains.

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?

There is one parameter ('task', documented as 'Task/query text for this SKU') at 100% schema coverage, so the schema already carries the full burden. The description adds nothing about how to phrase the token/chain query or what the task string should contain for a cross-chain price aggregation, leaving the baseline 3 appropriate.

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 — aggregating a token's price across chains and venues (DEX + CEX) into one comparable value, plus flagging the highest-deviation pair. It explicitly positions itself against siblings: narrower than oracle.comprehensive-report (single metric, not a full report) and an input to oracle.market-arbitrage. An agent can distinguish it from the whole oracle.* family without opening a schema.

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 gives a clear selection rule against oracle.comprehensive-report ('single metric, not a full report') and states a downstream consumer (oracle.market-arbitrage's spread detection). It does not, however, contrast itself with oracle.price-feed or oracle.historical-analysis, which are the closest siblings, so the 'when not to use' side is only partially covered.

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