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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the description carries a lighter burden and still adds real value: null semantics ('Too few adverts, or no read on record, is null with a reason'), the explicit warning that a missing gap is never zero, and the cost signal ('Free'). It stops short of describing series depth or refresh cadence.

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?

Very compact and front-loaded: the resource definition comes first, followed by the disclaimer, the coverage list, and the null rules. The telegraphic sentence fragments are efficient but slightly reduce readability relative to full sentences; no sentence is wasted.

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 adequately characterizes the return value (a per-currency dated series with explicit null-and-reason handling) and lists the currency universe. Gaps remain around historical depth, per-currency series length, and response shape, but nothing prevents a correct call.

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?

There is a single parameter with 100% schema description coverage ('YYYY-MM-DD. Default today (UTC)'), so the schema already does the work. The description adds nothing about the date argument, including whether a single date returns one point or a window ending at that date, which is the one ambiguity the schema does not resolve.

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 the concrete resource ('a dated series per currency of the gap between a public-advert median and the official rate') and enumerates the covered currencies, so an agent knows exactly what data comes back. It does not, however, distinguish itself from rate-oriented siblings such as get_corridor_rates, get_rate_receipt, or rate_deal_history, leaving the agent to infer the difference.

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?

The clause 'Labelled market-observed, never an official rate' functions as an implied guardrail against using this for pricing or settlement, which is useful. But there is no explicit statement of when to call this versus the sibling rate tools, no prerequisites, and no mention of pairing it with an official-rate source.

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