SNB — CHF FX Rates

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: the 11 am reporting time, historical coverage back to 1914, the default 24-month limit, and the data source (data.snb.ch cube devkum). It also discloses the open license and no-auth requirement, which helps an agent understand access constraints.

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 description is a single paragraph that front-loads the core purpose (retrieve SNB CHF exchange rates), then adds key details (27 currencies, monthly avg/end-of-month, 11 am, historical depth, limit default, use cases, source/license). It's information-dense but not bloated. The use-case sentence and source/license sentence could arguably be trimmed, but they add useful context for an agent deciding whether to invoke this 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?

The tool has only 2 optional parameters, a rich output schema, and comprehensive annotations (readOnly, idempotent, non-destructive). The description covers the data source, currency scope, rate types, historical depth, default limit, and intended use cases. It doesn't explicitly describe the return format, but the output schema exists and the description's mention of 'monthly average or end-of-month fixing values' gives sufficient context. The only minor gap is not explicitly stating that the base currency is CHF in the return values, though the title and description make this obvious.

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 already documents both parameters (limit and period) with descriptions. The description adds the default value of 24 months and clarifies that limit controls 'how many recent monthly periods are returned', which aligns with the schema. However, it doesn't add significant new meaning beyond the schema's own parameter descriptions, so the 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 clearly states the tool retrieves Swiss National Bank official CHF exchange rates for 27 currencies, with specific examples (EUR, USD, GBP, JPY, CNY). It distinguishes itself from sibling tools like africa.markets.fx_rates, bankofcanada.fx.rates, norgesbank.fx.history, and currency.exchange.convert by specifying the SNB source, CHF base currency, and the monthly average/end-of-month fixing value types.

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?

The description provides clear context for when to use this tool: for CHF valuation, Swiss currency analysis, and monetary research. It mentions the limit parameter controls how many recent monthly periods are returned. However, it doesn't explicitly name alternative tools or state when NOT to use this tool in favor of a sibling like currency.exchange.convert or africa.markets.fx_rates, though the SNB-specific context strongly implies the appropriate use case.

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