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

With no annotations at all, the description carries the full burden and does well: it discloses paid access ($0.002 USDC/call via x402 on eip155:8453), the authoritative source (ECB), the derivation method (direct, cross via EUR, or peg-derived), and that results are deterministic and non-estimated. What it omits is failure behavior, refresh cadence/typical staleness, and whether the paid call is charged on error, which matters for a paid endpoint.

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?

One dense, front-loaded sentence: payment tag, then resource, then what is returned, then a qualifier. Every clause adds information and nothing is repeated. The bracketed payment metadata is slightly noisy but is conventional and materially relevant for a paid tool.

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?

With no output schema, the description steps in to describe the return payload (rate date, method, source attribution), which is the key missing structure. The remaining gap is the quote convention — whether the rate is XAF per JPY or JPY per XAF, and at what precision — which is genuinely ambiguous for a pair tool and is the one thing an agent could get wrong when calling it.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description instead spends its words on the response shape (rate date, method, source attribution), which is useful but not a parameter concern.

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 the exact resource (XAF/JPY official reference rate) and the specific verb/data source (latest European Central Bank fixing), plus a fallback case (official peg). This is far more specific than the tool name alone, which is a bare pair code. It does not, however, distinguish itself from the ~1000 sibling pair tools or from fx_convert/fx_timeseries, so an agent still has to infer that this is the single-pair spot-rate tool.

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 rather than stated: an agent can infer 'call this when you need the official XAF/JPY rate', and the 'no estimate' phrasing implies it is not for computed/converted amounts. There is no explicit when-not guidance and no named alternative such as fx_convert (for converting an amount) or fx_timeseries (for history), which would be the most likely confusion points given the sibling set.

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