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

With no annotations, the description carries the behavioral load and does so well: it discloses the paid x402 metering ($0.002 USDC/call on eip155:8453), the authoritative source, the derivation method, and the absence of estimation. What it omits is operational behavior — publication cadence, holiday/staleness handling, and error responses for an unpaid call.

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 front-loaded sentence with the payment tag bracketed ahead of the substance, so cost is visible before commitment. It is dense but every clause — source, peg fallback, date, method, attribution, determinism — carries information; slightly better clause separation would help 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?

With zero parameters, no annotations, and no output schema, the description must cover the return payload itself, and it does by enumerating rate, rate date, derivation method, and source attribution. The remaining gap is the base/quote direction and freshness cadence, both of which matter for a foreign-exchange lookup.

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 no parameters, so the schema baseline is 4 and there is nothing for the description to disambiguate. It does implicitly confirm the call is parameterless by specifying the pair and scope in the fixed identifier, but it adds no semantics beyond that.

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 specific resource (THB/SAR reference rate) and states its provenance (latest European Central Bank fixing, or the official peg for SAR), which is well beyond a restated name. The one ambiguity is quote direction — with a sibling fx_sar_thb existing, an agent cannot tell from the text alone whether this returns THB per SAR or SAR per THB, and must infer it from the identifier convention.

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?

There is implicit guidance to prefer this over estimation ('Deterministic, sourced, no estimate') and a 'latest' scope that hints at a time-dimension sibling, but no explicit statement of when to use this versus fx_convert, fx_latest, fx_timeseries, or the inverse pair fx_sar_thb. Usage has to be inferred from naming.

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