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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond annotations: it identifies the rates as 'Reference FX rates (ECB)' (implying they are reference, not necessarily real-time market rates), names the sources (Frankfurter/ECB and open.er-api), and notes the per-call cost. This helps an agent understand the nature of the data and cost implications.

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?

The description is a single, tight sentence that front-loads the main function, then provides source, cost, and endpoint details. Every phrase earns its place, with no filler or redundancy. It is compact and immediately scannable for an agent.

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 simple read-only tool with 3 parameters fully documented in the schema, the description is nearly complete. It includes source, pricing, and endpoint, which are useful operational details. It does not describe the response format or whether historical rates are supported, but given the absence of an output schema and the low complexity, these are minor gaps.

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 100%, with clear descriptions and examples for from, to, and amount. The description adds only the notion of 'optional amount conversion,' which is already encoded in the schema's 'Amount to convert (default 1)'. With the schema doing the heavy lifting, a baseline score of 3 is appropriate; the description does not introduce new parameter-level meaning.

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 clearly states the tool provides 'Reference FX rates (ECB) with optional amount conversion,' specifying the resource (currency exchange rates) and the key feature (amount conversion). It is distinct from sibling tools like v1_unit_convert and v1_crypto_price based on the explicit 'FX rates' scope. The title and description together leave no ambiguity.

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?

The description provides clear context: this is for currency exchange rates and conversions, and it mentions the data source and pricing. It does not explicitly mention when not to use it or name alternatives, but the purpose is sufficiently specific for an agent to select it for currency-related requests. No misleading usage guidance is present.

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