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

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses extensive behaviors: ECB publication days only, empty map with a notice for non-publication ranges, same-currency rate of 1, inline vs spill based on range length and DataCanvas configuration, and the exact response flags (spilled, canvas_id, table_name). This is far beyond what annotations provide.

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 long but every sentence serves a distinct purpose: purpose first, then edge cases, then spill logic. It is front-loaded with the primary function and organized in a logical flow. While it could be trimmed slightly, the structure is strong and there is no fluff.

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?

Given the tool's complexity (multiple conditional behaviors, spill integration, and response variations), the description is remarkably complete. It explains all return scenarios, the spill condition and how to proceed, and the same-currency case. The existence of an output schema further reduces the burden, but the description goes beyond that by describing response fields and follow-up actions, leaving nothing critical missing.

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?

The input schema covers all parameters at 100% with descriptions, so the baseline is 3. The description adds domain context (e.g., date-boundary behavior, ECB holidays) but does not explain individual parameters beyond what the schema already states. It does clarify the 'short range' default of 90 days, which relates to start/end dates, but this is more about behavior than parameter semantics. Therefore, it meets the baseline without exceeding it.

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 names a specific verb ('Get historical daily exchange rates'), a precise resource ('currency pair over a date range'), and explicitly distinguishes itself from sibling tools by describing the spill workflow to fx_dataframe_describe/query. The purpose is unambiguous and not a tautology.

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?

It provides clear conditional guidance: when long ranges spill to DataCanvas, it explicitly directs the agent to call fx_dataframe_describe and fx_dataframe_query. It also implies this is the tool for historical daily series as opposed to single-rate tools, though it never explicitly states 'use fx_get_rate for a single date'. The lack of explicit 'when not to use' is a minor gap.

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