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.

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

Beyond readOnlyHint/idempotentHint it discloses that rounding happens exactly once and that the response carries the rate, its multiplier and the publication date, so the conversion is auditable. The one-side-must-be-RON constraint is a behavioral rule no annotation conveys. It does not discuss rate-availability failures or how dates without a published fixing are handled.

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 purpose and the formulas, then the rule selection, then the return shape. Dense but every clause carries information; the parenthetical about `rate` answers could be trimmed slightly.

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 7-parameter conversion tool with an output schema, the definition still covers the formula, direction constraint, both enum behaviors and the returned provenance fields. Nothing an agent needs to call it correctly is 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?

Schema coverage is 100%, so baseline is 3, and the description earns above that by introducing the 'multiplier' factor that appears nowhere in the schema and by spelling out the direction-dependent formulas showing how amount, rate and multiplier combine.

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 a specific verb and resource ('An amount converted to or from RON at BNR's reference rate') plus the exact computation, which clearly separates it from the sibling tools rate, rates and annual_average that only surface fixings.

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 concrete when-to-use routing for the rate_rule choice: in_force for the day's rate as `rate` answers it, last_before 'the rule for an invoice in a foreign currency'. Also states the hard precondition that one side must be RON and that other pairs require two calls. It stops short of naming a sibling to use instead when only a quoted rate is wanted.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeatability are covered structurally. The description adds that the payload reports the latest fixing date and currency count, which is useful, but it does not disclose failure semantics for a health check (e.g., does an unavailable rate source surface as an error or a status field?) — the single most important behavioral trait here.

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?

A single front-loaded sentence that names the readiness question first and then enumerates the two returned signals. No redundant or filler wording.

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 zero-parameter status tool with an output schema and full annotation coverage, the description supplies enough to call it correctly; the output schema carries the return-shape burden. Only the degraded/unavailable-rate scenario is left unaddressed.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline applies. No parameter-related gaps exist.

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 states a specific purpose: a readiness check on BNR rate data, returning the latest fixing date and currency count. It is clearly distinguishable in kind from the data-returning siblings (rate, rates, convert, annual_average), though it never names them explicitly and the verb is somewhat implicit ("whether ... can be read now").

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 is only implied: an agent can infer this is a pre-flight availability check before calling rate/rates, but the description never says when to call it, whether it should precede the data tools, or what to do if the check fails. No exclusions or alternatives are given.

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

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

Annotations already declare readOnly, idempotent, and openWorld, but the description adds genuinely new behavior: weekends, holidays, and today before ~13:00 Bucharest fall back to the last banking day's fixing, and the returned `published_on` reflects the fixing date rather than the requested date. The multiplier convention (1, or 100 for HUF/JPY/KRW) is also disclosed only here. It stops short of describing error behavior for unknown currency codes.

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 and units are front-loaded in the first clause, and each subsequent clause (multiplier exception, published_on, fallback rule, use case) carries distinct information. It is somewhat dense and runs long as a single block, but there is no 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 two-parameter lookup with an output schema, everything an agent needs is present: what is returned, the multiplier caveat, the date default, and the non-banking-day fallback. Return-value explanation is correctly kept brief since the output schema exists.

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 both parameters are already documented in the input schema, which sets the baseline at 3. The description's multiplier and Bucharest-timezone context clarifies how to interpret `currency` and `date` results rather than adding new parameter syntax, so it does not materially exceed the schema's own 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?

States a specific verb and resource: the National Bank of Romania's reference rate in force on a given day. The scope is precise enough that an agent can distinguish a point-in-time rate lookup from the sibling `rates` or `annual_average`, though neither is named to draw the contrast explicitly.

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?

"Use it for any EUR/RON or other conversion stated on a date" gives a concrete when-to-use trigger. It does not name the alternatives (`convert`, `rates`, `annual_average`) or state when not to use it, so the routing to siblings is left implicit — and the conversion phrasing brushes against what `convert` likely does.

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds substantive behavior beyond them: fallback to the last banking day's fixing when the day has none, oldest-first ordering, hard limits of 366 days and 2000 rates per call, and per-series multipliers. These are exactly the traits an agent needs to size requests and interpret values.

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?

Three sentences, front-loaded with what the tool returns, then mode behavior, then coverage and limits. The parentheticals carry real information (defaults, multiplier rule) rather than restating the schema — every clause earns its place.

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 an output schema present, return-format detail is unnecessary, and the description covers the remaining risk areas: input mode exclusivity, defaults, request caps, and the meaning of the multiplier. Little an agent needs to call this correctly is 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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by adding semantics the schema lacks — that `to` is inclusive and defaults to today, that `date` is in Bucharest time, that result rates reflect non-banking-day fallback, and that omitting `currencies` returns everything BNR published.

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 a specific verb+resource: BNR reference rates returned as series in the exact published text, with two modes (single day vs. window). It is distinguishable from `annual_average` and `convert`, though it never explicitly names the `rate` sibling, leaving the single-rate-vs-series boundary to be inferred from the title.

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 clear mode-selection guidance: use `date` for one day's rates in force, use `from`/`to` for a window of fixings. It stops short of explicit exclusions or routing to siblings such as `rate` or `convert`, so the agent must infer which tool to pick for a single conversion.

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