EM Snow

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

The annotations already disclose that this is a non-read-only, non-idempotent write that is not destructive. The description adds meaningful behavioral context beyond annotations: the report goes live immediately and is labeled as relayed via an AI assistant. It does not cover auth requirements, rate limits, or response behavior.

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

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

Three short sentences with no wasted words, front-loading the source-integrity constraint before the behavioral disclosure. Every sentence contributes directly to correct use of the tool.

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 write tool with five parameters, no output schema, and no schema descriptions, the definition omits all parameter semantics, required fields, and the meaning of tags/rating/observed_today. It covers source integrity and immediacy well but leaves significant gaps 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 0% for five parameters, and the description adds no information about resort, text, tags, rating, or observed_today. With low coverage and no parameter details in the description, an agent must infer all parameter meaning from the schema alone.

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 ('relay a report') and implicitly identifies the resource as a snow report, though it does not explicitly say 'add a snow report' as the name and title do. It distinguishes from sibling read tools like get_snow_reports by being the submission path, but does not name 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?

It provides explicit when-to-use guidance ('Only relay a report from a person who is at, or was just at, the resort') and a clear exclusion ('Never invent a report'). It does not name alternative sibling tools or explain when to use get_snow_reports instead, but the context is clear.

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 safe read-only/idempotent/non-destructive profile, so the bar is lower, but the description adds real behavior: multiple upstream bulletin networks, that expired products are never surfaced as current, and that it is not a substitute for official advice. It stops short of stating freshness/polling or fallback behavior when no bulletin exists for a resort.

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 that are front-loaded with scope and source coverage, followed by a short disclaimer; little wasted text. The opening sentence is dense but readable, and the safety caveat is placed where it will be seen.

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 single-parameter read-only summary with no output schema and annotations covering the safety profile, the description does enough: it states sources, the fields surfaced, and the expiry guarantee. A note about behavior when no bulletin exists would close the remaining 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?

One parameter with 0% schema description coverage, so the description carries the burden for 'resort'. The phrase 'covering a resort' anchors the parameter's meaning as a resort identifier, but supplies no format, matching, or disambiguation guidance for an undocumented free-text field.

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

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

Specific verb ('Summarise') plus resource ('the regional avalanche bulletin covering a resort'), with named source networks (EAWS, avalanche.org, Avalanche Canada) and the fields returned (zone, issuing centre, issue/expiry, official link). This is clearly distinguishable from data siblings such as get_conditions, get_snow_reports or get_forecast without opening the 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?

The regional coverage statement (Europe/US/Canada) implies when the tool applies, and the closing caveat frames it as advisory rather than authoritative. However, no sibling alternative is named and no explicit when-not-to-use condition is given, so usage is only implied rather than directed.

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 cover readOnly, idempotent, non-destructive and closed-world, so the safety profile is handled. The description adds genuine context the annotations do not: the data source (local ERA5 archive) and a conditional coverage limitation on the crowd-scorer portion, which explains why results may be partial.

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

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

A single front-loaded sentence beginning with the action verb, with no filler. It is dense but every clause earns its place by naming the two distinct outputs.

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

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

There is no output schema, so the description must describe returns, and it only names two outputs without indicating format, time range, or what happens when crowd-scorer coverage is absent. Adequate for a simple read-only tool but with clear 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?

One parameter ('resort') with 0% schema description coverage, so the description must carry the burden and largely does not — it merely references 'the resort' without specifying whether a name, slug, or ID is expected. The param is self-evident enough that this stays at minimum-viable rather than failing.

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

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

States a specific verb+resource: historical snow odds plus quiet-week guidance. The word 'historical' implicitly separates it from forecast siblings like get_forecast and get_extended_outlook, but it never names an alternative or explicitly contrasts with snow_reliability, which sounds close in intent.

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 'where the crowd scorer covers the resort' discloses a coverage precondition for the quiet-week half, which is useful. However, there is no explicit when-to-use-vs-sibling guidance and no stated exclusions, so the agent must infer usage from the name alone.

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, non-destructive, and closed-world. The description adds real behavioral context beyond that: status values (ready/limited/unavailable), the meaning of each, and the fallback behavior of returning the resort page when no tour is available. It does not mention latency or link-expiry traits, which keeps it short of a 5.

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 dense sentences that front-load the core outcome (a link to a 3D tour) and then pack status semantics into a compact parenthetical. It is efficient, though the long nested clauses around status make it slightly harder 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?

With no output schema, the description correctly explains the return value (a link) and the degraded return (resort page). It covers the status lifecycle an agent needs to interpret results, though the silent 'level' parameter leaves one input unaccounted for.

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 carry the burden. It explains 'pick' (names matching route_on_mountain, with picker ids for ambiguity) and 'runs' (which runs the tour covers), but says nothing about 'level' (all/easy/intermediate) or how 'resort' is resolved, leaving key inputs under-explained.

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

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

The description states a specific verb and resource: it returns a link that plays a simulated 3D flyby tour of a resort or of named runs. It distinguishes itself from the broader resort-info siblings by naming route_on_mountain as the reference for pick-name matching, though it never frames itself as an alternative to a specific sibling.

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 implies usage ('or a tour of runs you name') and references route_on_mountain for name-matching behavior, which hints at shared context. However, it never states explicitly when to call this tool versus route_on_mountain or get_resort_media, leaving the choice 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds a genuinely useful data-freshness caveat that annotations cannot express: lift and run counts are reported status, not guaranteed live. It omits error behavior for unknown resorts and any caching/latency notes.

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 tight sentences with zero filler; the payload of what is returned comes first and the caveat is appended after. Nothing redundant or padded.

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 no output schema, the description usefully enumerates the return contents (snow, lift/run counts, weather, season state), which covers the most important gap. For a read-only, one-parameter tool the remaining omissions, resort identifier format and unknown-resort behavior, are minor.

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 single required 'resort' parameter, so the description must carry the load. It never clarifies whether 'resort' is a name, slug, or ID (only maxLength 100 in schema). The name is largely self-explanatory and the surrounding context scopes the entity, so this is a mild but real gap.

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

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

States a specific verb ('Get') and enumerates the returned resources (current snow, lift and run counts, weather, season state), which is far more than a restatement of the title. It does not, however, name or contrast itself with close siblings such as get_forecast, get_snow_reports, or get_extended_outlook, so an agent must infer the boundary 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 word 'current' implicitly signals this is the now-snapshot tool versus the forecast/outlook siblings, but the description never states when to choose it over get_forecast, get_snow_reports, or get_extended_outlook, and lists no exclusions. Usage is implied rather than stated.

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 establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description goes beyond them by disclosing the underlying models, the self-hosted provenance, and importantly the confidence asymmetry between days 1-7 and 8-16, which materially affects how an agent should present results.

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

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

Two dense sentences, front-loaded with the core capability, then the variable list, then the source and the confidence caveat. No filler; every clause carries information an agent can act on.

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 no output schema, the description compensates by enumerating the returned fields (snowfall, temperatures, freezing level, gusts, precipitation probability) and their availability limits. It is nearly complete; the only gap is guidance on the resort parameter format.

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 carry parameter meaning. It conveys the 16-day ceiling and the 1-7 vs 8-16 split, implicitly documenting the days parameter, but says nothing about the required resort parameter's accepted values/format and never mentions the default or lower bound.

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

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

States a specific verb (Get), resource (16-day daily outlook), the exact variables returned, and the data sources (GFS/ECMWF IFS). It explicitly distinguishes itself from get_forecast by noting the days 1-7 overlap, so an agent can tell the two apart.

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?

Clearly frames when this tool is worthwhile: days 8-16 as low-confidence trend guidance, and it flags that days 1-7 duplicate get_forecast. It stops short of an explicit directive ('use get_forecast for days 1-7'), but the routing intent is unmistakable.

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, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds only the day cap, which is already in the schema as maximum:10, and says nothing about data freshness, availability ('available' is vague), or units.

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 sentence that front-loads the verb and resource and then lists the returned data, with no filler or 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?

With no output schema, the description does well to enumerate the forecast dimensions returned. However, for a tool sitting among several forecast/conditions siblings with a fully undocumented parameter set, it omits selection guidance and the resort identifier format, leaving real gaps.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only loosely references the 'days' parameter via 'up to 10 requested days' and says nothing about 'resort' (expected identifier format, name vs. id, or how it relates to search_resorts). The required resort parameter is left entirely undefined.

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?

Names a specific verb (Get) and resource (forecast) and enumerates the forecast contents (snow, temperature, freezing level, wind-hold risk), which is genuinely informative. It does not distinguish itself from close siblings like get_extended_outlook, get_conditions, or best_time_to_go, so an agent must guess which forecast tool to pick.

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?

There is no statement of when to use this tool versus the many overlapping siblings (get_extended_outlook, get_conditions, best_time_to_go, get_snow_reports). The 'up to 10 requested days' clause hints at a short-range use case but never makes the boundary 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, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing attribution/licence obligations for returned media and stating the negative fact that no trail-map image is available, which prevents an agent from hunting for one.

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 dense sentence that front-loads the purpose before listing contents, with no filler. It is slightly run-on in the enumeration, but every clause carries distinct 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?

With no output schema, the description does the work of describing the return payload in detail, including licence and attribution fields, and rules out the trail-map image. The remaining gap is the undocumented input format and no mention of behavior when a resort has no media.

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

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

Schema description coverage is 0% and the single required 'resort' parameter is undocumented in both schema and description. The description never says whether the value is a name, slug, or ID, nor what happens on an unknown resort, so with a 0% coverage it fails to compensate.

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

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

States a specific verb+resource ('Get images for a resort') and then enumerates exactly what comes back: webcams with provider credit, a Wikimedia Commons photo with licence/author/source, the EM Snow teaser, and the resort page link. An agent can distinguish this from get_webcams, which returns camera feeds alone, without opening a 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?

The phrase 'that vision-capable assistants can show' implies the intended context, but there is no explicit when-to-use guidance, no exclusions, and no pointer to the closely overlapping siblings get_webcams or watch_resort. Usage must be inferred from the content listing.

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, covering the safety profile. The description adds useful content-level context by stating that reports are recent, visible, and include their source (website vs AI relay), but it does not explain what 'visible' means or how results are ordered or limited.

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 well-formed sentence with no filler. The core scope is front-loaded, and every phrase carries informational weight.

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 no output schema and 0% parameter description coverage, the description should compensate by explaining the required resort input and the limit behavior. Instead it covers only the report source detail, leaving the agent without enough context to invoke the tool confidently.

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 two parameters, yet the description never mentions 'resort' or 'limit'. It gives no indication of what the resort parameter accepts or what the limit controls, leaving the agent entirely dependent on the bare 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 states a specific verb and resource: getting recent visible community reports, with a clear scope. It does not, however, differentiate this tool from siblings like get_conditions, get_forecast, or add_snow_report, so the agent must infer when community reports are the right artifact.

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

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

The description provides no when-to-use guidance, no prerequisites, and no alternatives to consider. The agent is left to infer that this tool should be used when community reports are desired, without any explicit routing or exclusion criteria.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld=false, so the safety profile is covered. The description adds one useful behavioral detail beyond that – the required provider credit, implying an attribution obligation on the returned content – but says nothing about freshness, availability, or rate limits.

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

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

A single front-loaded sentence that names the payload and the credit requirement with no filler. Efficient, though it spends its one clause on output rather than on routing or the input parameter.

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 one-parameter read tool with full safety annotations, the description is mostly adequate and does describe the return payload. However, with no output schema and an undescribed required parameter, it leaves the input side and the credit/attribution mechanics underspecified.

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

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

Schema coverage is 0% and the description never mentions the required 'resort' parameter or its format, so it does no compensating work. The parameter name is somewhat self-explanatory, which keeps this above a 1, but the description adds no meaning beyond the bare 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 states a specific verb (get) and resource (nearby webcam images and their source links), so the agent knows exactly what comes back. It doesn't distinguish itself from plausible siblings like get_resort_media or watch_resort, but the resource is concrete enough to be 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?

There is no when-to-use guidance, no exclusions, and no mention of an alternative sibling. An agent cannot tell from this text whether to prefer it over get_resort_media or watch_resort.

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, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds one genuine nuance — that snow reliability is 'modelled' rather than observed — but says nothing about data freshness, caching, or failure behavior when a resort is unmapped.

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

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

A single front-loaded sentence listing the payload; dense but no filler and no repetition of the title. Slightly list-heavy, though every clause names a distinct returned field.

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?

No output schema, but the description effectively enumerates the return payload (terrain, lifts, vertical, run length, facts, season dates, snow reliability), which is what an agent needs to decide to call it. The gaps are the unexplained 'resort' argument format and the absence of routing guidance.

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?

One required parameter ('resort') with 0% schema description coverage, so the description carries the full burden and does not meet it. It never states the expected format (name vs. slug vs. ID), matching rules for ambiguous names, or length limits beyond the schema's maxLength.

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

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

States a specific verb ('Read') and enumerates the resource: OSM terrain inventory, lift fleet, vertical, longest run, Wikidata facts, season dates, modelled snow reliability. An agent can tell this is a static resort-facts lookup rather than a conditions/forecast tool, but it never explicitly names the siblings it differs from.

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 when-to-use, when-not-to-use, or alternative guidance at all. Despite heavy sibling overlap (snow_reliability, get_conditions, where_is_it_snowing, best_time_to_go), the description gives no hint which to pick for a given question.

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 non-destructive behavior, so the safety profile is covered. The description adds only that results come from the 'local EM Snow resort index', which is minor but useful context; it does not describe rate limits, data freshness, or output shape.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though its extreme brevity contributes to gaps in other dimensions rather than adding value.

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 two-parameter retrieval tool, the description omits essential guidance: it does not explain the 'resort' input, the 'limit' capability, or when to choose this tool over similar siblings. Annotations cover the safety profile, but the description is still too thin 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 0%, so the description carries the burden of explaining both parameters. It does not clarify that 'resort' is the reference point for proximity or what format it expects, and it ignores 'limit' entirely. The word 'resort' appears but only incidentally, providing minimal semantic guidance.

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

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

States a specific verb and resource: 'Find nearby resorts'. However, it does not distinguish this tool from siblings like search_resorts or suggest_resort, and 'nearby' is left relative to an unspecified reference.

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 no indication of when to use this tool versus alternatives such as search_resorts or suggest_resort. It merely states what the tool does, leaving context 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 cover the safety profile (readOnly, idempotent, non-destructive). The description adds behavior beyond that: season-gating, terrain-level exclusion rules, and the explicit limitation that output is not live piste status — genuinely useful context. It still doesn't disclose output shape or any latency/data-freshness traits.

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 core action is front-loaded in the first sentence, followed by scope constraints, level semantics, and a disclaimer. Every sentence carries information with no filler, though the density makes it slightly heavy for a three-parameter tool.

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 no output schema and 0% schema description coverage, the description should ideally explain the returned plan and the date/resort inputs. It covers level semantics and season gating but leaves the output format and two parameters unaddressed, so it is only adequately 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 coverage is 0%, so the description must carry parameter meaning. It does explain the level semantics well (easy/intermediate/advanced exclude expert, freeride and extreme terrain; only expert permits it), which maps directly to the enum. But date and resort receive no explanation beyond the season constraint, leaving part of the burden unmet.

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 gives a specific verb and resource — 'Build modelled suggested runs in time order from forecast weather, sun, snow and mapped terrain' — so an agent knows it produces an ordered day plan. It also distinguishes itself from route_on_mountain by stating suggestions 'are not a connected route.' It stops short of clarifying its relationship to other planning siblings like best_time_to_go.

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 states important constraints (only days inside the reported winter season, summer lift/bike-park does not count) which implies when the tool is valid. However it never explicitly tells the agent when to choose this over siblings such as suggest_resort, best_time_to_go or route_on_mountain — the routing is only implicit via the 'not a connected route' caveat.

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 cover only the safety profile (readOnly, idempotent, non-destructive), while the description discloses genuinely non-obvious behavior: matching order (exact, then prefix, then contained words), multi-piece OSM pistes counting as one, lift endpoints resolving to top vs bottom station, candidate lists on ambiguity, and the 5 km coordinate rejection rule.

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 dense paragraph of roughly 110 words, front-loaded with what the tool does before the rule details. Every clause carries substantive semantics, though the compound sentences on lift resolution and level filtering are somewhat hard 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?

For a routing tool with no output schema, the description supplies most of what an agent needs to call it correctly, including failure modes and ambiguity handling. It stops short of describing the returned route (geometry, distance, elevation) and omits the avoid_closed parameter's behavior.

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

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

With 0% schema description coverage the description must carry all parameter meaning, and it does so well for from/to (name matching, lift top/bottom resolution), resort (coordinate proximity limit) and level (terrain-avoidance semantics, expert as the only level permitting freeride/extreme). It never explains the avoid_closed parameter or its default, leaving one of five params undocumented.

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

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

States a specific verb ('Route between') and concrete resources (named pistes, lifts, resort base, lat/long coordinates) powered by mapped OSM data. No sibling tool performs routing, so the function is unambiguously distinct from the informational tools in the sibling list.

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?

Gives clear operational context: name matching is accent-insensitive and partial, ambiguity returns candidates, and out-of-resort coordinates are rejected, which tells the agent when the call will fail. It never states an explicit 'use this rather than X' alternative, though no sibling offers routing, so nothing critical is missing.

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, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: a hard 20-match cap and the fact that the bulk resort index is not exposed. It stops short of describing ordering/truncation behavior when the cap is hit.

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

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

Two tightly written sentences with zero filler; the primary capability is front-loaded and the result cap follows as a secondary constraint.

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 no output schema and 0% schema description coverage across four parameters (including a nested object), the description covers the search axes but omits the limit semantics, default value, and what matches look like. It is adequate to call the tool but not to predict its behavior precisely.

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 maps loosely onto query, country and near ('name, country or distance') but never explains the nested lat/lon object, the 1-20 limit bounds, or the default of 10, leaving a real gap for a 4-parameter tool.

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

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

States a specific verb and resource ('Find ski resorts worldwide') and names the three search dimensions (name, country, distance). It is clear what the tool does, though it never contrasts itself with close siblings like nearby_resorts or suggest_resort, which also surface resorts.

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

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

Usage is implied by the search dimensions, and the note that it 'does not expose the bulk resort index' signals a use case boundary. However, there is no explicit when-to-use guidance and no routing to alternatives such as nearby_resorts for distance-based lookups or suggest_resort.

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, destructiveHint=false and a non-open-world (local) scope, so safety is covered. The description usefully corroborates the local source ("local ERA5 archive") but says nothing about return format, the meaning of "most recent completed season", or latency/caching for an archive-backed lookup.

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?

It is a single short sentence with the action front-loaded, which is good. However, the dangling "first" adds ambiguity rather than meaning and is dead weight in an otherwise minimal description.

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 single-parameter, read-only lookup with no output schema, the description should at least indicate what a "recap" contains (snow totals, days, etc.) or how far back the ERA5 archive reaches. It names the source but leaves the agent without a sense of the returned content.

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

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

There is one required parameter (resort) with 0% schema description coverage, and the description adds no information about it — no format, no valid values, no hint that it identifies the resort the recap applies to. With the schema silent, the description should have compensated and does not.

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 gives a specific verb ("Summarise") and resource ("the most recent completed ski season"), and identifies the data source ("local ERA5 archive"), which separates it from forecast/conditions siblings. The trailing "first" is confusing and suggests a sequencing the tool doesn't appear to have, but the core purpose is clear.

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

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

There is no explicit when-to-use guidance. The word "first" vaguely implies ordering relative to other tools but never names an alternative or a condition (e.g., when to prefer this over get_conditions or snow_reliability). The agent must infer when a season recap 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, idempotentHint, destructiveHint=false and closed-world behavior, so safety is well covered. The description adds genuinely useful context beyond that — the score is 'explainable' and derived from long-run ERA5 snow depth rather than current conditions — but it never states the score's scale, interpretation, or that results are historical/climatological rather than real-time.

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

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

A single front-loaded sentence with no filler; the key noun phrase ('snow-reliability score') and data source appear early. It is efficient, though so terse that brevity edges toward under-specification.

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 no output schema, the description carries the burden of explaining the return value, and 'explainable ... score' implies a value plus rationale but gives no scale or structure. Given a single-parameter, read-only tool with full annotation coverage, this is adequate but leaves the parameter format and score interpretation unspecified.

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 single required 'resort' parameter has 0% schema description coverage and the description never mentions it at all — no identifier format, naming convention, or whether IDs from search_resorts/suggest_resort are expected. With a non-zero parameter count and zero coverage, the description fails to compensate.

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

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

The description states a clear verb+resource ('get an ... snow-reliability score') and names the underlying data source ('long-run ERA5 snow depth'), which is more specific than a bare restatement of the title. It distinguishes itself reasonably from sibling reads like get_conditions or get_snow_reports, though it doesn't explicitly name what makes it different from them.

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?

There is no when-to-use guidance: no indication of which resort identifier to supply, no comparison to siblings that also report snow (get_snow_reports, get_conditions, wheres_it_snowing), and no mention of when a reliability score is preferable to a live forecast.

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 disclose readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds valuable context that the suggestion goes to human review and never enters the resort index, clarifying the write's effect. It does not cover auth or rate limits.

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

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

Two short sentences, front-loaded with the core action and immediately followed by the key behavioral constraint. 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 tool with 6 parameters and no parameter descriptions, the description does not help an agent provide correct inputs (e.g., country format, lat/lon conventions, notes purpose). While annotations cover safety, the parameter gap is significant.

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 6 parameters (4 required). The description adds no information about parameters, leaving formats and meaning entirely to the schema's type and constraint definitions, which only partly compensate.

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

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

The description states a specific verb ('Suggest') and resource ('missing resort') and adds the qualifier 'for human review'. It clearly distinguishes this from direct addition, though it does not name a sibling 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?

Usage is implied: use when a resort is missing from the index, and the tool will not add it directly. However, there is no explicit when-to-use guidance or reference to alternative tools for adding resorts.

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, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds one genuinely useful behavioral caveat — shading is only modelled 'where DEM coverage exists' — but says nothing about cost, caching, or the shape of what 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?

A single front-loaded sentence with no filler, and the conditional limitation is placed at the end where it reads naturally. It is efficient, though the compression contributes to the vagueness noted elsewhere.

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

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

With no output schema and 0% parameter description coverage, the description carries the full explanatory burden and does not meet it: an agent still cannot tell what a 'window' looks like in the response, what date defaults to, or what happens outside DEM coverage. Only the annotation layer is 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% across two parameters (resort, date). The description supplies no parameter meaning at all: neither the accepted resort identifier form nor the expected date format is stated, so the schema gap is left entirely unpatched.

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 modelled output (sun and shade windows across eight slope aspects), which is more than a restatement of the title. However, 'sun and shade windows' is jargon that an agent cannot map to a concrete result, and the description does not distinguish this from siblings like best_time_to_go or plan_my_day that plausibly overlap in intent.

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?

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. An agent has no signal for choosing this over best_time_to_go or get_conditions.

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, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely new context beyond that: it returns a URL artifact rather than data, and it explicitly does not collect email, which is a meaningful privacy trait an agent would not otherwise know. It still omits link permanence or auth requirements, so not a 5.

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 tight sentences with no filler; the core capability (returns a watch URL) is front-loaded and the caveat follows. Every sentence earns its place.

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

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

For a one-parameter tool with no output schema, the description adequately describes the return artifact (a URL) but leaves gaps: the resort identifier format is unexplained and the mention of dates has no corresponding schema field. Adequate but with clear omissions.

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

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

Schema coverage is 0% and the single 'resort' parameter has no description, so the description carries the full burden. It never explains the expected format (name, slug, or ID) for 'resort', and it mentions 'optionally add dates' even though no date parameter exists in the schema, which makes the parameter story less clear rather than more.

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+resource: it returns a one-tap URL where a person can watch a resort. It also states the scope constraint that dates are optional. It doesn't name or contrast a sibling (e.g. get_webcams), so it stops short of 5.

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

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

There is no explicit when-to-use guidance or comparison to alternatives such as get_webcams or get_resort_media. The use case is only implied by the phrase 'where the person can watch a resort', leaving the agent to 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 already declare the safe-read profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description does add useful context that results come from a cached home-page ranking, implying a limited, possibly stale curated set rather than a live full inventory. It stops short of saying how fresh the cache is or how many entries it yields.

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

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

A single front-loaded sentence with no filler; the core action and source come first. It is arguably too terse given the undocumented parameters, but nothing is wasted.

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 no output schema and 0% parameter coverage, the description carries the full burden, yet it says nothing about the shape of the ranked results (resort name, snow total, report date) or about the two inputs. An agent can guess the intent but not what it will receive or how to scope the call.

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 schema supplies names and constraints only, and the description compensates for none of it. Neither 'limit' (default 10, max 20) nor 'hemisphere' (nh/sh enum) is mentioned, and the effect of hemisphere on ranking is left entirely unexplained.

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

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

Clear verb ("Rank") and resource ("freshest recently reported snow"), with the data source named ("EM Snow home-page ranking"). It is distinguishable from siblings like get_snow_reports by being a global ranking rather than a resort-scoped report, though the description never explicitly contrasts them.

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?

There is no when-to-use guidance, no mention of prerequisites, and no alternative named among the many snow-related siblings (get_snow_reports, get_conditions, snow_reliability). The agent must infer that this is a discovery/ranking tool from the purpose statement alone.

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