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

Annotations already cover read-only behavior. The description adds valuable context beyond that: the data must always be presented with a reference to the official bulletin and is not a risk assessment. It also discloses the output format, which is useful for downstream handling.

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

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

Three short sentences, all informative: purpose, identifier pattern, and an important usage caveat. No redundant wording, and the key function is front-loaded.

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 annotations covering the read-only nature, the description covers the essential operational and presentational requirements. It could be slightly stronger by mentioning when to use related tools, but for its complexity it is complete enough.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning for zona_id by specifying the 'IT-21-...' identifier convention for AINEVA zones, which helps agents construct valid inputs. It also ties the provider concept to the zone type, going slightly beyond the schema text.

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 function: returning the current avalanche bulletin for a zone, with format details (CAAML v6, EAWS profile). It is distinct from siblings like cerca_sentieri or meteo_quota, though it does not explicitly name the closely related zona_valanghe_da_coordinate as an alternative.

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 need for a zone ID is implied by 'per una zona' and the example identifier pattern, but there is no explicit guidance on when to choose this tool over siblings, such as using zona_valanghe_da_coordinate first to obtain the zone ID, or when not to use it.

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 read-only and open-world behavior. The description adds that the tool returns multiple candidates and tells the agent to check with the user if ambiguous, which is valuable decision-making context. It does not disclose what happens with no results or the coordinate format, but the output schema likely covers the return structure. 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 compact and front-loaded: the first sentence states the core conversion and scope; the second sentence gives usage guidance and ambiguity handling. No sentence is wasted, and the structure is easy to scan.

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 adequately covers what the tool does, when to use it, and how to handle ambiguous results. The output schema covers return values, and annotations handle safety and open-world aspects. A minor gap is the lack of explicit guidance for when to prefer overlapping siblings like cerca_ricoveri, but the default use case is clear enough for an agent to select this tool for place-name queries.

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

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

Schema coverage is 50%, so the description must compensate for the undocumented 'limite' parameter. The phrase 'Restituisce piu' candidati' hints at the effect of 'limite' but does not explicitly state that it caps the number of results. The description also does not directly add meaning to 'nome' beyond its role as a toponym, which is already implied by the schema's example.

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 (converts a toponym into coordinates) and enumerates the place types covered (rifugi, cime, valichi, paesi, frazioni). This differentiates it from sibling tools like cerca_sentieri (trails) and coordinate-based tools, while also being distinct from the more specific cerca_ricoveri.

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?

It provides a concrete trigger condition: use when the user names a place rather than providing coordinates. It also instructs asking for confirmation when results are ambiguous. However, it does not explicitly name sibling alternatives for overlapping categories (e.g., cerca_ricoveri for shelters), so it lacks 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 and openWorldHint=true, so the safety and incompleteness profile is covered. The description adds useful behavioral context by warning that bed counts and contact data depend on OSM mapping and may be missing, which helps an agent set expectations about result quality.

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

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

Two sentences carry the needed information with no filler. The main purpose is front-loaded, and the caveat is placed second where it does not obscure the core function.

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

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

With an output schema present, return values need not be described. The description sufficiently covers search scope, result subject matter, and data completeness caveats. It could mention the radius bounds explicitly, but the schema already provides default and maximum values, so nothing essential is missing.

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

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

The input schema only describes raggio_km (33% coverage), while lat and lon have no semantic descriptions. The description adds the concept of a radius from a point, which loosely explains lat/lon and raggio_km, but it does not specify coordinate format, CRS, or clarify that the radius is in kilometers beyond the schema's own minimal note.

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

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

The description names a specific verb ('Cerca') and resource ('rifugi gestiti, bivacchi e ripari') and adds the spatial scope ('entro un raggio da un punto'). This clearly distinguishes it from sibling tools like cerca_sentieri and cerca_localita.

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

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

The phrase 'entro un raggio da un punto' implies the use case of finding shelters near a location, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. Sibling tool names provide context but no direct exclusion 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 convey read-only and open-world behavior, so the description need not repeat that safety profile. It adds a useful data-provenance detail ('relation OSM route=hiking') and the numbered-trail scope, but it does not disclose return format, pagination, or data completeness caveats beyond what the annotations imply.

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 definition is three short sentences, front-loaded with the main action. The `ref` hint and the OSM source sentence add useful context rather than filler, and there is no redundant prose.

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 high schema coverage, output schema, and read-only/open-world annotations, an agent has enough to invoke the tool correctly. The only real gap is the mention of a geographic bounding-box mode that does not correspond to any input parameter, which creates slight ambiguity.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters. The description's only parameter-related addition is the `ref` example ('103'), which duplicates the schema's own description, so it adds little beyond the structured 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 identifies the operation ('Cerca sentieri escursionistici numerati') and the two location modes, so the verb and resource are specific. It implicitly distinguishes from siblings like 'cerca_ricoveri' and 'dettaglio_sentiero', but it never names an alternative and the 'per riquadro geografico' mode is not reflected in the input schema.

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?

It provides clear context: use this when searching for numbered hiking trails by area or point, and it tells the agent where to put the trail number (`ref`). However, it does not say when not to use it or recommend a sibling such as `dettaglio_sentiero` for trail details, so routing guidance is implied rather than 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 and openWorldHint, so the read-only nature is covered. The description adds no further behavioral context such as data freshness, error behavior, or external OSM dependency, beyond saying that complete data is returned.

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

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

The description is a single efficient sentence, front-loaded with the action and object, with no filler. Every phrase 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 read-only tool with one required parameter and an output schema, the description is complete enough for correct invocation. Nothing essential is missing.

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

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

Schema description coverage is 100%, and the single parameter is already documented as an OSM relation ID. The description's mention of the ID does not add meaningful semantics beyond what the schema already provides.

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 'Restituisce' and identifies the resource clearly: complete trail data given an OSM relation ID. This distinguishes the tool from search-oriented siblings like cerca_sentieri and profilo_altimetrico.

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

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

The intended use is implied: call this tool when you already have an OSM relation ID and need the full trail record. However, the description does not explicitly contrast it with alternatives such as cerca_sentieri or profilo_altimetrico, so an agent must infer when this tool is preferred.

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 provide readOnlyHint=true and openWorldHint=true, covering the read-only nature. The description adds useful behavioral context: the forecast is elevation-corrected and includes specific weather variables. It does not contradict annotations and offers extra detail beyond the structured data.

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

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

A single compact sentence that front-loads the core purpose ('hourly forecast for a point') and then lists key output elements. All words are informative, with no 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?

With an output schema present, return values need not be explained. The description conveys the essential behavior and output content, but it omits the configurable time range (ore_max) and how coordinates are specified, leaving some gaps that the schema does not fully fill. 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?

With schema description coverage at only 40%, the description should compensate for undocumented parameters. It only reinforces quota_m through 'elevazione indicata' and fails to explain lat/lon coordinate formats, ore_max meaning, or the date parameter details. Minimal added value beyond the schema.

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

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

The description clearly states it provides an hourly weather forecast for a point, corrected for elevation ('Previsione oraria per un punto, corretta per l'elevazione indicata') and lists included elements (zero termico, raffiche, neve fresca). It is specific about the resource but does not explicitly differentiate from sibling tools like bollettino_valanghe.

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

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

No guidance is given on when to use this tool versus alternatives such as bollettino_valanghe or zona_valanghe_da_coordinate. The description neither mentions siblings nor provides conditions for selection, leaving usage entirely implicit.

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 tool read-only and open-world, and the description adds value by disclosing that it downloads the full geometry and is slower than alternatives. It also clarifies the sampling mechanism, which is useful behavioral context beyond the schema.

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

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

The description is two sentences with no filler. It front-loads the core output and method, then adds the performance caveat and usage guidance in a natural order.

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 complete input schema, an output schema, and read-only/open-world annotations, the description supplies the remaining essential context: when the slowness matters and what kind of query it should be reserved for. Nothing an agent needs to call it correctly 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 coverage is 100%: both osm_relation_id and passo_m already have clear descriptions in the input schema. The tool description's mention of sampling aligns with passo_m but does not add parameter semantics beyond what the schema provides, so the baseline 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 opens with a precise verb ('Calcola') and names the resource (sentiero) plus the concrete outputs: actual length, positive and negative elevation gain. It also separates itself from sibling search tools by warning it is not intended for searches.

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 states when to use this tool ('quando serve capire l'impegno di una gita') and when not to use it ('non nelle ricerche'), and it warns about slowness. However, it refers to alternatives only generically as 'altri tool' rather than naming a specific sibling such as dettaglio_sentiero or cerca_sentieri.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context beyond that: it does NOT return a verdict, only normalized facts and attention signals, and the decision remains with the user. This is a critical safety-relevant nuance for an agent setting expectations. 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?

Two sentences with no filler: the first front-loads the aggregation use case and scope, the second adds the essential non-verdict caveat. Every clause earns its place and the structure is easy to scan.

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 adequately covers what the tool aggregates, what it returns, and what it deliberately does not do. The presence of an output schema handles return-value details, and the openWorldHint covers data variability. The only minor gap is explicit guidance on when to use sibling tools instead, but overall the description is complete enough 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?

Schema description coverage is 100%, so the schema fully documents all five parameters. The description only frames the core inputs ('sentiero' and 'data') at a high level without adding syntax, defaults, or new meaning to any parameter. Baseline 3 is appropriate.

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

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

The description states a specific action ('raccoglie in un colpo solo') and enumerates the exact resources it aggregates: trail data, nearby refuges/bivouacs, avalanche bulletin, and mountain weather. It also differentiates itself from the individual sibling tools by being a one-shot aggregation, and clarifies the output is normalized facts and attention signals, not a go/no-go verdict.

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 a clear context for use ('Dato un sentiero e una data') and the convenience of a one-shot collection, but it does not explicitly name alternatives like dettaglio_sentiero or bollettino_valanghe, nor state when to use those instead. No exclusions or when-not-to-use guidance is provided, so the routing is left to inference.

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

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

Annotations already declare readOnlyHint=true, so the description's burden is reduced. It adds behavioral context by stating that the output is the EAWS zone to be used with the avalanche bulletin, and that the tool is a prerequisite step. It doesn't cover edge cases like points outside bulletin areas, but annotations mitigate the need.

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

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

Two sentences, both dense with information. The first states the core function; the second provides immediate actionable usage advice. No fluff 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?

For a simple two-coordinate lookup tool with an output schema, the description covers the essential purpose and usage guidance. Minor omission is handling of points outside any avalanche bulletin zone, but the read-only annotation and output schema likely fill that gap.

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

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

Schema description coverage is 0%: the properties lat/lon have only numeric ranges, no descriptions. The description only says 'Dato un punto', which implies a coordinate pair but fails to specify decimal-degree format, coordinate system, or how lat/lon map to the two parameters. This leaves too much for the agent to infer.

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 'Dato un punto, individua la micro-regione EAWS a cui appartiene', using a specific verb (individua) and a specific resource (micro-regione EAWS). It also explicitly ties the tool to `bollettino_valanghe`, making its role clear and distinguishing it from sibling tools like `cerca_localita`.

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 an explicit directive: 'Usa questo tool prima di bollettino_valanghe invece di indovinare l'identificativo della zona.' This tells the agent exactly when to use the tool and what alternative to avoid.

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