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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the data source and returned fields, but does not disclose additional behavioral details such as error cases or whether the result is a simple boolean or full record. 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 communicates the action, the resource, the specific data fields, and the authoritative source. There is no filler or redundant phrasing.

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 one-parameter, read-only, idempotent lookup tool with a high-coverage schema and an output schema present, the description conveys all needed selection and invocation information. The source is named, and annotations cover safety and behavior, leaving no critical gap.

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 parameter description already explains that name_or_uid accepts a company name or UID format. The tool description adds little beyond echoing 'UID' and the general purpose, so it does not significantly enhance what the schema already provides. 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 states a specific verb ('check'), a resource ('whether a company is registered'), and the exact data points returned (UID, legal seat, commercial register, VAT status). It clearly singles out the federal UID register, making it easy to distinguish from sibling tools like search_official_info or swiss_place_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 scope is clear: this tool is specifically for checking Swiss company registration via the federal UID register. Although it does not explicitly name excluded alternatives, the domain is narrow and distinct from the other Swiss information tools, so an agent can infer when it should be selected.

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, so the safety profile is covered. The description adds that it returns measured data only (no forecasts) and clarifies the source (MeteoSwiss station) and the selection criterion (nearest to a Swiss municipality). This adds context beyond annotations without contradicting them.

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, information-dense sentence that front-loads the core purpose and immediately clarifies the scope and limitation. No wasted words, and the structure is easy to parse.

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 an output schema, so return format is covered. The description explains what data it returns, where it comes from, and what it doesn't do. With annotations handling safety and the schema handling parameters, nothing essential is missing 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?

The input schema has 100% description coverage for both parameters, including examples for 'place' and an enum with default for 'language'. The description adds no additional parameter-specific meaning, which is acceptable since the schema already fully documents them. 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 latest measured weather (temperature, humidity, precipitation, wind) at the MeteoSwiss station nearest to a Swiss municipality. It also explicitly notes 'Measurements only, no forecasts,' which sharply distinguishes it from any forecast tool. No sibling covers weather, so this is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear context: for current measured weather at a Swiss location. It explicitly excludes forecasts ('Measurements only, no forecasts'), which tells the agent when not to use this tool. While it doesn't name an alternative, none exists among siblings, so the guidance is sufficient.

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. The description adds the dual-mode behavior (subjects for next vote vs. results for past vote), which is not in annotations. It does not disclose any other behavioral traits like data freshness or error handling, but given the strong annotation coverage, 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, well-structured sentence that front-loads the two primary outcomes. There is no filler or repetition; every word contributes to the purpose.

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 a complete schema (100% param descriptions), an output schema, and strong annotations, the description adequately covers the tool's purpose. It mentions the key distinction between future subjects and past results, which is the main contextual nuance. It does not need to detail return structure since an output schema exists.

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 provides full descriptions for all three parameters (place, language, vote_date) with 100% coverage. The description does not add any additional parameter semantics beyond what the schema already conveys, so a 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 states the tool's core function: returning subjects of the next federal popular vote or official results of a past vote. It clearly identifies the resource (federal votes) and the two operational modes. It does not explicitly distinguish from siblings, but the sibling list (transport, weather, law) makes the purpose distinct enough.

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: when a user asks about federal vote subjects or results. However, it does not explicitly mention alternatives or exclusions, such as 'use search_official_info for other federal topics'. The usage context is clear from the description but not formally stated.

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 meaningful context beyond these: it names the official FOPH data source, says it matches priminfo.admin.ch, and stresses that every plan is basic insurance, preventing confusion with supplementary coverage. 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 a single sentence that front-loads the core purpose and includes useful clarifications (language synonyms, basic-insurance-only scope, official source). It is slightly dense with parentheticals but every element earns its place 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?

With a full output schema, complete parameter descriptions, and safety annotations, the tool definition is largely self-sufficient. The description adds the data source and scope boundary. Minor details like data freshness or result-count behavior are not addressed, but they are not critical given the existing structured 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 description coverage is 100%, so the parameters are fully documented in structured form. The description restates the key filters (municipality, age, deductible) but adds no constraints or format details beyond what the schema already provides. A 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 identifies the resource: the cheapest mandatory basic health insurance premiums, scoped by municipality, age, and deductible, from official FOPH data. Though the verb is implicit, the action and domain are unambiguous and clearly distinct from the other Swiss-related tools in the sibling list.

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 states what the tool returns and clarifies that only basic insurance is included, which implies when to use it. However, it does not explicitly contrast it with sibling tools such as swiss_rates or search_official_info, nor does it state when not to use it. Usage guidance is implied rather than explicit.

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, so the description only needs to add value beyond those hints. It adds that the data is 'official timetable data' and that the tool supports two modes, which is useful context about the result nature. 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?

One sentence with no filler; the geographic scope, data source, and dual modes are front-loaded. It is as concise as possible while giving the essential purpose.

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 query tool with an output schema and well-documented optional parameters, the description is nearly complete: it names the domain, scope, and modes. A small gap is not explicitly instructing when to use 'connections' vs 'next departures', but the schema's destination parameter covers this.

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 the schema carries most parameter documentation; the description does not repeat or add parameter-level detail. The one undocumented parameter (limit) is adequately constrained by min/max/default in the schema, so this is acceptable.

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 a specific resource ('Swiss public transport') and the two main operations ('connections or next departures'), making the tool's purpose immediately recognizable. It lacks an explicit verb such as 'search' or 'get' and does not explicitly contrast with sibling tools, but no other sibling covers public transport.

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: whenever a user needs Swiss public transport connections or a departure board. It does not state exclusions or compare with alternatives such as swiss_place_info or swiss_coverage, so usage guidance is inferred rather than explicit.

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 adds meaningful behavioral context beyond the annotations: it mentions the tool is 'live, respecting robots.txt', which is not covered by readOnlyHint or idempotentHint. It also clarifies the output behavior (passages around focus). While it doesn't discuss rate limits or error handling, the annotations already cover safety, and the added details are useful. 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 the primary action and restriction front-loaded. Every phrase serves a purpose: it states the action, the live/robots.txt behavior, the focus-passage output, and the domain restriction. No fluff or 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 that an output schema exists, the description does not need to detail return values. It covers the tool's purpose, the key behavioral nuance (robots.txt), and the focus mechanism. The only minor gap is the lack of explicit guidance on error cases or what happens when the URL is not on an official domain, but these are not critical for an agent to call 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?

Schema coverage is 67% (url and focus have descriptions, max_chars does not). The description adds value for the 'focus' parameter by explaining it is used to return surrounding passages, which complements the schema's example. However, it does not explain 'max_chars' or its constraints, and the description does not fully compensate for the missing schema description on 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 clearly states the verb 'Fetch', the resource 'official Swiss page', and the specific behavior of returning passages around a focus word. It also imposes a domain restriction, which distinguishes it from generic web-fetch tools and sibling tools like search_official_info. The purpose is unmistakable.

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 does not explicitly state when to use this tool versus alternatives, nor does it name any sibling tool. It implies usage for reading a specific official page (since it says 'typically from search_official_info' in the parameter schema, but not in the main description). The guidance is implicit, relying on the agent to infer that this is for fetching a known URL rather than searching.

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 readOnly/idempotent/destructive safety, and the description adds substantive behavioral context: it scopes place-based filtering ('federal + that canton/municipality') and reveals the output shape ('Returns verbatim excerpts with URLs'). This goes beyond what annotations and schema alone convey.

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 compact, front-loaded with the core purpose, and each sentence adds useful detail (scope, use cases, place behavior, output format). 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?

With an output schema present and rich annotations, the description covers the main operational points: scope, use cases, place filtering, and output format. It omits details like pagination and rate limits, but for a read-only search tool with output schema, this is near-complete. It could still benefit from an explicit pointer to sibling tools (e.g., swiss_federal_law) for law-specific queries.

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 50%, so the description should help clarify parameters. It adds meaning for `place` by explaining its filtering effect. It does not mention `limit` or `language` behavior, and the schema already documents `query`, `place`, and `language`. The description's extra value is moderate.

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 ('Full-text search') and a precise resource ('official Swiss web pages: ch.ch, federal offices, the 26 cantons and large cities'), making the tool's purpose immediately clear. It does not explicitly name sibling tools to distinguish from, so it stops short of a 5.

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 says 'Use for procedures, rules, deadlines, fees and "how do I…" questions' and lists concrete example topics. This gives clear context for when the tool is appropriate, though it does not state when not to use it or name 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?

The annotations already convey read-only, idempotent, and open-world behavior, so the description's burden is low. It adds value by specifying which coverage dimensions the tool reports and explicitly mentioning that it also states what is not covered, which helps set expectations about the response.

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 carry the full meaning: the first states what the tool lists, the second states precisely when to call it. There is no filler, and the key scoping guidance is 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?

For a parameterless coverage tool with rich annotations and an output schema, the description is complete. It tells the agent what to expect from the tool and when to use it, leaving no meaningful gap for selection or 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 description cannot add parameter-level meaning. The baseline for parameterless tools is 4, and the description correctly focuses on what information the tool returns instead of inputs.

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 a specific verb ('List') and a concrete resource: the server's coverage across topics, geography, sources, and freshness. It also explicitly states what the tool does not cover, which clearly differentiates it from the domain-specific 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?

The description gives an explicit condition for use: 'Call this only when unsure whether a question is in scope.' This tells the agent exactly when to invoke this meta-coverage tool and implies that confident, in-scope questions should go to the relevant sibling tools instead.

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, so the tool's safety profile is clear. The description adds valuable behavioral context beyond annotations by specifying the source is the official consolidated text, that it is the version currently in force, and that article links will be included.

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 carry substantial, non-redundant information: source, version, output feature, and scope limitation. Nothing is wasted, and the key purpose is 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 the full input schema, the presence of an output schema, and the annotation set, the description covers the essential context: what source is used, which version, and what the output includes. It is not exhaustive about edge cases or parameter combinations, but the structured fields already handle those, so the description is complete enough for an agent 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?

Schema description coverage is 100%, so the baseline is 3 even though the tool description adds no detailed parameter semantics. The description's mention of 'article links' and 'federal law' loosely maps to the article and sr_number/query parameters, but it does not materially enrich the schema's parameter explanations.

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 operation ('Quote federal law'), the specific source ('official consolidated text on Fedlex'), the version ('currently in force'), and a distinctive output feature ('with article links'). It also distinguishes itself from broader legal or informational tools by explicitly limiting scope 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 provides clear context for when to use the tool: quoting federal law from Fedlex. The 'Federal law only; cantonal law is not included' statement gives an explicit when-not-to-use boundary. It does not name alternative sibling tools, so it falls short of a 5, but the usage scope is more than merely implied.

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, so the safety profile is fully covered. The description adds no behavioral details beyond the schema, such as data coverage limitations or how conflicts between place and year are resolved. No contradiction with annotations exists.

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, compact sentence that front-loads the core resource and its main scoping dimensions. Every word earns its place, and there is no redundant restating of the title or parameter names.

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 query tool with a rich output schema and complete parameter documentation, the description is sufficient for selection and invocation. A minor gap is that it does not clarify whether 'place' only applies to school holidays or also to public holidays, but this is not critical given the schema context.

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 covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds only a slight mapping by saying 'canton or municipality' for place and 'public holidays' for kind, which is already reflected in the schema text. No new semantic meaning is added.

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 the resource (school/public holidays) and the key scoping dimensions (place, year), which clearly distinguishes it from all sibling tools. It lacks an explicit verb like 'get' or 'list', but the intent is unmistakable and the title reinforces the subject.

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?

There is no explicit guidance on when to use this tool versus alternatives, or any exclusions. The use case is implied by the name and description, but the description does not state 'use this when the user asks for holidays' or mention any sibling it replaces or complements.

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 safe read-only nature is covered. The description adds useful behavioral context: it returns the 'latest BFS figure' and resolves to 'official municipality' data, clarifying that results are standardized and current. It does not discuss edge cases like ambiguous place names, but the annotation coverage lowers the burden.

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 and every part earns its place: a clear capability statement, an explicit list of returned fields, and concrete example use cases. It is front-loaded with the core action and output list before the usage examples.

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 single-optional-parameter lookup tool with a rich parameter schema, an output schema, and safety annotations, the description covers what the tool does, what it returns, and when to invoke it. Nothing essential is missing for an agent to select and call 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 description coverage is 100%, and the parameter's schema already explains accepted forms ('Lugano', '8003', 'Genf', 'Bahnhofstrasse 1, Zürich') and languages. The tool description adds no new parameter-level meaning beyond what the schema provides, so 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?

Description states a specific action ('Resolve a Swiss place to its official municipality') and a concrete resource, then enumerates the exact outputs: BFS number, canton, district, postcodes, population, and website. It also gives representative queries, making the tool's purpose unmistakable and distinguishing it from sibling tools like 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 explicitly lists trigger questions: 'how many people live in X', 'which canton is X in', and finding a municipality's website, which tells an agent when to use it. It does not explicitly state when not to use it or name alternatives, but the provided use cases are sufficient for a single-purpose lookup 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds modest value by stating the data is current and sourced via BWO/SNB, but it does not describe pagination, units, or any time-dependence beyond the word 'Current'.

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 covers both data modes with no filler. Every word contributes to the agent's ability to choose the right kind.

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 lookup with a full output schema and complete parameter schema, this description is sufficient. The only minor gap is that 'BWO' is not expanded in the description itself, though the schema's kind description also uses the acronym.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema documents all three parameters. The description adds the BWO/SNB context but essentially restates what the kind parameter's description already contains, so it provides no significant extra parameter semantics.

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 tool as providing two specific data products: the current BWO mortgage reference rate and SNB CHF exchange rates. It lacks an explicit retrieval verb, but 'Current ... or ...' makes the query intent clear and the two modes are distinct.

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 separates the two use cases (reference interest rate vs exchange rate), which tells an agent when to select this tool. It does not mention when not to use it, but none of the sibling tools covers this data domain, so exclusion guidance is less critical.

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, covering safety. The description adds behavioral context beyond that: it mentions the tool may request additional input ('the tool will say') and specifies the data source ('municipal open data'), which is not in annotations. This is useful supplementary information.

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, compact sentence that front-loads the core function and then gives a concise usage note. Every word serves a purpose, with no redundancy 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?

Given the tool's simplicity (4 optional, well-documented parameters, output schema present, safety annotations), the description is complete. It covers what the tool returns, what input is needed, and how it handles missing information. No critical operational detail 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%, so the baseline is 3. The description adds value by clarifying that a municipality is effectively required ('Needs the municipality') and that additional parameters may be needed conditionally, which is not captured in the schema's optional flags. This supplements the parameter documentation meaningfully.

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 ('Next waste collection dates') and resource (municipal waste data), and lists example waste types. It clearly differentiates from sibling tools like public_transport or current_weather, which address entirely 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 says 'Needs the municipality' and notes that some cities need postcode or street, giving practical input requirements. It does not explicitly name alternatives or state when not to use it, but the tool name and sibling context make the intended use obvious. Slight gap in explicit exclusion guidance.

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