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

Annotations only say read-only/idempotent/open-world; the description adds substantive behavior the annotations do not: weekend and holiday dates return the last publication, the date defaults to today, omitting the currency returns all rates, and the source is the official BNR feed at no cost. These are exactly the operational facts an agent needs before calling.

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?

Front-loaded with the use case followed by the rate semantics, defaults, and edge cases; no filler sentences. It is a single dense run-on with stacked parentheticals, which costs a little readability but not accuracy.

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 still conveys the return shape implicitly ('RON per 1 unit', omitting currency yields all rates) and covers defaults and publication-day fallback. Only the exact response envelope (list vs. object, rate field naming) is left unstated, a minor gap for a two-parameter 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?

Schema already documents both params at 100% coverage (date as YYYY-MM-DD, currency as ISO 4217), so the baseline is 3. The description goes beyond it by stating the date default (today), the fallback rule for non-publication days, and the special semantics of omitting currency — meaningful additions rather than repetition.

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?

States a specific verb-resource pair (official BNR exchange rate) and pins down the direction, 'RON per 1 unit of the currency,' which is the ambiguity that matters most here. It is clearly distinguishable from every sibling (validate_invoice, ro_business_day, etc.), none of which deal with FX.

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?

Gives a concrete triggering scenario — a foreign-currency invoice needing VAT in RON for e-Factura — plus a general catch-all ('any RON conversion'). There is no explicit when-not or named alternative, but no sibling competes for this job, so the guidance is effectively complete.

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