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

Annotations already declare readOnlyHint/openWorldHint, and the description goes well beyond them: data source (SDMX-JSON), business-days-only coverage, cost of $0.002 USDC per successful call, payment rails (Base, Solana, Arc) via x402, and that failed calls are not charged. Cost and billing-on-failure disclosure is exactly the context an agent needs before deciding to spend.

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 tight sentences: what it returns and in which units, then coverage constraints, then pricing. Front-loaded and every sentence carries information; nothing is padded.

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?

An output schema exists so return format needn't be explained, and the description covers source, unit semantics, observation window, calendar coverage, and cost model. That is everything needed to call a two-parameter read tool correctly and to judge whether spending $0.002 is warranted.

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 the schema carries the mechanics, but the description adds real semantic value by fixing the unit convention (NOK per 1 unit) for the currency parameter and clarifying that `last` returns the latest observations limited to business days. That resolves ambiguity the schema alone leaves open.

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 (daily exchange rate from Norges Bank's SDMX-JSON API) and nails the quote convention: NOK per 1 unit of the foreign currency. An agent knows exactly what series it is retrieving and the direction of the rate, which is the classic ambiguity in FX tools.

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?

'Last N observations; business days only' implies the use case (recent daily rates) but the description never says when to prefer this source over sibling FX/rate tools such as finance_bank_of_england_iadb or finance_bcb_brazil_central_bank, nor any prerequisites. Usage is inferable, not stated.

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