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

Annotations already cover read-only and open-world behavior, but the description adds substantial context they don't: data provenance (ECB, NBU, Binance vs USDT), cache TTLs of 30 min for fiat and 5 s for crypto, and a $0.003 per-call cost payable via x402 in USDC on Base or Solana. That pricing/payment detail is exactly the kind of thing an agent needs before invoking. What's missing is any statement of error behavior or rate limits.

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 tight sentences, front-loaded with the core capability followed by cost/caching operational facts; nothing is filler. The opening clause largely restates the title, which is the only wasted space.

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?

There is no output schema, so the description should say what a conversion returns (a rate, a converted amount, a map per target currency) and it doesn't. Payment mechanics, caching, and source coverage are well covered, leaving the return shape as the main gap for a tool that can take up to 10 target currencies at once.

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 only 25% (only `tx` is documented), so the description has some burden to carry. It does clarify the currency universe and that crypto pairs are quoted against USDT, which adds meaning beyond the bare patterns/examples, but it never explains that `to` accepts a comma-separated list of targets or what `tx` is for. Baseline 3 is 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?

States a specific verb (converts) and resource (amount between fiat and crypto), and names the concrete sources (ECB, NBU, Binance) and the ~60-currency scope, which separates it from siblings like price/prices/token_price. It stops short of explicitly naming those siblings as alternatives, so a 4 rather than a 5.

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 'converts an amount between...' and the mention of paid x402 access tells the agent a cost applies, but there is no explicit when-to-use/when-not guidance or pointer to the price/prices/token_price siblings for non-conversion lookups. Caching windows hint at freshness tradeoffs but aren't framed as selection criteria.

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