Swiss Grounding

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 covered. The description adds the data source and fields returned, but does not disclose any additional behavioral traits such as freshness of data or limitations. This is adequate but not exceptional.

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, front-loaded sentence that states the purpose and scope without filler. Every element earns its place, and the most important operative details come first.

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, one-parameter lookup tool with a full input schema, an output schema, and complete annotations, the description is sufficient. Nothing essential for the agent to select and invoke the tool is missing.

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 100% and the single parameter 'name_or_uid' is clearly described with a format example. The description does not need to add parameter meaning, 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 uses a specific verb ('Check whether a company is registered') and names the exact resource and data scope: UID, legal seat, commercial register, and VAT status from the federal UID register. This makes it clearly distinguishable from sibling tools like search_official_info or read_official_page.

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 clear context for when to use the tool: to verify a company's registration and retrieve register details from the federal UID register. It does not explicitly name alternatives or exclusion cases, but the domain-specific focus is strong enough to guide 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 declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds beyond annotations by explaining that the tool resolves a Swiss municipality to the nearest MeteoSwiss station and that it returns measurements only, not forecasts. This gives useful behavioral context without contradicting the 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 a single sentence that is front-loaded with the key information ('Latest measured weather') and includes the essential variables and the 'no forecasts' exclusion. Every word adds value; there is no repetition or filler.

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, combined with full schema coverage, annotations, and an output schema, provides enough information for an agent to call the tool correctly. It could be slightly more explicit about behavior when 'place' is null or when the requested place is outside Switzerland, but these are minor gaps given the schema's default and 'Swiss municipality' qualifier.

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%, and the schema already documents both parameters well: 'place' explains accepted formats and language variants, and 'language' explains it is the user's question language. The tool description adds no additional parameter meaning, so the baseline score 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?

The description states a specific verb and resource: it returns the latest measured weather (temperature, humidity, precipitation, wind) from the MeteoSwiss station nearest to a Swiss municipality. It also clearly distinguishes itself from forecasts, so an agent can immediately understand what this tool does.

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 clear context: use it for measured weather at a Swiss location, not for forecasts. It provides the when-not-to-use signal 'no forecasts,' but does not name any alternative tool for forecasts. There are no weather-related siblings to contrast with, making the lack of explicit alternatives less impactful.

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 cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is well established. The description adds the next-vs-past distinction, which is useful, but it does not disclose additional behaviors such as output format or edge cases; those are partly covered by the schema.

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 sentence with no filler, front-loading the resource and the two retrieval modes. It is compact and 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?

For a simple read-only tool with full schema coverage and an output schema present, the description is largely complete. It conveys the core purpose clearly, though it could explicitly mention that 'place' adds a canton-specific result; the schema covers this detail.

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 all three parameters are already documented. The description adds no parameter-specific meaning beyond aligning vote_date with next/past, which the schema already states. 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 identifies the resource (federal popular votes) and the two modes: subjects of the next vote or official results of a past vote. It lacks an explicit verb like 'retrieve' or 'get', but it is unambiguous and clearly distinguishable from siblings such as swiss_federal_law or search_official_info.

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 the tool (for federal vote subjects or results) but does not explicitly state when to prefer it over alternatives or when not to use it. The schema's vote_date hint adds context, but the description itself provides no exclusions or alternative routing.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about the official data source and clarifies the scope (basic insurance only), which is useful but does not disclose additional behavioral traits like pagination or rate limits. It does not contradict the 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 a single, focused sentence that front-loads the core purpose ('Cheapest mandatory basic health insurance premiums') and includes necessary clarifications (multilingual terms, data source) without redundancy. Every clause adds value, and it avoids unnecessary verbosity.

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 6 optional parameters, full schema descriptions, and an output schema, the tool is well-documented. The description covers the primary inputs and purpose, and the source reference adds credibility. It does not describe return structure, but that is handled by the output schema. Minor gaps like pagination or error handling are not critical for a read-only tool with this annotation coverage.

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 provides 100% coverage with detailed descriptions for every parameter, so the schema carries most of the semantic weight. The description adds a general statement about the tool's purpose ('for a municipality, age and deductible') and reinforces that all plans are basic insurance, but does not add new parameter-level meaning beyond what the schema already specifies. 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 returns the cheapest mandatory basic health insurance premiums for a municipality, age, and deductible. It names the resource (premiums), the verb (get/cheapest), and the data source (official FOPH). It distinguishes itself from siblings by focusing on health insurance premiums, and the multilingual clarification ensures the agent knows it's specifically basic insurance.

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 (when a user asks for cheapest basic insurance premiums by place, age, deductible). It does not explicitly name alternative tools or conditions for when not to use it, but the context is unambiguous and distinguishes it from general rate or coverage tools like swiss_rates or swiss_coverage.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds minimal context ('official timetable data') but does not disclose behaviors like data freshness, rate limits, or any operational nuances. It does not contradict the 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?

A single, front-loaded sentence that conveys the core functionality without waste. It is appropriately sized for a tool whose parameters and safety are already documented in the schema and annotations.

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 5 parameters, but schema coverage is high and an output schema exists. The description explains the two modes (connections vs. departures) sufficiently, and the schema handles parameter details. Nothing critical for correct invocation is missing, though a sentence on typical use cases would strengthen it.

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 80%, so most parameters are already documented. The tool description adds the conceptual distinction between connections and departures, but this is also captured in the schema (destination: 'omit for a departure board'). Thus the description adds little beyond schema, warranting a baseline score of 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 provides Swiss public transport connections or next departures, using official timetable data. It names the specific resource (public transport) and the actions (connections or departures), distinguishing it from unrelated siblings like company_register or current_weather.

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 transport queries, but does not explicitly state when to use it versus alternatives. Since siblings are unrelated, the purpose is obvious, but there is no guidance on scenarios like planning a trip versus checking live departures, and no mention of 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 already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds meaningful behavioral context: it is 'live', 'respecting robots.txt', and restricted to 'official Swiss domains'. These go beyond annotations, though it does not address rate limits or error behavior. 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 a single, dense sentence that front-loads the primary action and key constraints. No wasted words; every clause contributes to understanding the tool's purpose and boundaries.

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 read-only fetch tool with an output schema, the description covers the essential behavior (live fetch, focus passages, domain restriction). It does not mention pagination or error handling, but these are likely covered by the output schema and are not critical for calling the tool. The description is sufficiently complete for an agent to use it 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?

Schema coverage is 67% (focus and url have descriptions; max_chars does not). The description clarifies 'focus' by referencing 'passages around `focus`' and reinforces the url domain constraint. However, max_chars is not mentioned, and the description does not fully compensate for the missing schema description of that parameter.

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 states a specific action ('Fetch the current text'), a clear resource ('official Swiss page'), and the output ('return the passages around `focus`'). It also specifies the domain restriction, distinguishing it from search and other tools. The verb and resource are 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?

The description implies a use case—reading a specific page—and the sibling 'search_official_info' is clearly the search counterpart. However, it does not explicitly state when to use this tool vs. alternatives or when not to use it. The context is clear but lacks explicit exclusions or alternative routing.

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 cover the read-only, idempotent, non-destructive nature. The description adds a behavioral detail beyond that: 'Returns verbatim excerpts with URLs.' It does not discuss rate limits or auth, but those are not essential for this tool type.

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 sentences, each earning its place: scope, use cases, and a parameter hint plus return format. The most important information (scope and purpose) is front-loaded, with no filler.

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 is complete for a read-only search tool. It covers scope, when to use it, the key parameter behavior, and the output format. An output schema exists to document the return structure, so the description doesn't need to expand on that.

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 exactly 50% (query and place have descriptions; limit and language do not). The description's mention of 'Give `place` to restrict results' restates the schema's existing description of place, adding little new meaning. It does not compensate for the undocumented limit and language parameters.

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 opens with a specific verb and resource: 'Full-text search over official Swiss web pages', then enumerates the exact sources (ch.ch, federal offices, cantons, cities) and lists concrete use cases. This clearly distinguishes it from siblings like swiss_federal_law (legal texts) or read_official_page (reading a specific page).

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 explicit use cases: 'procedures, rules, deadlines, fees and "how do I…" questions' with examples, which tells an agent when to invoke it. It does not explicitly name alternative tools or say when not to use it, so it stops short of a 5.

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 readOnly, idempotent, openWorld, and non-destructive hints, so the safety profile is covered. The description adds valuable behavioral context by specifying what content is returned (topics, geography, sources, freshness) and that it also states exclusions. It does not contradict 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?

Two sentences with zero filler. The core capability is front-loaded: it lists coverage dimensions and exclusions, followed by the single usage directive. 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?

For a no-parameter tool with a rich annotation set and an output schema, the description is fully complete. It tells the agent what to expect (coverage details) and when to use it. No additional information is needed for correct invocation.

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 tool has zero parameters, so the schema already fully defines the invocation signature. The description doesn't need to elaborate on parameters, and the baseline of 4 applies. It correctly implies the tool takes no arguments.

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 states it lists topics, geography, sources, and freshness, and what it does not cover. This clearly distinguishes it from sibling tools that focus on specific domains (e.g., weather, votes, law), making the 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?

Explicit usage guidance is provided: 'Call this only when unsure whether a question is in scope.' This instructs the agent when to invoke the tool and implies when not to (when certainty exists), though it doesn't name alternatives – none are needed for a coverage tool.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds useful behavioral context beyond annotations: it returns the official consolidated text, uses the version currently in force, and includes article links. There is no contradiction with 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 two sentences with no filler. The core behavior is front-loaded, and the scope limitation is stated in a compact second sentence. 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 the full schema coverage, rich annotations, and presence of an output schema, the description provides the necessary selection and invocation context: source, scope, version status, and link behavior. No critical information is missing.

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 input schema already documents all four parameters in detail. The description itself adds no parameter-specific semantics, which matches the baseline of 3 when the schema carries the burden.

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 a specific verb ('Quote') and a specific resource ('federal law from the official consolidated text on Fedlex'), and clarifies the version scope ('currently in force'). It also distinguishes itself from siblings by explicitly limiting to federal law and excluding cantonal law.

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 clearly states when to use the tool: to quote federal law from Fedlex. It also gives a when-not condition: cantonal law is not included. However, it does not name specific alternative sibling tools, so it stops short of fully explicit routing.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds minimal behavioral context beyond the schema, such as the scoping to canton/municipality for school holidays. It does not disclose return format, pagination, or edge cases, but with annotations carrying the safety burden, 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 a single, front-loaded sentence that immediately communicates the tool's purpose. Every word earns its place, with no filler or repetition of schema details. The title and description together are compact and 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?

Given the presence of an output schema, annotations, and a fully documented input schema, the description is sufficient for an agent to select and invoke the tool correctly. It does not explain that place is optional for public holidays or that language affects output, but those details are already in the schema. The only minor gap is not clarifying that 'public holidays' may not require a place, but this is inferable from the schema's default null.

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 all four parameters (kind, year, place, language) already have meaningful descriptions. The tool description does not add any semantic detail beyond the schema—it only restates the general topic. A baseline of 3 is appropriate when the schema fully documents parameters.

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 states a specific resource ('School holidays by canton or municipality, or public holidays') and a time scope ('for a year'). It clearly distinguishes this tool from siblings like federal_votes or public_transport by naming the exact domain. The verb is implied but unambiguous, and the title reinforces the purpose.

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: if an agent needs school or public holidays for a Swiss location and year, this is the tool. However, it does not explicitly state when to use it over alternatives, nor does it mention any exclusions or conditions (e.g., 'use swiss_place_info for place details'). The guidance is present only by inference from the tool's domain.

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 readOnly=true, openWorld=true, idempotent=true, destructive=false. The description adds useful context by specifying it resolves to official municipality data and cites 'latest BFS figure', so an agent understands the freshness of the result. No contradiction with 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?

Two sentences with no filler: the first defines scope and outputs, the second gives concrete query examples. Every clause contributes.

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 is simple, has rich annotations, an output schema, and a well-documented parameter. The main gap is that 'place' is optional in the schema but the description does not say what happens when it is omitted or defaulted to null.

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 provides 100% coverage for the single 'place' parameter, including examples like 'Genf' and '8003'. The description itself adds no new parameter detail, so the 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?

The description names the specific action 'Resolve a Swiss place to its official municipality' and enumerates concrete outputs: BFS number, canton, district, postcodes, population, and website. This makes it clearly distinct from siblings like current_weather and company_register.

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: 'how many people live in X', 'which canton is X in', and finding a municipality's website. It does not explicitly state when not to use the tool or name an alternative, so it falls just short of a 5.

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 the tool read-only, idempotent, and non-destructive. The description adds that results are 'current' and sourced from BWO/SNB, which is useful context, but it does not go further into limitations, rate update behavior, or currency scope beyond the schema.

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, tightly written sentence that immediately states the two supported data types. No filler or redundant explanation is present.

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 a full input schema, an output schema, and comprehensive annotations, the description is sufficiently complete for ordinary use. A small gap is that it does not clarify what happens when 'currency' is omitted for exchange_rate, but the schema and output schema likely cover that.

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%, with all three parameters already explained. The description mostly restates the kind options and does not add meaningful details beyond the schema, so the 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?

The description clearly identifies the tool as providing 'current mortgage reference interest rate for rents (BWO) or SNB CHF exchange rates', which names the two concrete data resources. It does not use an explicit verb like 'retrieve', but the meaning is unambiguous and distinct from the sibling 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?

Usage is implied: an agent should call this tool when asked for the BWO mortgage reference rate or SNB CHF exchange rates. However, it does not explicitly state when not to use it or name alternatives, so the guidance relies on inference rather than direct 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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: it depends on municipal open data and may ask for more location details, which aligns with openWorldHint and helps the agent anticipate a follow-up interaction.

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. The purpose is front-loaded, and the prerequisite/behavioral note follows immediately. Every clause 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?

For a read-only, idempotent lookup tool with an output schema and fully documented parameters, the description covers the essential operational detail: the required municipality and the possibility of needing more location input. The agent has everything needed to invoke it correctly or ask for missing information.

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 100%, so the baseline is 3. The description adds value by stating that the municipality is required even though no parameter is marked required, and that some cities need postcode or street. This goes beyond the schema's field descriptions and helps the agent decide what to ask the user.

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 identifies the resource: next waste collection dates for cardboard, paper, household waste, green waste, from municipal open data. It lacks an explicit verb like 'get' or 'list', but the meaning is unambiguous and distinct from the sibling tools, which cover different domains.

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 concrete usage guidance: the municipality is required, and some cities additionally need postcode or street, with the tool itself indicating when more input is needed. It does not explicitly contrast with alternatives, but the sibling tools are clearly different in purpose, so no exclusion is necessary.

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