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

Die Annotationen liefern bereits readOnlyHint, idempotentHint und destructiveHint=false. Die Beschreibung ergänzt darüber hinaus das kritische Verhalten: die Achsenreihenfolge je Richtung und dass vertauschte Achsen abgewiesen statt stillschweigend umgerechnet werden. Das geht deutlich über die Annotationen hinaus.

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?

Die Beschreibung ist kurz, in use_case und important_notes strukturiert und enthält keine überflüssigen Wiederholungen. Jeder der drei Abschnitte liefert direkt verwertbare 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?

Angesichts eines vorhandenen Output-Schemas und der ausführlichen Annotationen deckt die Beschreibung alle relevanten Aspekte ab: Anwendungsfall, Richtung, Achsenfehler und Fehlerverhalten. Für einen koordinatenbasierten Umrechnungs-Tool ist sie damit vollständig.

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?

Obwohl das Tool-Schema laut Signal eine Beschreibungsabdeckung von 0% hat, enthält die Tool-Beschreibung die wichtigste Parameter-Semantik: easting/northing sind richtungsabhängig, und bei wgs84_to_lv95 ist easting der Längengrad und northing der Breitengrad. Die Enum-Werte und Einheiten bleiben dem Schema überlassen, aber der kritische Verwechslungsfall wird klar kompensiert.

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?

Die Beschreibung nennt das konkrete Verb 'umrechnen' und die Zielsysteme WGS84 und LV95, ergänzt durch den offiziellen Dienstnamen REFRAME. Damit ist der Zweck eindeutig und klar von den übrigen swisstopo-Tools abgegrenzt.

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?

Das use_case-Tag beschreibt explizit, wann die Umrechnung benötigt wird: um LV95-Koordinaten für andere Tools nach WGS84 zu bringen oder umgekehrt für den Katasterbezug. Es wird keine Alternative genannt, da auch unter den Geschwister-Tools kein direkter Koordinaten-Umrechner existiert; die Einsatzbedingung ist hinreichend klar.

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 readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: the requirement of at least 2 coordinate pairs, the default WGS84 coordinate system with option for LV95, and the deprecation note for the 'sr' parameter. These details help the agent understand constraints and edge cases beyond the 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 and well-structured: a one-sentence purpose followed by structured <use_case> and <important_notes> tags. Every element earns its place, with no redundancy or filler. The German text is clear and front-loaded with the primary action.

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 existing annotations, the description covers the essential aspects: purpose, use case, prerequisites, and coordinate system handling. It doesn't elaborate on return values, but that's sufficiently handled by the output schema. The tool is relatively simple, and this description is adequate without major 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 input schema fully documents all parameters with descriptions (coordinates format, defaults, ranges). The description's important_notes largely reiterate schema information but add the '≥2 Koordinatenpaare' constraint and the deprecation of 'sr'. Since schema description coverage is effectively high, a baseline of 3 is appropriate; the description provides marginal but non-essential additions.

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 starts with 'Berechnet ein Höhenprofil entlang einer Linie aus mehreren Koordinatenpaaren', which is a specific verb (Berechnet) + resource (Höhenprofil) + scope (entlang einer Linie). It clearly distinguishes from the sibling tool swisstopo_get_height (which likely handles single points) and other location-based tools. The use_case tag reinforces the intended domain.

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 <use_case> tag explicitly states when to use the tool (e.g., hiking/school-route analyses), providing clear contextual guidance. It doesn't explicitly name alternatives or exclusion conditions, but the purpose and use case are specific enough. The <important_notes> also give prerequisites (≥2 coordinate pairs), which helps the agent decide if the tool is 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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds valuable behavioral details: lists are complete ('interne Pagination, nicht auf 10 Einträge gekürzt'), canton abbreviation→key resolution happens server-side to avoid silent empty results, and the BFS number is the official join key. These details help the agent anticipate behavior and pitfalls.

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 well-structured with a concise opening sentence, a <use_case> block, and an <important_notes> block. Each sentence serves a purpose—covering modes, examples, and caveats—without fluff. The use of tags helps an agent scan key information efficiently.

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 complexity (four modes, exact-one-parameter constraint) and the existence of an output schema (which covers return values), the description is complete. It covers all parameter semantics, a usage example, and important edge cases like canton abbreviation resolution and full pagination. 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?

Schema description coverage is effectively 0% at the top level (only 'params' wrapper has no description), so the prose must compensate. The description thoroughly explains each of the four modes and parameters: name (forward), bfs_number (reverse), canton (abbreviation or number), district (numeric). It also emphasizes that exactly one parameter must be given, which is critical for correct invocation.

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 opens with a specific verb and resource: 'Löst Gemeinden auf: Name→BFS-Nummer, BFS-Nummer→Name, oder alle Gemeinden eines Kantons/Bezirks.' This clearly defines the tool as a commune resolver, distinct from siblings like swisstopo_geocode or swisstopo_reverse_geocode. The four modes are enumerated, making the purpose unmistakable.

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

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

The description provides clear context on when to use the tool: 'Vier Modi (genau einen Parameter angeben)' followed by a concrete example ('Welche Gemeinden liegen im Bezirk Uster...'). It explains the input constraints and the exact modes. It does not explicitly exclude alternatives or name sibling tools, but the guidance is sufficient for an agent to decide when this tool is 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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the workflow context but does not disclose additional behavioral details like pagination or handling of multiple results. With annotations, 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?

The description is concise: one main sentence plus a structured use_case block. Every sentence serves a purpose, with no redundant 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 rich schema and annotations, the description is complete enough for an agent to understand when and how to use the tool. The use_case ties it into a larger workflow, and return values are covered by the output schema. Minor gap: it doesn't explicitly explain the optional filters, but these are well-documented in the schema.

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 description does not mention any parameters, but the input schema provides detailed descriptions for each property (search_text, sr, limit, origins). Since the schema covers parameter semantics, the description adds little beyond it, and the baseline is 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?

The description clearly states a specific verb and resource: 'Wandelt eine Adresse, einen Ortsnamen oder eine PLZ in Koordinaten um (Geocoding).' It distinguishes this from reverse geocoding and other sibling tools by naming the conversion direction and the downstream tool usage.

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 use_case explicitly describes when to use this tool ('Startpunkt für ortsbezogene Abfragen') and which downstream tools it feeds into, providing clear context. However, it does not explicitly mention when not to use it or directly compare with reverse_geocode, so it's not a full 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds workflow context but no additional behavioral details such as authentication, rate limits, or output quirks. It does not contradict 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 extremely concise, with two sentences: the first states the core function, and the second gives the workflow context. Information is front-loaded and 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 parameter), has an output schema, and annotations cover safety. The description provides workflow context via the use_case, but could be more explicit about how to derive collection_id from search results. Overall, it is sufficient for selection and invocation.

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

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

The description does not mention the collection_id parameter at all. Schema description coverage is 0%, meaning the description fails to compensate. The schema provides an example but lacks detailed semantics on how to obtain a valid collection ID.

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: retrieving detailed information and download links for a STAC collection. The use_case further specifies that it is the second step after swisstopo_search_geodata, which distinguishes it from sibling search 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 use_case explicitly tells when to use this tool: after swisstopo_search_geodata, to obtain assets/download URLs. It does not list when-not-to-use or explicit alternatives, but the sequential workflow provides clear 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, idempotentHint, and destructiveHint=false. The description adds useful context about the need for a supported canton, which could cause errors otherwise. It doesn't contradict annotations and provides the key behavioral constraint beyond what annotations state.

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 extremely concise: one main sentence, a use_case block, and a short important note. It's well-structured with tagged sections, front-loads the core purpose, and every sentence earns its place 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 simple lookup tool with strong annotations and an output schema, the description covers the primary use case, an alternative, and an important prerequisite. It misses explicitly stating the coordinate pair requirement, but the schema handles that detail. Overall, it's adequately complete for an agent to invoke correctly.

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

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

The tool description does not explain parameter semantics; it only says 'aus Koordinaten' (from coordinates). The schema does describe each parameter, but with schema_description_coverage at 0%, the description provides almost no value beyond the schema. It gives no hints about the need to supply either lat/lon or easting/northing, nor the coordinate systems.

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 the specific verb 'ermittelt' (determines) and clearly identifies the resource (EGRID property ID) and the input (coordinates for a specific canton). It also distinguishes itself from siblings by explicitly directing users to swisstopo_oereb_at for restrictions, resolving the EGRID internally.

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 use_case section states when to use the tool ('wenn die ID selbst gebraucht wird') and explicitly points to an alternative for restriction lookups (swisstopo_oereb_at). The important_notes adds a prerequisite (supported canton), giving clear usage 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 deklarieren readOnly, idempotent, nicht destruktiv. Die Beschreibung ergänzt die wichtige Einschränkung, dass entweder lat/lon ODER easting/northing angegeben werden darf ('nicht beides') – ein Verhaltenshinweis, der über die Annotationen hinausgeht.

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?

Die Beschreibung ist mit zwei knappen Absätzen und Tags strukturiert und enthält keine unnötigen Informationen.

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?

Mit Schema (Parameterdetails), Annotations (Safety) und Output-Schema ist die Beschreibung angemessen: Sie erklärt Use Case, Koordinatensysteme und die wichtigste Einschränkung. Sie muss nicht jedes Schema-Detail wiederholen.

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?

Das Schema dokumentiert alle Parameter mit Beschreibungen (z.B. sr als veraltet, lat/lon-Grenzen). Die Beschreibung fügt den gegenseitigen Ausschluss der Koordinatenpaare hinzu, was die Schema-Einzelbeschreibungen nicht explizit sagen.

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?

Die Beschreibung beginnt mit 'Gibt die Höhe über Meer (m ü. M.) an einer Koordinate zurück' – ein spezifisches Verb und Ressource. Der use_case grenzt explizit von swisstopo_elevation_profile ab (Punkt vs. Linie).

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?

Im use_case steht 'Punkthöhe für eine Adresse/Koordinate; für Linien siehe swisstopo_elevation_profile.' Das gibt eine klare Entscheidungsregel und nennt die Alternative.

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 convey read-only, idempotent, and non-destructive behavior. The description adds the constraint that a supported canton is required, which is useful but not a major behavioral disclosure. It does not mention response format or error handling, but the output schema covers the return structure.

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, with the core purpose in the first sentence and supplementary information in clearly labeled XML tags (<use_case>, <important_notes>). No wasted words; the structure aids parsing and scannability.

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 provides essential usage context: purpose, when to use vs. an alternative, and a key prerequisite. Combined with the annotations and a rich input schema, it is nearly complete. However, it does not mention any edge cases (e.g., unsupported canton behavior) or response size limits, so a slight deduction applies.

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

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

The tool description does not discuss parameters, but the input schema independently provides rich descriptions for all four fields (egrid, canton, lang, topics) with examples and constraints. The description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Ruft öffentlich-rechtliche Eigentumsbeschränkungen (ÖREB) für ein Grundstück (EGRID) ab.' This is a specific verb+resource combination and distinguishes from siblings by noting that coordinate-based lookups should use swisstopo_oereb_at.

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 use_case explicitly defines when to use this tool ('ÖREB-Auszug zu einem bereits bekannten EGRID') and directs users starting from a coordinate to an alternative sibling tool. It also adds a prerequisite ('Erfordert einen unterstützten Kanton'), providing clear decision 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, idempotentHint=true, and destructiveHint=false. The description adds beyond these by framing the tool as a 'Discovery-Tool' and explaining that it outputs layer IDs accepted by query_geodata, with emphasis on free availability without contract. This provides useful behavioral context without contradicting the 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 extremely concise: two sentences and a use_case tag. The first line immediately states the core purpose, and the use_case adds practical context without any fluff. 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 description covers the tool's purpose, usage timing, and a practical example. Since an output schema exists, the description need not explain return values. It also mentions the free-availability constraint. Some details like response format or filtering semantics are not described, but they are either in the schema or not essential for a simple discovery 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 description coverage is 0% (the top-level 'params' property has no description), and the description does not explain the parameters object. It only gives a single example (canton='ZH'). The inner schema does describe each field, but the description fails to compensate for the lack of top-level param documentation, so the agent gets minimal guidance on how to construct the input.

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: 'listet die Layer-Kennungen, die swisstopo_query_geodata akzeptiert' (lists layer identifiers accepted by swisstopo_query_geodata). It uses a specific verb (listet) and resource (Layer-Kennungen), and explicitly distinguishes itself from the sibling query tool by being a discovery step.

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

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

The description explicitly says 'Erster Schritt vor swisstopo_query_geodata' (first step before query_geodata), giving clear when-to-use context. It also provides a concrete use case and an example of specifying a canton. However, it does not mention when not to use or name alternatives, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: unknown postal codes return an empty list with an explanatory hint, and the data source is OpenPLZ (not swisstopo geodata). This enriches transparency without contradicting 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 compact and well-structured with XML-like tags (use_case, important_notes). Each sentence adds distinct value: the main statement, an example use case, and essential notes about the BFS key and unknown-PLZ behavior. No 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?

For a simple single-parameter lookup tool with an output schema present, the description covers all essential aspects: what it does, the use case, key output (BFS number), data source caveat, and behavior for unknown inputs. No gaps are evident.

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

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

The schema provides a clear description for the single parameter ('Schweizer Postleitzahl (4-stellig, z.B. 8001)'). The tool description only adds an example ('8001') in the use_case, contributing minimal additional meaning beyond the schema. Given the schema coverage is 0% from the description side, this is a baseline score.

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 ('Löst auf') and resource ('Schweizer PLZ') to clearly state the output ('Ort, Gemeinde, Bezirk und Kanton'). The use_case further clarifies by giving a direct example question and mentioning the BFS commune number, which distinguishes it from sibling tools like geocode or reverse_geocode.

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 important_notes section clarifies the data source (OpenPLZ) and the primary use case (joining to BFS statistics), which implies when to use this tool. However, it does not explicitly name alternative tools or state when not to use it, so it falls slightly short of full explicit 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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond those annotations: exactly one operation per call is required, and fields from a different operation are rejected with an error listing allowed fields. This exposes strictness that the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a crisp opening sentence followed by clearly delineated <use_case> and <important_notes> sections. Every sentence carries unique information—there is no filler, repetition, or verbosity. The structure makes the content easy to scan and consume for an AI agent.

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 multi-operation tool with a nested schema and output schema present, the description covers the full decision space: what the tool does, when to use it vs alternatives, how operations chain together, and a critical behavioral constraint. The presence of an output schema means return-value documentation is not necessary, and the description delivers everything else needed for correct 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?

Although the context signal indicates 0% schema description coverage, the tool description compensates by explaining the operational flow and how operations relate to parameters (e.g., 'features_at_point' for spatial queries, 'features_by_attribute' for attribute-based). The schema itself also contains detailed per-parameter descriptions inside the nested MapQueryInput object, so the description adds semantic sequencing rather than repeating field-level details. The use_case block meaningfully links parameter categories to operations.

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 opens with 'Fragt den nationalen Swisstopo-Kartenkatalog ab (500+ Layer): Layer finden, Felder ansehen, Features abfragen', which uses a specific verb and resource and enumerates the tool's core actions. It also distinguishes this tool from siblings by explicitly naming alternative tools for zoning/municipality and for intercantonal/cantonal sources, making its scope 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 <use_case> block lays out a clear chain of operations (search_layers → layer_info → features_at_point/features_by_attribute → feature_by_id) and the <important_notes> give explicit when-not-to-use guidance, pointing to swisstopo_zoning_at, swisstopo_municipality_at, swisstopo_list_available_layers, and swisstopo_search_geodata for alternative needs. This is exemplary usage direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it produces a shareable link and does not perform data retrieval, but it doesn't disclose details about URL format, coordinate limitations, or error behavior. The added context is helpful but minimal beyond the safety profile.

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 extremely concise—two short sentences. The first sentence states the core action, and the second clarifies the use case. Every word earns its place with no redundancy.

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

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

The description clearly explains the tool's purpose and use case. While it doesn't detail URL construction or parameter constraints, the schema and output schema fill in those details. For a simple URL-generation tool, the context is sufficiently 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% for the top-level parameter, and the tool description does not compensate by explaining the required 'params' object or its fields. The nested schema has descriptions, but the description text provides no guidance on parameters, leaving a gap for the agent.

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: 'Generiert eine teilbare map.geo.admin.ch-URL zum Öffnen im Browser.' This is a specific verb (generates) with a specific resource (map.geo.admin.ch URL), and it distinctly contrasts with sibling tools that perform data retrieval or geocoding.

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 use_case block clarifies when to use the tool: 'Einen Kartenausschnitt mit optionalen Layern als Link bereitstellen (kein Datenabruf).' This gives clear context and explicitly states the tool does NOT retrieve data, helping distinguish it from siblings.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds key behavioral details: it returns the current state from a layer with per-historical-year features, and that results are empty on boundaries or outside Switzerland. This is meaningful context that the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-sentence summary, a use_case block, and important_notes. Every sentence provides distinct value—function, context, and edge-case behavior—with no redundancy or filler.

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

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

Given the output schema exists and the schema documents parameters, the description is nearly complete. It covers the primary use case (BFS join key), the current-state behavior, and empty-result conditions. It does not explicitly state that lat/lon and easting/northing are mutually exclusive coordinate systems, but the schema hints at this, so a small gap remains.

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 description does not discuss parameters, and schema_description_coverage is 0%. However, the input schema itself provides thorough descriptions for lat/lon/easting/northing, including coordinate system hints and examples, so the schema carries the semantic burden. The description adds no additional parameter meaning, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns 'Gemeinde, BFS-Nummer und Kanton an einer Koordinate' (municipality, BFS number, and canton at a coordinate), specifying the resource and output. This distinguishes it from siblings like reverse_geocode or geocode, which focus on addresses or broader features.

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 use_case explicitly describes when to use: to obtain the official BFS municipality number as a join key for other MCPs. It also warns in important_notes that results are empty on borders or outside Switzerland, giving practical guidance. It does not name alternative tools, but the context is clear enough for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. The description adds valuable behavioral context beyond these: it is a single call ('ein Aufruf'), it resolves the EGRID internally, and it is restricted to cantons with a connected ÖREB service. It also notes coordinate formats. However, it does not clarify behavior when both coordinate systems are provided or what happens for unsupported cantons.

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 well-structured with distinct use_case and important_notes blocks. The main sentence is front-loaded and direct. Each sentence provides actionable information, such as the EGRID resolution, the alternative tool, and coordinate format requirements, without any filler.

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

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

The tool is relatively complex with multiple parameters, coordinate systems, and an output schema. The description covers the primary use case, internal EGRID resolution, cantonal availability, and coordinate formats. The output schema is present, so return structure need not be described. However, it omits topics and language parameters, which are only in the schema, and does not address edge cases like no coordinates provided or conflicting coordinate systems.

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 description provides essentially no parameter documentation (0% coverage), but the input schema itself has detailed descriptions for each field (e.g., lat: 'Breitengrad (WGS84). Zusammen mit lon angeben.'). The description's note about lat/lon or easting/northing and the cantonal restriction adds a bit beyond the schema, especially the requirement that the canton must have an ÖREB service. Still, the description does not compensate for the low coverage; it relies on 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 clearly states the tool's function: 'Gibt die ÖREB-Eigentumsbeschränkungen an einer Koordinate zurück' (returns ÖREB property restrictions at a coordinate), with a specific verb, resource, and scope. It also distinguishes from sibling tool swisstopo_get_egrid by explaining that this tool resolves EGRID internally and is the normal way, while get_egrid is only for needing the parcel ID itself.

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 explicit usage context via the use_case block: '«Welche Beschränkungen gelten auf diesem Grundstück?»' and states 'Das ist der normale Weg; swisstopo_get_egrid braucht es nur, wer die Parzellen-ID selbst benötigt.' This gives clear when-to-use and when-not-to-use guidance, names an alternative, and also specifies a precondition: 'Nur für Kantone mit angebundenem ÖREB-Dienst'.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds behavioral context about the façade nature, the requirement to pass exactly one location, and layer-specific parameter requirements (geodienste require bbox/point). 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?

The description is concise, with a clear primary sentence followed by structured use_case and important_notes tags. Every sentence adds value, and the format is front-loaded and easy to parse.

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

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

Given the tool's complexity (7 parameters, multiple layer types) and the presence of a detailed input schema and output schema, the description covers the core usage rules (exactly one location, layer-source mapping, geodienste requirements). It does not explicitly state which location types apply to each layer, but the schema covers parameter constraints, making this acceptable.

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 does mention point, bbox, commune, and radius_m, and explains that geodienste layers require bbox or point, adding meaning beyond the schema. However, it does not systematically describe the parameters or their mutual exclusivity; the schema itself handles most 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 clearly identifies the tool as a unified facade over multiple geodata sources based on a layer identifier, and enumerates the specific source types ('strassenverzeichnis', 'oereb-verfuegbarkeit', 'geodienste'). This distinguishes it from sibling tools that handle narrower queries.

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 explicit constraints: exactly one location parameter (point, bbox, or commune), and notes that geodienste layers require bbox or point with radius_m. It also directs users to swisstopo_list_available_layers for valid layer IDs. It lacks explicit 'when not to use' alternatives, but provides clear 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?

Die Anmerkungen lesen sich als readOnlyHint, openWorldHint, idempotentHint und destructiveHint false. Die Beschreibung fügt hinzu, dass die Quelle OpenStreetMap (ODbL) ist und nicht swisstopo, und dass Overpass Rate-Limits/Timeouts hat, weshalb ein kleinerer Radius bevorzugt werden sollte. Dies geht über die Annotationen hinaus und schafft Verhaltens-Transparenz, inklusive möglicher Fehlermeldungen.

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?

Die Beschreibung ist kompakt: ein einleitender Satz, gefolgt von klar strukturierten Abschnitten use_case und important_notes. Jede Zeile liefert einen Mehrwert, ohne überflüssige Wiederholungen. Die Struktur mit XML-Tags erleichtert das Parsing.

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?

Das Tool hat 4 Parameter und eine Ausgabe-Schema, daher muss die Beschreibung nur den Kontext und die Besonderheiten abdecken. Sie erklärt die externe Datenquelle, den Anwendungsfall, die Einschränkungen von Overpass und das Fehlerverhalten. Das ist für ein Such-Werkzeug eine vollständige Beschreibung.

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?

Obwohl das Schema für alle vier Parameter Beschreibungen enthält (area, limit, radius_m, feature_type), liefert die Tool-Beschreibung keine zusätzliche syntaktische Information. Sie erwähnt jedoch den Suchradius und die POI-Kategorien im Fließtext, was den Zweck der Parameter kontextualisiert. Das Schema trägt die Hauptlast, daher ist 3 angemessen.

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?

Die Beschreibung nennt das Verb 'Findet', die Ressource 'OpenStreetMap-POIs' und den Kontext 'im Umkreis'. Beispiele wie Schulen, Spielplätze und Apotheken machen den Zweck konkret. Sie grenzt sich von den amtlichen swisstopo-Daten ab und ist klar von den Geschwister-Tools unterscheidbar.

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?

Das use_case-Feld definiert genau, wann das Tool eingesetzt wird: für die Beantwortung von Umkreisfragen nach POIs. important_notes gibt zusätzlich Hinweise zu Overpass-Limits und Fehlerverhalten, was eine informierte Nutzung ermöglicht. Alternativen werden zwar nicht explizit genannt, aber der Zusatz 'Ergänzt die amtlichen swisstopo-Daten' impliziert die Abgrenzung.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds context about WGS84 input and that it finds the nearest address, but does not disclose e.g., return format or geographic bounds. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences plus a use_case tag, front-loaded with the main purpose. Every word earns its place with no filler or repetition.

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 relatively simple and has an output schema plus safety annotations. However, the description omits important context like Swiss bounds, configurable coordinate systems (sr), and result limit (limit), relying on the schema to convey these. For a tool with nested parameters, this is adequate but not 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?

The context signal reports 0% schema description coverage for the top-level params object, meaning the description must compensate for parameter semantics. It only mentions 'WGS84-Koordinaten', which partially explains lat/lon, but does not describe 'sr', 'limit', or the nested structure. The nested schema has descriptions, but the tool description itself adds minimal parameter 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?

The description specifies a clear verb+resource: 'Findet die nächstgelegene Adresse zu gegebenen WGS84-Koordinaten (Reverse Geocoding).' This precisely identifies reverse geocoding and differentiates it from sibling forward geocoding tools like swisstopo_geocode. The use case tag further clarifies the intended scenario.

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 use_case ('Koordinaten aus Karte oder GPS in eine lesbare Adresse auflösen') explicitly states when to use the tool. It implies the distinction from forward geocoding but does not name alternative tools or provide explicit exclusions, so it falls short of a top score.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds behavioral details: results are paginated, max 50 per request, total hit count is shown, and data source is OpenPLZ (BFS/swisstopo OGD). It also mentions it returns Gemeinde and BFS number if available, which is useful context beyond 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 compact and well-structured, using clear tags for use_case and important_notes. Each sentence delivers distinct value: purpose, output, pagination, data source, and alternative tool. No redundant or filler content.

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 strong annotations, the description covers all necessary selection and invocation context: clear use case, pagination behavior, data source, and when to prefer a sibling tool. It fully equips an agent to decide and call the tool correctly.

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

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

The input schema already provides descriptions for both 'query' and 'limit', including patterns and constraints. The description adds only minor extra context (e.g., 'freien Suchbegriff', pagination limit) that largely mirrors the schema. With schema coverage at 100% for parameter meaning, baseline 3 is appropriate.

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

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

The description clearly states it is a full-text search over Swiss streets and localities ('Volltextsuche über Schweizer Strassen und Ortschaften') and specifies the output includes municipality and BFS number. It also distinguishes itself from sibling swisstopo_lookup_postal_code by noting that tool is more precise for exact PLZ-to-municipality resolution.

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 provides an alternative: 'Für die exakte PLZ→Gemeinde-Auflösung ist swisstopo_lookup_postal_code präziser.' It also states pagination behavior (max 50 per query) and that total hits are returned, giving concrete usage 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 the operation as read-only, idempotent, and non-destructive. The description adds behavioral context by specifying that the result is collections/metadata, not direct data, and that download links require a complementary tool. This goes beyond the annotations and clarifies the tool's role in a workflow.

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 extremely compact, with a one-sentence main purpose and two clearly labeled sections (use_case and important_notes). Every sentence contributes meaningful guidance without unnecessary detail. The structure front-loads the core function and separates practical usage notes.

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 search tool, the description is largely complete: it states the resource, the output type, and directs to the sibling tool for downloads. It does not explain the full return structure or edge cases, but an output schema exists and the annotations cover safety, so the missing details are not critical.

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 context signal indicates 0% schema description coverage, meaning the description does not explain any parameter semantics. Although the schema itself contains descriptions for query and limit, the description offers no added guidance; it merely repeats query examples from the schema. The limit parameter is entirely unmentioned in the description, failing to compensate for the low coverage.

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 the specific verb 'Durchsucht' (searches) with a clear resource 'STAC-Katalog' and object 'herunterladbaren Geodaten'. It also lists concrete data types (Orthophotos, Höhenmodelle, 3D-Gebäude, historische Karten), distinguishing it from sibling tools like swisstopo_get_collection.

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 important_notes explicitly state that the tool returns collections/metadata and that download links are obtained via swisstopo_get_collection, providing a clear alternative. The use_case gives concrete examples of when to use the tool, making the selection rationale explicit.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context by explaining the ARE layer is a non-binding synthesis and that the legal disclaimers appear in every result, which is beyond the annotation set. No contradictions found.

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 efficiently structured with a leading one-sentence summary followed by tagged use_case and important_notes sections. It avoids redundancies and front-loads the core purpose, though the XML-like tags add some bulk.

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 point-lookup tool with an output schema, the description covers the essential context: purpose, coordinate formats, the legal caveat, and the relationship to sibling tools. It does not address edge cases like out-of-bounds coordinates or service limitations, but these are secondary given the schema's bounds and annotations.

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 description mentions 'lat/lon (WGS84) oder easting/northing (LV95)', which adds coordinate-system semantics beyond the schema's terse per-property descriptions. However, it does not clarify that the two coordinate pairs are mutually exclusive alternatives, nor does it explain the required 'params' object wrapper. The schema's own descriptions provide some context, so the description partially compensates for the low coverage.

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 begins with a clear verb+resource statement: 'Gibt die harmonisierte Bauzone an einer Koordinate zurück' (returns the harmonized building zone at a coordinate). It also distinguishes itself from sibling tool swisstopo_map_query by explicitly noting it avoids a prior layer-ID lookup, making its purpose 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 use_case section provides a direct query example ('Welche Bauzone gilt hier?') and explains when to use this tool instead of swisstopo_map_query. However, it does not explicitly state when not to use it beyond the legal caveat, nor compare to other 'at coordinate' siblings like swisstopo_municipality_at.

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