Zügle

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

With no annotations provided, the description carries the full behavioral burden. It clearly discloses that the result is a duration in minutes, that it is for public transport, and that it relies on the national timetable—useful context beyond the raw schema. It does not cover edge cases like unavailable routes or real-time delays, but this is a simple lookup tool.

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 action, output, mode, and geographic scope with no filler. 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?

The tool is simple: two string parameters with clear schema descriptions and no output schema needed because the return value is described as 'time in minutes.' The description fully covers what an agent needs to know to 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%, with both 'from' and 'to' already documented with examples and constraints. The description adds the contextual framing of 'two Swiss places,' which aligns with the parameters, but it does not add meaningful semantic detail beyond what the schema 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 ('Returns'), an explicit resource ('public-transport journey time in minutes'), and a clear geographic scope ('between two Swiss places'). The sibling tools are unrelated (municipalities, tax, listings), so the tool is easily distinguished without needing extra differentiation.

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 intended use clear: retrieve a public-transport journey time in minutes between Swiss places. It does not explicitly name alternatives or exclusions, but the sibling tools are in entirely different domains, so there is no ambiguity about when to use this 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?

无注解，描述承担全部行为披露责任。它明确揭示了三个关键行为：有意包含成本相近的市镇（不排除）、基于缓存数据可能导致部分结果、响应会报告覆盖候选数。这些信息超出了基本'排名'的含义，帮助代理设定预期。

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?

两句话完成核心功能定义和限制说明，第一句话前置排名逻辑，第二句话补充数据局限性。没有任何冗余信息，每个字都发挥作用。

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?

没有输出schema，描述部分说明了返回内容（排名和覆盖数），但未描述返回列表的结构（如是否包含市镇名、节省金额）、排序方向（降序/升序）或可选参数（如currentRooms）如何影响计算。对于一个6参数的工具，这些缺口中等严重。

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覆盖率100%，每个参数都有描述。描述本身未增加参数语义，仅通过'stated current home'隐含关联currentBfsId。按基线规则，在高覆盖情况下即使无额外参数信息也评为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?

描述以具体动词'Ranks'开头，指定资源'municipalities'和排名标准（更便宜或低于CHF 1000/年以内，按年度税收节省额）。这与兄弟工具如tax_lookup（单一税额查询）或municipality_seearch（搜索）有明显区别，代理能清晰识别其功能。

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?

描述说明了数据来源（缓存）和结果可能不完整，但未明确说明何时使用此工具而非tax_lookup或municipality_detail，也未提及替代方案或排除条件。使用场景是隐含的，需要代理自行推断。

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?

There are no annotations, so the description carries the behavioral transparency burden. It does disclose the core behavior: searching by name or postcode and returning matches with BFS id, name, canton, and postcodes. However, it does not clarify behavior when both q and zip are supplied, result ordering, empty-result behavior, or whether the search is exact/substring/fuzzy, leaving meaningful behavioral gaps.

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 three short sentences with no filler. The main action and search modes are front-loaded, the return fields are listed, and the relationship to other tools is stated efficiently. Every sentence earns its place.

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

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

For a simple lookup tool with no output schema, the description explains what is returned and why the result matters for subsequent tools. The parameter details are covered by the schema. It is mostly complete; only minor edge-case semantics like combined q/zip usage or result ordering are absent.

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?

Input schema coverage is 100%, so the schema already fully documents q, zip, and limit with rich examples and constraints. The description adds no per-parameter meaning beyond restating that search can be by name fragment or postcode, which meets but does not exceed the baseline for fully-covered schemas.

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 ('Finds') and resouce ('Swiss municipalities'), modifiers it by search mode ('by name fragment or postcode'), and lists the return fields (BFS id, name, canton, postcodes). It also distinguishes itself from the other municipality tools by noting that the BFS id is the key those tools take, making its role clear.

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

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

The description gives clear usage context: this tool is the municipality lookup that produces the BFS id used by every other tool here. It implies 'use this first, then call the other tools with the BFS id', which is actionable, though it does not explicitly enumerate when-not-to-use scenarios or name alternative 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?

No annotations are present, so the description carries the disclosure burden. It adds real behavior beyond the name: the tax is split into federal, cantonal and municipal parts and the figures come from the federal tax administration's calculation. It does not state limitations or side-effect information, but for a read-only lookup this 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 concise sentences with no waste. The first sentence front-loads the verb, resource, and output structure; the second adds the authoritative data source. Both sentences earn their 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?

There is no output schema, but the description explains the return shape at a useful level (three tax components) and identifies the data source. It leaves minor gaps such as not explicitly connecting bfId to municipality_search, but the schema and sibling context largely fill these for 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?

Schema description coverage is 100%, so the schema already documents all six parameters with meaningful descriptions. The description adds little beyond confirming the 'gross income' basis, which the income parameter already states; it does not need to repeat schema detail.

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 ('Calculates') and resource ('annual Swiss income tax for one municipality and one household profile'), and further details the output as federal, cantonal and municipal parts. This clearly distinguishes tax_lookup from sibling search, listing, commute, and municipality 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 intended use is implied ('Calculates the annual Swiss income tax for one municipality and one household profile'), but the description gives no explicit guidance about when to choose this over alternatives such as favorable_municipalities or listing_search, and no when-not-to-use cases.

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