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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which are consistent with a non-mutating conversion. The description adds that it uses the monthly average rate from SNB and returns CHF equivalent, rate, and date, providing additional context beyond annotations.

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 well-structured with separate sections for purpose, args, returns, and examples. It is not overly verbose, but could be slightly more concise without losing clarity. Every part adds value.

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?

Given the input schema, output schema existence, and annotations, the description provides all necessary context: the source of rates, parameter defaults, return format, and example usage. There are no gaps in understanding how to use the tool.

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?

Although the input schema provides descriptions for all parameters (amount, currency_id, reference_month), the description reinforces their meanings with examples (e.g., 'amount=45000, currency_id=USD1') and clarifies defaults. This adds practical value beyond the schema alone.

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 converts foreign currency to CHF using SNB official exchange rates. It specifies the exact rate type (monthly average) and distinguishes from sibling tools that retrieve exchange rates rather than performing conversions.

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 indicates suitability for budget calculations, cost estimations, and financial planning, providing clear use cases. It does not explicitly state when to avoid this tool or mention alternative tools, but the context of sibling tools implies that this is a conversion tool while others are retrieval tools.

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=true and idempotentHint=true, so the description's burden is lower. It adds value by stating data goes back to 1980, returns Markdown and JSON, and explains default year range. No contradictions.

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 well-structured with a concise opening sentence, a brief usage context paragraph, and clearly labeled Args/Returns sections. Every sentence adds value; no redundancy.

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?

Given the tool's complexity (annual rates, multiple currencies, year range), the description covers purpose, source, return format, and appropriate use cases. It mentions the cube name and gives defaults. The output schema exists, so return format details are sufficient.

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 schema already has descriptions for all parameters (currencies, from_year, to_year, lang). The description's Args section largely repeats these, adding slight context like example currency IDs and default year calculation. Since schema coverage is high, the description adds little new parameter meaning.

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 annual average CHF exchange rates from SNB, specifying the cube name and that it returns yearly averages for all major currencies. It distinguishes from sibling tools like snb_get_exchange_rates (likely daily) by highlighting 'annual average' and multi-year use.

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 gives explicit use cases: multi-year trend analysis, budget planning, financial reporting. However, it does not mention when not to use this tool or explicitly name alternative tools (e.g., snb_get_exchange_rates for daily rates).

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=true and idempotentHint=true, so the tool is known to be safe. The description adds that the return is a 'Markdown summary with JSON data', and details the category options with cube names. However, it does not disclose any other behavioral traits like auth requirements or rate limits, leaving some gaps beyond annotations.

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 moderately concise but includes a redundant 'Args' section that largely duplicates the input schema. This adds unnecessary length. The structure is clear with categories and a list, but could be trimmed to essential information.

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 output schema exists, so the description need not explain return values. Annotations cover safety. The description provides category options with cube names, date format examples, and language hints. It is reasonably complete for a read-only tool, though it lacks details on error handling or default ranges beyond the schema.

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 0%, meaning the description does not add substantial new meaning beyond the schema's own parameter descriptions. The description lists parameters in an 'Args' block but merely repeats schema info like types and examples. The schema already provides detailed descriptions for each field, so the description adds minimal value. Baseline 3 is appropriate given the schema richness.

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?

Description clearly states 'Retrieve balance-of-payments or international investment position data', with specific verb and resource. It distinguishes from sibling tools like exchange rates or balance sheets by naming the specific data type. The two categories are also clearly separated, making the tool's purpose 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?

No explicit guidance on when to use this tool versus alternatives. While the name and description imply its domain, there is no mention of when not to use it or references to sibling tools. The tool's specificity somewhat compensates, but the dimension requires more direct guidance.

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=true, destructiveHint=false, idempotentHint=true. The description adds context about return format (Markdown + JSON in millions CHF), data source, and default date range, which is useful beyond annotations. No contradictions.

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 well-structured: concise purpose statement, followed by return details, key positions list, and clear Args section. Every sentence adds value with no redundancy or fluff.

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?

Given the tool's complexity (multiple optional params, date range, language, many positions), the description covers all necessary aspects: purpose, parameters, defaults, return format, and even provides a curated list of important positions. No gaps.

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 0%, so the description carries full burden. It provides detailed explanations of each parameter, including defaults, example values, and a key list of position IDs with meanings (GFG, D, N, GB, T0/T1), adding significant value beyond the schema.

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 it retrieves SNB balance sheet data, specifies the cube 'snbbipo', and lists covered positions (assets, liabilities). It distinguishes from sibling tools by explicitly naming the cube and data type (balance sheet vs. banking balance sheet).

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 decent context but does not explicitly guide when to use this tool vs alternatives (e.g., snb_get_banking_balance_sheet, snb_get_cube_data). It mentions using snb_list_balance_sheet_positions for available IDs, but lacks when-not-to-use or comparative guidance.

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=true and destructiveHint=false, so the safety profile is clear. The description adds behavioral details: values are in millions of CHF, returns Markdown summary with JSON data, and lists parameter 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 concise with front-loaded purpose and a bulleted parameter list. No redundant sentences, but the bullet list could be slightly more compact.

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?

Given rich schema, output schema exists, and annotations covering safety, the description is adequately complete. It explains data source, return format, and parameter defaults. Missing guidance on tool relationships, but overall sufficient.

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 input schema has detailed descriptions for all parameters, so the description's 'Args' section adds little beyond summarizing defaults and grouping. Baseline 3 applies as schema coverage is high, though the description does provide a quick overview.

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 banking balance sheet data from SNB Warehouse (BSTA BIL cubes) and returns total assets/liabilities. However, it does not distinguish from sibling tools like snb_get_balance_sheet, which may cause confusion.

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?

No explicit guidance on when to use this tool vs alternatives. No conditions or exclusions are provided, leaving the agent without context for tool selection.

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 indicate readOnly, destructive, and idempotent hints. The description adds that values are in millions of CHF and returns both markdown and JSON, providing useful behavioral context beyond annotations.

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 concise (6 lines), front-loaded with a clear summary, and uses a well-organized 'Args' section. No unnecessary content.

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?

Given the tool's complexity (1 nested parameter), annotations, and output schema existence, the description provides sufficient context: return format (markdown+JSON), unit conversion, and reference to sibling tool for bank groups. Minor gap: no mention of date range defaults beyond schema.

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 input schema has detailed parameter descriptions (e.g., bank_groups default, year format), and the description summarizes the args and notes default behavior. Together they cover semantics well, with the description adding overall return format.

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 uses specific verbs ('Retrieve') and resources ('banking income statement data from SNB Warehouse (BSTA EFR cubes)'), clearly distinguishing it from sibling tools like snb_get_balance_sheet.

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 implies usage for retrieving income statement data and mentions default bank groups, but does not provide explicit when/why to use this tool versus alternatives or when not to use it.

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 declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds that return is raw JSON timeseries data, but does not discuss potential errors or performance. With strong annotations, this is adequate.

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 fairly concise but includes a redundant Args section that mostly restates the schema. It is front-loaded with the main purpose and usage guidance, but the Args section could be trimmed.

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?

Given the tool's generic nature, the description covers purpose, prerequisites, parameter source, and return format. With an output schema present, it does not need to detail the response structure, making it complete for the use case.

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 schema has detailed descriptions for all parameters, so schema coverage is effectively high. The description adds a URL for discovering cube IDs and briefly lists parameter names, adding limited but useful context beyond the schema.

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 raw data from any SNB cube by ID and explicitly differentiates itself as a generic fallback beyond dedicated tools, making its purpose very clear.

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 advises using snb_get_cube_metadata first and provides a URL to discover cube IDs, offering clear when-to-use and prerequisite guidance. The mention of 'beyond the dedicated tools' implicitly conveys when to use this generic tool over specialized ones.

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 read-only, non-destructive, idempotent behavior. The description adds context that it retrieves metadata for subsequent data queries, but does not provide additional behavioral details like rate limits or error cases. This is adequate given annotation coverage.

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 concise and well-structured: a one-line summary, a usage explanation, an Args section with parameter details, and a Returns section. Every sentence adds value without redundancy.

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 description covers input, output, usage order, and annotations provide safety information. However, it does not detail the output format or error conditions, which would be useful for a complete understanding. Overall, it is sufficient for the tool's simplicity.

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 descriptions are sparse (0% coverage per context), but the tool description fully compensates by explaining both parameters with examples and purpose: cube_id (e.g., 'devkum', 'snbbipo') and lang (de/en/fr with effect on labels). This adds significant meaning beyond the schema.

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 that the tool retrieves metadata and dimension structure for SNB data cubes, using specific verbs and resources. It distinguishes itself from sibling tools, notably snb_get_cube_data, by stating this tool is for metadata and should be used before querying data.

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?

Explicitly advises to use this tool before querying snb_get_cube_data to understand available parameters and filters, providing clear when-to-use guidance and differentiating from data retrieval tools.

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, destructiveHint, and idempotentHint, so the description does not need to repeat these. It adds value by detailing the data source (SNB cube 'devkum'), the expression of rates (CHF per foreign currency unit with examples), and the optional month-end rates. It also specifies the return format (Markdown table with metadata), enriching the behavioral context.

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 well-structured with a clear opening, a bulleted argument list, and a return format section including a JSON schema. It is slightly verbose but front-loaded with the main purpose. The organization aids readability.

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 description covers all essential aspects: data source, parameter details with defaults, return format (Markdown table), and an output schema. Combined with comprehensive annotations and no missing critical information, it is fully adequate for an agent to use the tool correctly.

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?

Although the input schema has descriptions for each sub-property, the tool description adds a concise summary with examples and defaults (e.g., 'Default: 12 months ago'). It explains the meaning of the rates and references snb_list_currencies for currency IDs, enhancing understanding beyond the schema.

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 it retrieves monthly CHF exchange rates from the Swiss National Bank, using a specific verb ('Retrieve') and precise resource ('monthly CHF exchange rates'). It distinguishes itself from sibling tools like snb_get_annual_exchange_rates by focusing on monthly data.

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 implies when to use (for monthly exchange rates) but does not explicitly provide when-not-to-use or alternatives. Sibling tools exist for annual rates or conversion, but no guidance is given on choosing between them. This is adequate but lacks explicit direction.

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=true, destructiveHint=false, idempotentHint=true. Description adds that the tool returns 'Timeseries data from the warehouse cube as Markdown + JSON,' which is useful behavioral context beyond annotations. No contradictions.

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?

Description is well-structured: first sentence states purpose, then contextual sentence, then sibling guidance, then Args/Returns sections. No wasted words; every sentence adds value.

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?

Given the tool's simplicity (one object param, no output schema), the description covers purpose, usage prerequisites, return format, and domain context (SNB Warehouse cubes, BSTA banking statistics). With rich annotations, it is complete.

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 effectively high (all parameters have descriptions in schema). The description adds minimal extra parameter info beyond restating schema details, so baseline of 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?

Description clearly states 'Retrieve raw data from any SNB Warehouse cube by ID.' It specifies the verb (retrieve), resource (SNB Warehouse cube data), and distinguishes from siblings like snb_get_warehouse_metadata (which gets structure) and snb_list_warehouse_cubes (which discovers cube IDs).

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?

Explicitly instructs to use snb_get_warehouse_metadata first to understand cube structure and snb_list_warehouse_cubes to discover available cube IDs, providing clear when-to-use guidance and alternatives.

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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explaining the return value (cube ID, edition date, dimensions) and that it is safe and idempotent. No contradictions.

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 concise (three sentences plus args/returns) and well-structured with clear sections. It could be slightly shorter by omitting the args/returns that mirror the schema, but overall no unnecessary content.

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?

Given the presence of an output schema (not shown) and annotations, the description adequately covers the purpose, usage context, and return format. It does not describe pagination or error cases, but for metadata retrieval this is sufficient.

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 input schema already describes cube_id and lang (with enum). The description repeats this information without adding new semantics. With schema description coverage apparently 0% (though schema does have one description), the description provides marginal additional interpretation. Score is baseline 3.

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 metadata and dimension structure for SNB Warehouse cubes, using the verb 'Get' and specifying the resource. It differentiates from sibling tools like snb_get_warehouse_data by explicitly stating it should be used before querying data, and it is distinct from snb_get_cube_metadata since it targets warehouse cubes.

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 explicitly states 'Use this before querying snb_get_warehouse_data,' providing clear guidance on when to use the tool. However, it does not mention when not to use it or differentiate it from snb_get_cube_metadata, which is a similar metadata tool for other cubes.

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