swiss-living-index

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

Without annotations, the description must disclose behavioral traits. It mentions requiring explicit consent to share contact details, which is a key constraint. However, it does not specify post-submission behavior (e.g., response time, follow-up process) or any side effects.

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 two sentences with no fluff. Front-loaded with the action and quickly conveys purpose and a key requirement. Every sentence earns its place.

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 6 parameters, no output schema, and no annotations, the description lacks completeness. It fails to explain expected outcome (e.g., confirmation), process, or how to use parameters like topic and message. Agents need more context to correctly invoke 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?

Schema description coverage is only 17%. The description adds minimal parameter meaning beyond the schema—only consent is reinforced. Parameters like phone, topic, and message lack clarity on usage or constraints. The tool would benefit from explaining which fields are required vs optional.

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's purpose: requesting a personal consultation with Mirabello Consultancy for specific topics beyond data. It distinguishes from sibling tools which are data-focused (e.g., commune_tax, rank_by_metric). The verb 'Request' and resource 'personal consultation' are specific.

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 when to use the tool: for questions beyond data, covering topics like relocation, residency, lump-sum taxation. It implies it should be chosen over data tools when personal advice is needed. However, it does not explicitly state when not to use it or list 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?

With no annotations provided, the description carries full burden but only hints at behavior by calling it 'live' tax and specifying year 2026. It does not disclose whether the tool is read-only (likely safe), rate limits, data freshness, error handling, or side effects. The agent gets minimal insight into call consequences.

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?

A single sentence of 33 words that front-loads the purpose and then maps parameters efficiently. Every word earns its place—no redundancy. The parameter mapping is compact yet clear, making it easy for an agent to parse quickly.

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 no output schema or annotations, the description covers inputs adequately but provides no information about return values, error messages, or example usage. For a 5-parameter tool, this is barely sufficient; agents would benefit from knowing the output format (e.g., tax amount in CHF) to interpret results.

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 coverage is 0%, so description must explain all 5 parameters. It does: commune as name/postcode, income in CHF, married as bool, children as count, wealth in CHF. This adds meaning beyond bare schema (e.g., units, allowed formats). However, it doesn't highlight which parameters are required (commune and income) or clarify wealth is optional.

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 computes a live income+wealth tax for a specific commune and household, referencing official ESTV and year 2026. It distinguishes from sibling tools (e.g., compare_cantons, get_canton) which focus on cantons rather than commune-level tax. However, the verb is implicit ('Live...tax' rather than 'compute' or 'calculate'), slightly reducing clarity.

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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, input validation, or scenarios where other tools (e.g., compare_cantons) might be more appropriate. The description only states what the tool does, leaving the agent without context for 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?

No annotations provided. Description only mentions 'compare' without explaining behavior (read-only, output format, or side effects).

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 short sentences, no redundancy. Front-loaded with verb and resource.

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 no output schema or annotations, description is minimal. Does not explain output structure or validation constraints, leaving gaps for a comparison 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?

Schema has 0% description coverage. Description adds that 'cantons' expects abbreviations and array length, but lacks format details (e.g., ISO codes).

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?

Clearly states the tool compares 2-4 cantons across all metrics. Distinguishes from sibling tools like get_canton (single) and rank_by_metric (ranking).

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?

Implies use when comparing 2-4 cantons, but lacks explicit guidance on when to use alternatives or when not to use.

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?

No annotations are provided, so the description carries the full burden. It discloses the data sources and meaning of positive savings. It does not mention side effects or non-obvious behaviors, but as a non-destructive estimation tool, 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?

Two sentences, front-loaded with the verb and resource, no unnecessary words. The description is highly efficient.

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 explains the calculation components but omits output format details. Given no output schema, more could be said about the return value structure or precision. The tool has multiple optional parameters, and their roles are not fully clarified.

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 67%, and the description adds overall context but does not elaborate on individual parameters beyond what the schema provides. The description explains the purpose of the calculation but not the optional parameters like wealth, married, children.

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 verb 'estimate' and the resource 'net yearly CHF impact of moving between two Swiss communes'. It specifies the components (commune-level tax, canton-average rent and health-premium differences) and distinguishes it from siblings like commune_tax or compare_cantons.

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 estimating relocation financial impact, but does not explicitly state when not to use it or suggest alternatives. The context is clear, but lacks exclusions.

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?

No annotations provided, so description carries burden. Discloses input format (2-letter abbreviation) but does not mention return structure, authentication, or rate limits. Adequate for a simple read operation.

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 concise sentences: first states purpose, second explains parameter format. No wasted words, front-loaded.

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 simplicity (single param, no output schema), description covers essential aspects. Could mention return type or contents, but sufficient for basic usage.

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 only defines a string parameter; description adds critical meaning by specifying '2-letter abbreviation (e.g. ZH, GE, TI)', enhancing usability beyond 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?

Clearly states 'Get all metric values for one canton', which is a specific verb+resource combination. Distinguishes from sibling tools like 'compare_cantons' (multiple cantons) and 'list_metrics' (list of metrics).

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?

Implied usage: use when you need metric values for a single canton. However, no explicit guidance on when not to use or alternatives (e.g., compare_cantons for comparisons).

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?

The description mentions that from_year is optional and provides example start years for metrics, but does not disclose the output format, data ordering, pagination, or behavior for omitted from_year. No annotations exist to supplement.

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 two sentences, front-loading the purpose. It efficiently conveys essential information without fluff, though could be better structured.

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?

Despite having 3 parameters and no output schema or annotations, the description does not specify the return structure, error cases, or behavior for invalid inputs. The agent needs more to invoke 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?

The description explains that metric should be a key from list_metrics with history, listing valid values. However, it does not describe the format for canton or from_year, leaving some ambiguity. Improves on the empty 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 provides historical year-series data for a specific metric in one canton, with examples of available metrics and their start years. This distinguishes it from sibling tools like rank_by_metric or compare_cantons.

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 time series data but does not explicitly state when to use this tool versus alternatives like list_metrics or rank_by_metric. No guidance on prerequisites or when not to use.

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?

With no annotations, the description must disclose all behavioral traits. It lists the return fields, which is helpful for a read-only list operation, but does not mention side effects, authentication, rate limits, or any constraints beyond the data returned.

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, well-structured sentence that immediately states the action and scope, with parenthetical detail for clarity. There is no redundant or unnecessary text.

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 a zero-parameter list tool, the description adequately covers the purpose and output structure. It names the fields returned, which compensates for the lack of an output schema. However, it does not mention pagination or ordering, but this may not be needed given the likely small dataset.

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 no parameters, so schema coverage is 100%. The description adds no parameter information because there are none, meeting the baseline for high coverage.

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 verb 'list', the resource 'metrics', and the scope '26 Swiss cantons'. It also enumerates the returned fields (key, label, unit, source, interpretation), distinguishing it from sibling tools like commune_tax or compare_cantons.

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 available metrics but does not explicitly state when to use this tool versus alternatives like rank_by_metric or compare_cantons. No exclusions or alternative guidance is provided.

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?

No annotations are provided, so the description carries full burden. It discloses the ranking behavior and parameter defaults but omits details on output format, data source, limits, or side effects. For a mutation-like operation (ranking), more behavioral context is needed.

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, no filler, front-loaded with the core purpose. Every word earns its place.

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 low complexity (2 params, no output schema), the description covers purpose and parameter usage. However, it does not explain the output or return value, which an AI agent would need to use the tool effectively.

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 coverage is 0%, but the description adds meaning by specifying valid values for metric (from list_metrics) and order (high/low, default high). This compensates for the empty schema descriptions.

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 ranks all cantons by a metric using specific parameters. It distinguishes from sibling tools like list_metrics (lists metrics) and compare_cantons (compares specific cantons).

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 the tool (ranking cantons) and explains parameter usage (metric from list_metrics, order high/low default). It lacks explicit when-not or alternatives, but sibling names help differentiate.

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?

With no annotations, the description carries the burden. It mentions the official data source and return fields, but does not disclose rate limits, authentication needs, or error behavior. For a simple search tool, it provides moderate transparency.

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 concise sentences, front-loaded with purpose and return, followed by usage guidance. Every word adds value with 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?

For a simple search tool with one parameter and no output schema, the description covers purpose, return values, and usage context. It is mostly complete, though it lacks error handling or pagination notes.

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 coverage is 0%, but the description explains that the query parameter can be a name or postcode, adding crucial meaning beyond the schema. However, it does not specify format details (e.g., numeric postcode, case sensitivity).

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 finds Swiss communes by name or postcode using the official ESTV register, and it returns commune name, canton, and postcode. It also distinguishes from siblings by mentioning when to use it before commune_tax or estimate_net_move.

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 recommends using this tool before commune_tax or estimate_net_move when spelling is uncertain, providing clear context. It does not include explicit when-not usage, but the positive guidance is strong.

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?

No annotations are provided, so the description carries the full burden. It clearly indicates a read operation returning dates and subjects, with language options and data source. No destructive or hidden behavior is apparent.

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, well-structured sentence that conveys all essential information without any wasted words.

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 a tool with zero parameters and no output schema, the description sufficiently explains what the tool returns (dates, subjects, languages, data source). No additional context is needed.

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?

There are no parameters, and the schema has 100% coverage (empty object). The description adds value by specifying the output (dates, subjects, languages, source), going beyond the empty 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 provides next Swiss federal vote dates and ballot subjects in multiple languages, using official data sources. This is specific and distinguishes it from sibling tools like 'book_consultation' or 'get_trend'.

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 the tool is for retrieving upcoming Swiss vote information, but does not explicitly state when to use it over alternatives. However, the context is clear given the siblings cover different domains (e.g., commune taxes, cantons).

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