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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds substantial behavioral depth beyond them: half-even default plus per-currency ISO 4217 minor-unit rounding, no intermediate rounding in cross conversion, same-currency identity without external quote, and stale/missing/mismatched rates blocking export and total. It also discloses hard limits (500 rows, 48,000 argument bytes) and result guarantees.

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 purpose is front-loaded, but the body is a dense, run-on block that mixes rounding, limits, output shape, pricing, and disclaimers without clear grouping. Every sentence carries content, yet the wall-of-text structure makes it hard to parse, so it is only adequately sized.

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?

Despite the complex batch/rounding semantics and low schema coverage, the description covers limits, rounding, output format, error behavior, and source integrity. An output schema exists, yet the description still names key result fields (amount_target, total_target, target_decimal_places), which is helpful rather than strictly required.

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 only 25%, so the description carries weight and delivers: it defines the 30-currency target_currency set with EUR default, explains rounding modes and per-line minor-unit behavior, and clarifies output_format ('json keeps the response smaller', 'both includes the CSV'). It adds real meaning beyond the schema, though the rows item fields (id, date, amount) get only incidental coverage.

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 first sentence states a specific verb and resource: convert dated decimal-string amounts to a target_currency from 30 supported currencies. No sibling (catalog, get_exchange_rates, get_exchange_rate_history, get_evidence, get_record) performs conversion, so the tool's role is unambiguous even without naming them.

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?

Usage context is implied ('start small', 'Preserve originals and evidence', 'never replace dates', 'No transfers'), which gives operational posture but not selection guidance. It never states when to choose this over get_exchange_rates or get_exchange_rate_history for raw rate lookups, leaving the routing to inference.

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