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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the input/output transformation detail but does not disclose behavior for ambiguous addresses, no-match results, or how the limit parameter affects results.

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 tight sentences with no fluff. The first sentence states the core action and outputs, and the second adds useful conceptual framing. 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 core purpose and input/output direction are clear, and the output schema covers return values. However, the description omits behavior around multiple matches and the meaning of 'limit', which an agent would need for fully confident 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 0%, so the description must compensate for parameter documentation. It clarifies the 'address' parameter through 'address in → federal building identifier out', but it says nothing about the 'limit' parameter, leaving a required semantic gap.

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 ('Geocode') plus a precise resource and output ('Swiss address to EGID/EDID and LV95 coordinates'). It clearly differentiates this tool from siblings like lookup_building or buildings_in_bbox by framing it as the address-to-identifier bridge.

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: this tool exists to convert addresses into federal building identifiers, making other data sources EGID-capable. It does not explicitly name alternatives or state when not to use it, so it stops short of full usage-rule guidance.

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 readOnlyHint annotation already covers the safe-read behavior; the description adds that the tool aggregates/counts buildings and dwelllings. It does not describe filtering semantics, aggregation dimensions, or limits, but the annotation lowers the burden somewhat.

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 tight and front-loaded: purpose, use-case example, and coordinate context each earn their place. There is no filler or redundant restating of the 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?

Given six parameters and no schema descriptions, the description covers the core bounding-box concept but leaves canton and since_year behavior unexplained. The output schema and readOnly annotation fill some gaps, but the definition is not fully self-sufficient.

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 0%, so the description must compensate. It explains the LV95 coordinate system and plausible numeric ranges for the four required bounding-box parameters, and 'new construction' hints at a time filter. However, the optional canton and since_year parameters are not explicitly explained.

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 opening sentence states a specific action ('Aggregate buildings/dwellings') and resource constrained to an LV95 bounding box, making the tool's purpose clear. It does not explicitly differentiate from siblings like new_construction or lookup_dwellings, 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 school-district example implies a sub-municipal analysis use case, giving some contextual guidance. However, it does not name alternative tools or state when not to use this tool, leaving routing decisions to inference.

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, so the description's additional information about status breakdowns and the interpretation of 'under construction' as an early indicator adds useful behavioral context. However, it does not disclose potential limitations like data availability by municipality or time-range constraints.

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 concise sentences: the first states the core purpose, the second details the status categories, and the third explains the practical implication. Every sentence adds value, and the content is front-loaded with the most critical information.

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 and the tool's moderate complexity, the description covers the data meaning and use case. However, it omits parameter semantics and does not specify what the output contains or how to interpret the status codes fully (though codes are listed). The description is adequate but not comprehensive.

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 0% description coverage for its two parameters (canton, municipality_bfs). The description does not mention these parameters or provide any guidance on their values, formats, or roles. With no schema descriptions and no parameter information in the description, the agent receives no help beyond the schema structure.

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 specifies the tool retrieves buildings and dwellings in the planning/construction pipeline of a municipality, with explicit breakdowns by status codes. This verb-resource combination is distinct from sibling tools like lookup_dwellings (likely existing dwelling data) and new_construction (new building registrations). The context of early indicator for school-space planning further differentiates its use case.

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 getting pipeline data for a municipality and hints at its value for school-space planning, but it does not explicitly state when to prefer this tool over siblings or when not to use it. No exclusions or alternative recommendations are provided.

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

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

Annotations already declare readOnlyHint=true. The description adds value by stating the tool never returns empty records and reports last refresh time, which is beyond what annotations provide. 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?

Two sentences, no wasted words. The key information is front-loaded and every sentence contributes meaning.

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 zero parameters and the existence of an output schema, the description adequately covers the tool's behavior and return value. It is sufficient for the agent to understand what to expect, though it doesn't detail the output structure.

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?

No parameters exist, so the baseline is 4. The description correctly adds no parameter information since none are needed.

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 shows cache status of GWR dumps with graceful degradation. It is distinct from sibling tools like lookup_dwellings which retrieve data. No explicit differentiation from siblings, but the purpose is 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 implies usage for checking cache health even when sources are unreachable, but does not explicitly state when to use it over alternatives. It provides context but no exclusions or direct guidance.

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, so the read-only nature is clear. The description adds value by specifying the source of the labels (official code table) and the supported languages (DE/FR/IT), going beyond what annotations provide.

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 very concise at two sentences, but the second sentence could be more structured or broken into bullet points for clarity. No superfluous information, but room for slight improvement.

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 moderate complexity (3 params, no enums) and the presence of an output schema, the description adequately covers the main purpose. However, it lacks explanation for the optional parameter and does not mention the output schema's structure, resulting in moderate completeness.

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?

With 0% schema description coverage, the description bears the full burden of explaining parameters. It includes an example of 'attribute' and 'code' but does not describe the optional 'canton' parameter at all, leaving a gap in understanding.

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 decodes GWR code values into human-readable labels, with a specific verb and resource. It provides an example of inputs (GSTAT=1004) and distinguishes itself from sibling tools that handle different tasks.

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 for decoding codes from a specific code table, but does not explicitly state when to use this tool vs alternatives, nor does it mention any prerequisites or when not to use it. Sibling tools have different purposes, so some implicit differentiation exists.

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 openWorldHint=true, so the incremental bar is low. The description adds the live-API behavior ('always current, no dump download needed') and explains the EGID's role as a join key, which is useful 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?

Three short sentences, no filler; purpose is front-loaded in the first sentence and the remaining sentences each add one relevant fact (live API, EGID role).

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 lookup with an output schema, the description is nearly complete: it states the resource, the identifier semantics, and data source. It could optionally mention routing to siblings (e.g., use address_to_egid when no EGID is known), but that gap is minor for this simple tool.

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

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

Schema coverage is 0% and the schema only names the property 'egid' with type integer. The description defines EGID as a federal building identifier and the cross-administrative join key, adding the missing semantic meaning, though it stops short of providing an example or value-format details.

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 opening sentence states a specific action and resource: 'Look up a single building by its EGID (federal building identifier).' The qualifier 'single building' plus EGID distinguishes it from siblings like buildings_in_bbox and address_to_egid, so a user can select it correctly.

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: it should be used for exact EGID lookups against the live geo.admin.ch API, and it explicitly avoids needing a dump download. It doesn't name sibling alternatives or state exclusions, but the 'single building by EGID' phrasing implies the boundary.

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. The description adds context (data source 'daily cantonal dump' and included fields) but does not disclose behavior beyond that, such as error handling or permissions. 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 concise (two sentences) and front-loaded with the core action. However, it could be slightly more structured with bullet points for clarity.

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 list tool with an output schema, the description adequately mentions included fields but omits explanation of the required 'egid' parameter and the default value for 'canton'. The data source reference is vague.

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 0%, so the description should explain parameters. However, it does not mention 'egid' as building ID or 'canton''s role. It only references 'a building' implicitly, leaving parameter semantics unclear.

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: 'List all dwellings (EWID) of a building' and specifies included attributes (rooms, floor area, floor, status). This distinguishes it from sibling tools like new_construction or dump_status.

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 but not explicit. The description does not mention when to use this tool versus alternatives, nor does it provide conditions for appropriate use.

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

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

The annotations already carry readOnlyHint=true, so the description's lack of behavioral disclosure is partially mitigated. However, it adds no extra context beyond that – no mention of data freshness, aggregation details, or limitations. Since the description does not contradict the annotation, it is not a failure, but it also provides no additional transparency value.

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 delivers the core message immediately with no filler. It is perfectly sized for the amount of information it conveys, even though that information is incomplete elsewhere.

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 (not provided) but the description fails to cover critical input usage: it doesn't explain the relationship between canton and municipality_bfs, how to obtain a BFS number, or what kind of output is expected (though the schema covers returns). Combined with zero parameter guidance and no sibling differentiation, an agent would likely struggle to invoke this 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 0%, and the description says nothing about either parameter. It does not explain that municipality_bfs is a BFS identifier, whether canton is optional, or how they interact. The agent must guess the meaning from the name, which is risky. This is a severe omission for a required integer 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 clear verb and resource: it provides a housing stock overview for a municipality, specifically listing buildings, dwellings, and room-size mix. This is specific enough to distinguish it from tools like lookup_dwellings (which focuses on individual dwellings) and new_construction (which covers future builds). However, it does not explicitly contrast it with any sibling, so it lacks the direct differentiation seen in top-tier descriptions.

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

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

No guidance is given on when to use this tool versus alternatives. It neither states scenarios nor mentions sibling tools. An agent cannot know whether to pick this over lookup_dwellings or buildings_in_bbox from the description alone, leaving the decision entirely to inference.

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 indicate readOnlyHint=true. Description adds context about the 4+ room share being a proxy for family housing, but does not disclose any additional behavioral traits such as data source, update frequency, or limitations.

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?

Description is two sentences, efficiently conveying core purpose and a key interpretation note. No redundancy or fluff.

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, return value explanation is not needed. However, the description lacks usage context and does not fully cover parameters. Adequate but with 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?

Schema description coverage is 0%. Description only explains municipality_bfs with an example. Parameters canton and since_year are not described at all, leaving their semantics unclear.

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 clearly states it returns annual new residential construction data for a municipality, including buildings, dwellings, and 4+ room dwellings. However, phrasing 'existing buildings' may cause confusion about whether it covers new construction or existing stock.

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

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

No guidance on when to use this tool versus siblings like lookup_dwellings or construction_pipeline. Does not mention alternatives or exclusions.

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