BNR annual average

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description goes further: it discloses the aggregation method (mean of twelve monthly means, each from daily rates), rounding to four places, that monthly values and day counts are returned, and the partial-year `complete: false` semantics. Minor overlap with the output schema on returned fields, and no note on caching or data vintage, keeps it from a 5.

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 definition, then methodology, then the disambiguation, then the edge case — a logical order with no filler. Two sentences are dense but each clause carries information; the 'to four places' and day-count detail are borderline but justify themselves against the ANAF spec.

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 annotations covering safety and an output schema covering return shape, the description supplies exactly what those fields cannot: the computation semantics, precision, and the incomplete-year behavior. Complete enough to call correctly; only rate limits/caching freshness are unaddressed, which is minor for a read-only reference lookup.

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% and both parameters (ISO 4217 currency, calendar year) are fully specified there, so the baseline of 3 applies. The description adds context about what the year parameter means for an in-progress year, but nothing beyond the schema about formats, bounds, or currency handling.

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?

Names a specific resource and computation: 'BNR's annual average rate for a year', anchored to the exact ANAF/D212 wording it serves. It also explicitly excludes a plausible misreading ('Not the mean of the daily rates, which differs'), so an agent can separate it from the sibling `rate`/`rates` tools without opening their schemas.

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 a concrete use context (converting foreign income in the D212 return) and a negative rule (this is not the daily-rate mean), plus the edge-case behavior for an unfinished year. It stops short of naming the sibling tools to route to instead — e.g. 'use `rate` for a single day' — so the alternative is implied rather than stated.

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