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

With no annotations, the description carries the full burden and does substantial work: it discloses the x402 payment/authorization model and price ($0.002 USDC/call on eip155:8453), the upstream source, the derivation method including cross-via-EUR and peg-derived fallback, and the guarantee that values are deterministic and not estimated. What it does not cover is caching/freshness cadence (how often the fixing updates) or the failure mode when no fixing exists.

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?

It is a single tight sentence with no filler, and the core identity (SAR/INR reference rate, ECB fixing) leads the substantive text. The bracketed pricing/network prefix is useful but sits ahead of the purpose, slightly delaying the front-loaded answer to 'what does this do'.

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-parameter lookup with no output schema and no annotations, the description covers source, method, response components, cost, and accuracy posture — enough to call it correctly. The remaining gap is temporal: it never says how current the fixing is or how staleness is represented.

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 of 4 applies. The description correctly treats the pair as fixed by the tool identity rather than implying any caller-supplied input.

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 precise resource (SAR/INR reference rate), its source (European Central Bank fixing, or the official peg), and the exact output components (rate date, method, source attribution). Against hundreds of near-identical fx_* siblings, the currency pair, source, and method are all pinned down, so the agent can distinguish this tool without opening anything else.

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 implies the right context — official, deterministic, sourced reference data rather than an estimate — which helps an agent prefer it over estimate-style tools. However, it never names an alternative (e.g. fx_convert or fx_latest) or states when not to use it, so the routing guidance is inferred rather than explicit.

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