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

Annotations provide readOnlyHint=true, so the safety profile is covered. The description adds the data source (swisstopo reframe service) and the easting/northing conventional mapping, which adds some context. However, it doesn't disclose output format, error behavior, or accuracy/precision details. With readOnlyHint=true covering the read-only nature, a 3 is appropriate.

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 zero waste. The first sentence states the core purpose, the second clarifies the critical easting/northing mapping detail for WGS84 direction. No 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?

The operation is a simple stateless coordinate conversion with clear annotations (readOnlyHint=true, idempotentHint=false). The description plus schema fully cover what the agent needs. The easting/northing mapping clarification and data source reference are valuable additions. An output schema exists, so return format details are not the description's burden.

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% for the top-level 'params' parameter, but the nested schema fields (easting, northing, direction) each have thorough descriptions explaining the LV95 vs WGS84 duality. The description adds the critical clarification that for wgs84_to_lv95, easting=longitude and northing=latitude, which complements the schema. Since the schema itself is rich, the description's incremental value is moderate — a 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?

Specific verb+resource: 'Convert coordinates between WGS84 (lon/lat) and LV95'. Clearly distinguishes from siblings — none of the sibling tools (geo_search_layers, geo_height, geo_identify, etc.) deal with coordinate conversion, so this tool's purpose 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 explains the direction semantics ('for wgs84_to_lv95, easting=longitude and northing=latitude') and names the data source, providing clear operational context. However, it doesn't explicitly state when to use this vs an alternative or mention exclusions/limitations (e.g., no elevation handling — which is covered by sibling geo_height). Usage context is implied but not 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds the LV95 coordinate system constraint and the 'profile service' nature, which is useful context beyond annotations. However, it doesn't disclose behaviors like the number of sample points (covered by schema), service limits, or what happens with out-of-Switzerland coordinates.

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?

Single sentence, front-loaded with purpose. It's efficient and wastes no words, though it could arguably include more substance in the same space (e.g., mentioning nb_points or output format). For a one-line description, it's acceptable but minimal.

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?

An output schema exists, so return-value documentation burden is reduced. The description explains the coordinate system (LV95) and the service (geo.admin.ch). However, with 0% schema description coverage and no parameter detail in the description, the agent must rely entirely on field-level hints in the schema for the 4 coordinates plus nb_points. The description is adequate but not rich for a tool with this many semantic parameters.

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%. The description does not compensate by explaining any parameters. The 'params' wrapper object contains 4 required coordinates plus a default nb_points, but the tool description provides zero parameter-level detail beyond what the schema states. The description only mentions 'two LV95 points' generically without explaining easter/northing structure or the nb_points control.

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 'Elevation profile along a line between two LV95 points' with a specific verb (profile) and resource (elevation along a line). It clearly names the geo.admin.ch profile service as the backend. However, it doesn't explicitly distinguish from sibling tools like geo_height, though the purpose is distinct enough that a capable agent would infer the difference.

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 context (elevation profile for line segments between two LV95 coordinates) but provides no explicit 'when to use' or 'when not to use' guidance. It doesn't mention alternatives such as geo_height for single-point elevation queries, nor does it state when choosing between these tools would be appropriate.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, covering the safety profile. The description adds meaningful context: the data source (geo.admin.ch MapServer find), which helps set expectations about the underlying service. It doesn't describe pagination or error behaviors, but for a read-only query tool with solid annotations, this adds appropriate value beyond the structured fields.

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, tightly focused. The first sentence states the purpose; the second provides the key prerequisite (geo_layer_info) and source. Zero filler or redundancy — 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?

Has an output schema, so return-value documentation isn't needed in the description. The 1-parameter nested input with full schema documentation and the geo_layer_info prerequisite cover the essential usage context. It doesn't mention query syntax specifics (wildcards, exact-match behavior), but for a straightforward find tool with an output schema and good annotations, this is reasonably 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 0%, meaning the description must compensate. It mentions 'by attribute value' and names the data source, but all three parameters (search_field, search_text, limit) are fully described in the schema with examples and defaults. The schema carries the heavy lifting for parameter explanation; the description offers only marginal framing value.

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?

Clear verb+resource+mechanism: 'Find features on a layer by attribute value' with an explicit backend source (geo.admin.ch MapServer find). The description distinguishes this from siblings like geo_identify (point-based) and geo_zoning_at (location-based) by stating it searches by attribute value. The purpose is fully specific.

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 advises using geo_layer_info first to see queryable fields, providing a clear prerequisite for usage. It identifies the data source context. However, it doesn't explicitly state when NOT to use this tool or name specific alternative tools for exclusion, though the prerequisite guidance is genuinely helpful context.

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, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds the LV95 coordinate system requirement and the swissALTI3D data source, which is useful context beyond annotations. Specifying 'm a.s.l.' clarifies the height datum format.

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 concise sentence, zero waste. Front-loads the purpose well. Though it's arguably too terse given zero parameter coverage and a single parameter that is itself a nested object.

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 output schema exists (though not shown in full here), annotations cover safety profile, and the core behavior (single point height query) is straightforward. For a simple point-lookup tool this is reasonably complete. Main gap is not explaining that the 'params' argument is the point object, but the schema handles that.

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

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

Schema description coverage is 0%, and the description says nothing about the parameters directly. The schema itself has well-documented params (easting/northing with examples), so the schema does heavy lifting here. But since coverage is 0%, the description doesn't compensate at all - it never mentions that the single 'params' object requires easting and northing coordinates.

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?

Clear verb+resource: returns terrain height at a point in LV95 coordinate system, sourced from swissALTI3D service. It's specific and unambiguous. However, it doesn't explicitly distinguish from sibling geo_elevation_profile (which is profile, not single point) or geo_identify, though the 'at an LV95 point' scoping is fairly 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 use case: get a single height value at a coordinate point. It is close to sibling geo_elevation_profile but doesn't explicitly state when to use this vs the profile tool. No when-not-to-use or explicit alternatives given.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is well covered. The description adds useful context about soft-miss vs error semantics, which is genuinely valuable beyond annotations. However, it doesn't disclose behavior around tolerance/limit effects, result count caps, or coordinate system assumptions beyond what annotations and schema 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 compact (three sentences) and front-loaded with the essential question it answers. Every sentence adds value: the purpose, the soft-miss interpretation, and the data source. No wasted words or redundancy with schema/annotations.

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

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

The tool has an output schema present, so return format doesn't need explanation. The soft-miss behavior and LV95 framing are well covered, which addresses the main interpretational risks. However, given the nested params structure with 5 fields at 0% schema coverage, the description could note which fields are required (layer, easting, northing) and which are optional (limit, tolerance), though the schema's required list partially 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 0%, so there are no inline parameter descriptions to compensate. However, the tool has zero parameters at the top level (the actual params live in a nested 'params' object) — the nested IdentifyInput has 5 fields but the description doesn't elaborate on them. The description does provide partial semantic context (LV95 coordinate system) in the main text. With an output schema present and the LV95 framing, a baseline 3 is appropriate, though more per-parameter detail would help.

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 purpose: identifies feature attributes at an LV95 point on a given layer via geo.admin.ch MapServer. It uses specific verb+resource and distinguishes from siblings (identify vs search/height/layer discovery). The first line frames the question 'What is at this LV95 point on a given layer?' which 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 gives helpful usage nuance: notes that an empty result is a soft miss (nothing at that location), not an error, which guides interpretation. It also names the data source and implicitly distinguishes from geo_search_layers (which finds layer ids) and geo_find. However, it doesn't explicitly state when NOT to use this tool versus the sibling identify-like tools (geo_municipality_at, geo_zoning_at), missing explicit 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns plain-text legend and queryable fields, which is some additional context, though it doesn't detail the exact output structure or any data source nuances beyond naming the MapServer.

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 with the primary purpose in the first sentence. It's a few short sentences with no filler, effectively conveying the tool's function and connection to a sibling in minimal space.

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 single parameter, readOnly/openWorld annotations, and an output schema present, the description covers the essential need. It explains the return (fields and legend), connects to geo_find usage, and names the data source. The output schema handles return-value details, so the description doesn't need to.

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?

There is a single parameter with 0% schema description coverage, so the description carries the burden. It does explain that 'layer' is a layer id (with example in the schema 'ch.are.bauzonen'), and the description clarifies the fields come from geo.admin.ch MapServer. The description adds context that the layer's fields are queryable for geo_find, but doesn't elaborate on the legend format.

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+resource ('Queryable fields and legend (plain text) for a layer') and ties it to the geo.admin.ch MapServer source. It distinguishes itself by mentioning the fields can be used with geo_find, but doesn't explicitly contrast against siblings like geo_search_layers.

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 explains the tool reveals fields that can be passed to geo_find as search_field, which gives clear usage context and connects it to a sibling tool. However, it doesn't explicitly state when NOT to use this tool or list alternative scenarios.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds value by noting the data source (swissBOUNDARIES3D) and the BFS-number bridging usage. It does not describe edge cases like points outside Switzerland or at boundaries, which would be useful, but annotations carry the main burden here.

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 sentences with zero waste. The first sentence states the core action and output, the second provides integration/bridging context, and the third cites the data source. 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?

The tool is simple (one point input, well-documented nested schema, read-only), and the description covers the core purpose plus integration value. An output schema exists, so return-format explanation is unnecessary. Could note boundary/outside-Switzerland behavior for completeness, but for a straightforward geospatial lookup with annotations and schema coverage, this is adequate.

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% for the top-level params field, but the nested PointInput schema itself has descriptions for easting and northing with example values (2683531, 1247914). The description clarifies the coordinate system (LV95) and confirms both parameters are used for the point lookup. Since the nested schema already documents the parameters well, the description adds marginal value beyond reinforcing the LV95 context.

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 exactly what the tool does: returns 'Municipality, BFS number and canton' for a given LV95 point, sourced from swissBOUNDARIES3D. It uses a specific verb+resource structure and clearly distinguishes this from siblings like geo_height (elevation) and geo_zoning_at (zoning) by specifying the geographic lookup behavior.

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 specifies this is a point-based lookup (LV95/CH1903+ coordinates), and the mention of the BFS number bridging to register/statistics servers gives useful cross-tool context. While it doesn't explicitly name alternatives or exclusions, the LV95 coordinate requirement implicitly distinguishes it from coordinate-conversion siblings. No explicit 'when-not-to-use' is given, but the geographic lookup purpose is unambiguous.

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, destructiveHint=false, and openWorldHint=true, covering the safety and scope profile. The description adds the ~700-layer catalogue scope and the data source (geo.admin.ch SearchServer), which is useful context. However, it doesn't describe pagination, ordering, or whether results are sorted by relevance. With solid annotations in place, a 3 is appropriate.

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 paragraphs, well front-loaded with the core purpose in the first sentence. The second paragraph adds one valuable line about its pipeline role and one about the data source. Zero waste, 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 discovery/search tool with one required param and a default limit, the description is largely complete. It covers purpose, pipeline role, and data source. It could slightly improve by noting result format details or relevance sorting, but the presence of an output schema relieves the description of explaining return value structure. Minor gap in usage nuance keeps it from a 5.

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, but the two parameters (query, limit) are already well-described in the schema itself (query: 'Keyword(s) to search the layer catalogue'; limit: 'Maximum layers to return', with min/max bounds). The description adds the catalogue scale context but no additional parameter semantics beyond the schema. Baseline 3 is appropriate given the schema carries the load.

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 the verb+resource: 'Keyword-search the ~700-layer federal geodata catalogue'. It explicitly frames itself as 'the discovery entry point' returning layer ids for downstream tools, distinguishing it from geo_identify, geo_find, and geo_layer_info by naming them as consumers of its output. This is specific and actionable.

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 positions this as the discovery entry point and names the exact downstream tools (geo_identify, geo_find, geo_layer_info) that accept its returned ids, giving clear when-to-use guidance. It explains its role in the pipeline relative to the sibling tools, which all appear to operate on already-identified layers.

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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, destructiveHint=false, which the description does not contradict. The description adds the data source note (ch.are.bauzonen) and clarifies it returns the 'main-use' zone type. However, it doesn't explain behavior for points outside zoning-covered areas given openWorldHint=true, or detail what happens when no zone exists at the point. With readOnlyHint already declared, some credit for adding data-source context; score 3 is fair.

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 paragraphs, one introductory sentence and one return-value sentence. Zero filler or repetition. Could possibly add usage guidance without becoming verbose, but current size is appropriately economical.

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 readOnly annotations set, the tool is reasonably complete for a point-query tool, but openWorldHint=true signals incomplete data that the description could address. It doesn't state what happens at points with no zoning, which is a meaningful gap for a location-based query where unsupported areas likely exist.

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% for the nested params, so the description carries the burden. The description mentions LV95 coordinates in its opening phrase, but the schema already documents easting/northing fields with examples. The description does not explain coordinate formats or conventions beyond what the schema states, and does not clarify units or precision expectations for LV95 points.

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

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

The description states it returns 'the harmonised main-use zone type' at an LV95 point, with a specific verb+resource ('building zone(s) at a point'). It names the data source (ch.are.bauzonen, ARE) which adds specificity. It could better distinguish from siblings like geo_municipality_at, but the phrase 'harmonised building zone type' is reasonably 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 provides no guidance on when to use this tool versus alternatives like geo_identify or geo_municipality_at. It doesn't mention what the openWorldHint implies (data may be incomplete outside certain areas), nor does it state that it requires LV95 coordinates as a prerequisite (which is instead learned from the schema). No exclusions or conditions are given.

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