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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety and data-source profile are covered. The description adds a useful disclaimer ('Rates are not investment advice') and implies inference behavior, but says nothing about data freshness, failure modes, or what an empty result looks like for an open-world lookup.

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?

Dense and front-loaded: domain scope first, then routing rules, then the disclaimer. The sentence 'Applies to questions about rates, inflation or wages' largely restates the opening list, and 'Choose kind rates, inflation or wage' duplicates the enum, but nothing else 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?

For an 11-parameter, zero-required, three-mode tool the critical ambiguity is mode selection, and the description addresses it thoroughly. The notable gap is that with no output schema, the agent gets no signal about response shape (e.g., a rate table vs a wage range), which matters for a multi-mode 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 82%, so the baseline is 3 and the schema already documents most fields including the kind enum and its inference note. The description does add the 'otherwise rates' default and the ambiguity tie-breaker, but does not explain term, offer/offer_per, country defaults, or how amount is interpreted per mode beyond what the schema says.

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 three concrete data domains (central-bank rates and Treasury yields, inflation/value-of-money across years, wage-by-place) so an agent knows exactly what data comes back. It stops short of a crisp single verb framing, reading more as a topic list than a 'returns X for Y' statement, but the resource coverage is unambiguous.

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 mode-selection logic: 'Choose kind rates, inflation or wage', plus inference rules ('Job implies wage; from, to or category imply inflation; otherwise rates') and a tie-breaker ('Use kind when fields are ambiguous'). There are no when-not-use conditions or pointer to an alternative tool, which keeps it from a 5, but the routing guidance is stronger than typical.

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