Zügle

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

With no annotations, the description carries the behavioral burden. It meaningfully discloses that 'Some pricing regimes are approximations rather than an exact tariff', which is an important accuracy limitation for an agent to know. It does not describe output shape or error behavior, but it does surface the key non-obvious trait.

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 core purpose and currency, followed by a concise caveat. Every word earns its place and nothing repeats the input schema.

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 what the tool computes, the currency, time horizon, and precision caveat. However, without an output schema or annotations, it leaves the exact return value/format and behavior for invalid or unknown places unspecified, keeping it from being fully complete.

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

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

Schema description coverage is 100%, so both from and to are already documented. The description adds the Swiss fare-zone context but does not need to explain parameters further; 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 verb 'Estimates' and object 'monthly cost in CHF of commuting between two Swiss places' make the tool's purpose very clear. It reads as the cost counterpart to the sibling commute_time tool, though it does not explicitly name or differentiate itself from any sibling.

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 use case: estimating monthly transit-pass commuting costs between Swiss locations. It gives no explicit guidance on when to choose commute_cost over commute_time or other sibling tools, and no exclusions or alternative suggestions.

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 the full disclosure burden. It does state the output type ('time in minutes') and the data source ('national timetable'), but omits any edge-case behavior such as how departure time is handled, accuracy, or error conditions. This is a minimum viable disclosure for a read-only lookup.

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, information-dense sentence with no filler. It front-loads the core return value and efficiently conveys mode, scope, and data source.

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 two-parameter, read-only tool without an output schema, this description is complete: an agent knows exactly what result to expect (minutes), the input restrictions (place/station names), and the scope (Swiss public transport). 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?

The input schema already provides 100% parameter coverage, describing both 'from' and 'to' as place/station names and noting the default value for 'to'. The description adds no additional parameter-specific meaning, so it does not need to compensate; the baseline 3 applies.

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 function with a specific verb ('returns') and resource ('public-transport journey time in minutes between two Swiss places'), adding the data source ('national timetable'). This strongly differentiates it from the sibling commute_cost, which presumably addresses cost rather than time.

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 about when to use the tool: for public-transport travel times in Switzerland. While it does not explicitly name alternatives or exclusion conditions, the precise scope makes the appropriate use case unambiguous relative to the listed sibling tools.

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

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

With no annotations, the description must carry the behavioral burden, and it does: it discloses cached-only figures, potential partial rankings, the deliberate inclusion of near-identical municipalities, and error reporting for unrecognized places. This is substantial behavioral context 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 compact and front-loaded: ranking criteria first, data caveat second, parameter guidance third. Every sentence contributes a distinct piece of information, with no repetition of schema fields.

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 an 8-parameter tool with no annotations and no output schema, the description covers the core decisions: what is ranked, on what basis, with what data limitations, and how errors surface. It does not describe the response shape beyond coverage count, but that is a minor gap given the strength of the rest.

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

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

The schema already documents all 8 parameters, so adding param detail in the description is bonus. The description contributes a useful semantic link between `near` and `radiusKm` and the household context, but it does not materially expand parameter meaning beyond the schema's 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?

States specifically what the tool does: ranks municipalities by annual tax saving against a current home, with a precise inclusion threshold (cheaper or within CHF 1000/yr). This clearly differentiates it from sibling tools like municipality_search or tax_lookup.

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 tells the agent how to scope results via `near` and `radiusKm` and flags unrecognized places, but it never explicitly says when to choose this tool over siblings or what conditions favor alternatives. Usage context is implied by the ranking purpose rather than stated as a routing rule.

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 transparency burden and adds meaningful caveats: figures are indicative, sourced from a portal feed, and not verified against the listing page. It also discloses the sorting behavior ('cheapest first'), though it leaves out subtle behaviors like the re-ranking effect of rooms/surface, which are documented in 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?

Two tightly written sentences: the first states the tool's core purpose and ordering, the second provides the important reliability caveat. There is no filler or repetition of schema details.

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-oriented search tool with fully documented parameters, the description explains what the caller gets (listings plus median rent) and its reliability limitations. It does not detail return structure, but no output schema exists and the listed information is sufficient for an agent to select and invoke the tool; only error/edge-case behavior 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 schema already explains each parameter clearly. The description reinforces 'bfsId' as a single municipality and implies the sort order, but it does not add meaning beyond the schema's own descriptions, 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?

The description uses a specific verb ('Lists') and a clear resource ('apartments currently advertised in one municipality'), and adds distinct ordering ('cheapest first') and the local median rent. This clearly differentiates it from siblings like municipality_search, which target municipalities rather than rental listings.

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 that the data is for browsing only, implying it should not be used for verified decisions. It does not explicitly name alternatives or exclusion conditions, but the sibling tools are sufficiently different in scope that the intended use case is evident.

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 present, so the description carries the burden. It clearly indicates a read-only operation ('Returns'), spells out what the result contains, and discloses a limitation (trend only where past years are known). It stops short of explaining output format or error/not-found behavior, but for a query tool this is sufficiently transparent.

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 focused sentence with front-loaded verb and resource, a colon introducing the output items, and a trailing caveat. No filler, repetition, or 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?

With 7 parameters and no output schema, a richer description would normally be expected, but the description names all key outputs and the key limitation. It could define 'tax multiplier' or the sign convention of the annual difference, yet an agent already has enough to select and 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 coverage is 100%, so the parameters are fully described in the schema; the description adds only a conceptual link (current home -> currentBsId, trend -> years) without providing new semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Returns'), a specific resource ('tax picture for one municipality relative to a stated current home'), and enumerates the output components (annual difference, tax multiplier, multi-year trend). The comparative 'relative to' distinguishes it from siblings such as tax_lookup and favorable_municipalities.

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 use case (comparing a candidate municipality to the current home) and includes a caveat about known past years, but it never explicitly tells the agent when to choose this tool over siblings like tax_lookup or favorable_municipalities, nor provides exclusion criteria.

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 behavioral burden. It discloses that the tool searches by name fragment or postcode, returns multiple matches ('for each match'), and what output fields to expect. It does not mention edge cases like empty results or behavior when both q and zip are supplied, but for a simple search tool the disclosed behavior is reasonably transparent.

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 focused sentences with no fluff. The first sentence names the action and search keys; the second specifies the return fields and the key's significance. Information is front-loaded and 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?

The tool has no output schema, so the description's enumeration of returned fields (BFS id, name, canton, postcodes) is essential and present. It also provides the cross-tool context of BFS id being required by siblings. Minor gap: it does not explicitly say that q or zip is expected to be provided, though the search framing implies 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?

The input schema already covers all three parameters with descriptive names and examples, so schema coverage is 100%. The description adds no new parameter-specific meaning beyond what the schema provides: the schema already defines q as a name fragment and zip as a Swiss postcode. 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 and resource: 'Finds Swiss municipalities by name fragment or postcode.' It also specifies the return fields (BFS id, name, canton, postcodes) and explicitly positions the BFS id as the key for all other tools, clearly distinguishing this lookup/search tool from siblings like municipality_detail.

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 phrase 'The BFS id is the key every other tool here takes' provides strong contextual guidance for when to use this tool: as the entry point before calling other municipality-related tools. It does not explicitly state conditions like 'use municipality_detail if you already have the BFS id', but the implied routing is clear enough for an agent.

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 behavioral disclosure burden. It discloses a non-obvious limitation: BFS does not publish rent below canton level except for 10 cities, so results may describe the canton, and it tells the caller that the response identifies which scope applies. This is valuable transparency 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?

Two sentences, no filler. The main purpose is front-loaded in the first sentence and the important data-scope caveat occupies the second without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity, two-parameter retrieval tool with no output schema, the description covers the operation, the optional parameter, and the key output nuance (whether the figure is municipal or cantonal). It could optionally state units/currency, but that is a minor 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 description coverage is 100%, including bfsId provenance and rooms examples, so the baseline applies. The description adds only general meaning that rooms are an optional size filter, which is already represented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Reports') and identifies a precise resource: the Swiss Federal Statistical Office's average monthly rent for a municipality, with an optional room-size filter. This distinguishes it from sibling tools like listing_search or tax_lookup because it names the official statistical source and the rent metric.

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 makes the tool's domain clear and implies it should be used when an official BFS average rent figure is needed. However, it never explicitly states when to prefer this tool over siblings such as listing_search or favorable_municipalities, and gives no 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?

With no annotations, the description carries the behavioral burden. It usefully discloses the data source and the split output, but it does not mention read-only behavior, error cases, or limitations such as unsupported municipalities or income values.

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 with the main action and scope front-loaded, followed by a useful data-source clarification. Every sentence earns its place and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers scope, inputs, and the high-level output split even without an output schema. It could provide more detail about exact return structure and error behavior, but the schema fills most parameter gaps.

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

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

The schema already documents all six parameters with names, defaults, enums, and ranges, so the high-coverage baseline applies. The description adds helpful context by mapping 'gross income' and 'household profile' to the schema, but it does not substantially go beyond it.

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?

States a precise operation—calculating annual Swiss income tax—and explicitly scopes it to one municipality and one household profile. The federal/cantonal/municipal split is clearly identified and differentiates it from the sibling municipality and listing 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 implies use when tax figures are needed, and the sibling names hint at alternatives, but it never explicitly states when to prefer this tool over others or when not to use it. No exclusion criteria or alternative routing is provided.

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