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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered; the description adds genuinely new operational context: it is free, covers ~30 currencies, supports only today or working days within the last 90 days, and returns cross rates. The working-day/90-day constraint is exactly the kind of limit an agent needs and could not infer from annotations.

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 single most decision-relevant token ('Free') followed by the when-to-use clause, then inputs. One dense block with essentially no filler; only slight cost is the packing of constraints into a run-on list.

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 does enough: it names the data source, coverage, date window and that cross rates come back. It could say more about the response shape or what happens on non-working days, but an agent has what it needs to invoke this correctly.

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 0% and all four params are bare strings, so the description carries the full documentation burden. It supplies the default for base (EUR), a format example for symbols (USD,GBP), a format for date (YYYY-MM-DD), and identifies date and amount as optional — a meaningful lift, though it never clarifies that amount is a numeric quantity typed as a string.

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 combination: ECB euro reference rates for ~30 currencies, plus cross-rate conversion, with the currency universe and date range named. An agent can distinguish it immediately from every sibling (none of which deal with FX) without opening the schema.

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 an explicit trigger — 'Use when the user needs an official euro exchange rate or a conversion for an invoice, contract or report' — which maps a user intent onto the tool. It stops short of stating when not to use it or naming an alternative, but no sibling is a plausible substitute for FX rates.

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