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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the rest and does: business-days-only coverage (a real data caveat that affects interpretation), a bounded N-observation window, and a full payment model ($0.002 in USDC per successful call, via x402 across Base/Solana/Arc, failed calls free). That cost and failure semantics is exactly the kind of behavior an agent must know before invoking.

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?

Two sentences, front-loaded with the core definition and unit convention, then source/coverage, then alternatives, then price. Dense but every clause carries information; the x402 payment parenthetical is long but genuinely load-bearing for a paid tool.

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, the description needn't explain return structure, and it still supplies the unit direction, frequency (business days), lookback window, source, and pricing. The only meaningful gap is that it never says what happens for an unsupported currency code or whether the range is open-ended historically.

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% — both `last` (1–30, default 5) and `currency` (ISO 3-letter code, with examples) are fully documented in the schema. The description adds only the framing 'Last N observations' and the NOK-per-unit output convention, which clarifies the return value rather than the inputs. Baseline 3 is appropriate.

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 verb and resource — daily exchange rate of one foreign currency in NOK — and pins down the quote convention (NOK per 1 unit), the upstream source (Norges Bank SDMX-JSON API), and the observation type (business days only). An agent can tell exactly what data comes back without opening the schema.

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 gives explicit routing: use finance_bank_of_england_iadb for BoE series and finance_asian_dev_bank_data for ADB IATI data, framed as 'for a different need'. That is clear context for the nearest lookalikes, but it never states when *not* to use this tool (e.g. non-business-day rates or other central banks' FX feeds such as finance_bcb_brazil_central_bank), so the exclusions are only partial.

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