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

With no annotations supplied, the description carries the full disclosure burden and does so well: it reveals the per-call price and payment protocol ($0.002 USDC, x402, eip155:8453), the upstream source (ECB fixing), and the fallback behavior (peg-derived when XOF is pegged). It also pre-empts the key question of methodology by naming direct, cross-via-EUR and peg-derived paths. It does not mention rate limits, caching or freshness lag beyond the rate date field.

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?

A single dense sentence preceded by a bracketed pricing tag; every clause (source, peg fallback, returned fields, determinism) earns its place. The pricing/channel metadata up front is useful but slightly crowds the functional statement, keeping it from a 5.

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 zero-param, no-output-schema lookup, the description supplies source, method taxonomy, returned metadata and cost — enough to call it correctly and interpret the result. The only gap is that XOF's actual peg relationship and any staleness expectations are named but not quantified.

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 per the baseline this scores 4. The description adds value by describing what the parameterless call returns — rate date, method classification and source attribution — which tells the agent what to expect without a schema to lean on.

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 resource and pair ('Official ILS/XOF reference rate') and specifies the provenance (latest ECB fixing, or official peg when XOF is pegged). That is far more precise than the bare currency-pair name, so an agent knows exactly which of the many fx_* siblings this returns. It stops short of 5 because it never names adjacent generalist siblings like fx_latest or fx_convert to disambiguate rate-lookup from conversion.

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: 'Deterministic, sourced, no estimate' signals this is the authoritative-rate choice when a quoted figure must be defensible. There is no explicit when-to-use/when-not guidance and no pointer to fx_convert for arithmetic conversion or fx_timeseries for history, so the agent must infer routing from the pair name alone.

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