Get a bank's official published rates

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

Annotations only cover readOnlyHint and openWorldHint, so the description usefully adds the parts they cannot: the API-key/paid-plan requirement for `date`, weekend/holiday rollback to the last published date, the `derived` flag for cross-computed pairs, and the instruction to cite `rate_date`. It stops short of discussing rate limits, caching, or table size limits, so it is strong but not exhaustive.

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-loads the definition and the get_exchange_rate distinction, then handles each parameter mode in order. It is dense — semicolons carry several distinct constraints per sentence — but nearly every clause carries a decision-relevant fact rather than filler.

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 four-parameter read tool with an output schema present, the description covers everything an agent needs to choose the right call: source-tool dependency (list_central_banks for bank codes), auth implications, date fallback behavior, and pair narrowing. Return-value details are appropriately deferred to the output schema.

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%, so the baseline is 3, but the description adds genuine semantics the schema lacks: `date` shifts to the last published table on weekends/holidays, omitting `date` yields the newest table without a key, and omitting both source and target returns the full table with cross-computed pairs flagged `derived`.

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 the resource precisely ('OFFICIAL rates a named institution published') with three real user-phrasing examples, and explicitly names the sibling it is not (get_exchange_rate). An agent can distinguish it from get_exchange_rate and get_historical_rates without opening a 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 explicit when-to-use routing ('NOT live market rates — use get_exchange_rate for those'), plus conditions for each invocation mode: omit `date` for the newest table (no API key), supply `date` for the table in force that day (API key, paid plan), omit source/target for the full table vs both for one pair.

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