skimetric

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

Beyond the annotations, it discloses the key behavioral requirement: presenting entry_url exactly as given is what attributes the booking and funds free access. It also adds specifics like 'local shops when we know them' and risks no contradiction with the annotations.

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

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

The description is two dense, well-ordered sentences: scope first, then categories, then the critical entry_url behavior, then formats. Every sentence carries actionable information 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?

Without an output schema, the description still covers the core integration contract: every item carries an entry_url and the URL must be opened exactly as given to attribute the booking. It leaves minor gaps around parameter defaults and the exact result shape, but those are secondary for invoking the tool correctly.

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

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

Schema coverage is 0%, but the description compensates by specifying date format (ISO YYYY-MM-DD), origin format (city or IATA), and the role of party and dates in the stay search. It does not explain defaults or optionality, but all six parameters are at least functionally implied.

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 names a concrete resource ('a resort stay') and enumerates the categories returned: flights, stay search, ski rental, car, transfer, and eSIM. It lacks an explicit verb like 'list' or 'return,' so it stops just short of top clarity.

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 gives a clear use context: everything bookable for a resort stay with no trip required, which helps an agent distinguish this from trip-planning or trip-status tools. It also provides explicit handling instructions for entry_url, though it never names sibling alternatives or states 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 mark it non-read-only and destructive, but the description goes further by explaining the precise side effects: choosing activates the LIVING JOURNEY, changes future trip_status responses to a requirements checklist, announces the choice in the trip conversation, and is reversible by choosing again. 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?

Three dense sentences, each earning its place. The core action and parameter source are front-loaded, followed by reversibility, downstream effects, and conversation visibility. No filler or repetition.

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

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

The description covers the action, side effects, reversibility, and downstream trip_status behavior, which is substantial. However, without an output schema it never states what choose_path itself returns, and the grant parameter remains entirely unexplained, leaving a notable gap for the agent.

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 carries the burden of explaining parameters. It clearly explains path_id as coming from trip_status options[].id, and trip_id is implied by 'the trip's own conversation', but grant is never mentioned at all. With one of three required parameters undocumented, compensation is incomplete.

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, and data provenance: 'Choose one of a delivered trip's researched options' with 'path id from trip_status options[].id'. This makes it unmistakably different from read-only status or planning tools like trip_status or plan_trip.

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?

Provides clear context for when to use the tool: after a trip's options have been researched and are visible in trip_status. It also clarifies the consequence (activating the LIVING JOURNEY) and reversibility, though it does not explicitly name alternatives or exclusion cases.

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

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

Beyond the readOnly/destructive annotations, the description discloses a non-obvious fail-closed data policy: 'absent means no source reported, never a guess' and notes that data is dated. This materially changes how an agent should interpret missing fields and prevents fabrication. It also names the data sources (operator, skier reports, avalanche bulletin), which is exactly the extra behavioral context annotations cannot express.

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 organizes the key idea up front and then expands into three datum types, with the important fail-closed caveat tucked into a parenthetical. Every phrase contributes meaning and no words are 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?

For a read-only, one-parameter tool with no output schema, the description covers what the result contains (lift/piste counts, skier thumbs, avalanche bulletin), freshness semantics, and absence behavior. Minor gaps remain around exact return formatting and how the avalanche bulletin is localized, but nothing blocks a correct 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 coverage is 0%, so the description carries the burden for the single 'resort' parameter. The phrase 'for one resort' clarifies that the parameter selects a single known resort, but the description does not specify accepted value format or whether it expects a name, slug, or ID. Given there is only one parameter and its schema title is 'Resort', this is minimally adequate but not enriched.

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

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

The opening phrase 'Live mountain truth for one resort' names the resource and scope, and the colon list enumerates concrete content types: lifts/pistes counts, skier thumb reports, and avalanche bulletin. It is clear even without a verb, and the content list implicitly distinguishes it from forecast-oriented siblings like snow_forecast and daily_snow, though it never names 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 description establishes implied usage: call this for current, single-resort operating status and avalanche information. It does not explicitly state when to prefer a sibling such as snow_forecast, webcams, or daily_snow, nor does it give exclusion criteria. The signal is adequate but leaves routing decisions to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds that the output is editorial-style and focused on current weather, which is useful context beyond the annotations. However, it does not describe the return format, pagination, or any other behavioral traits, but given the annotations cover safety, this is acceptable.

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 long, with the purpose front-loaded and the parameter note following naturally. Every sentence earns its place; there is no filler or redundant information. It is compact while conveying core semantics.

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 three optional parameters and no output schema, the description is nearly complete. It covers the purpose, scope, and the filter options (albeit not lang). The only missing piece is an explicit note on what the output looks like, but since there is no output schema and the tool is editorial, this is a minor gap. Overall, an agent can call this tool correctly with the given information.

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

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

The description explains that 'country' takes an ISO-2 code and that both country and region are optional filters, giving meaning beyond the schema which has no descriptions. However, the 'lang' parameter is not mentioned at all, and the format for 'region' is unspecified. With 0% schema coverage, the description partially compensates but leaves at least one parameter 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?

The description clearly states it provides today's Daily Snow editorial with expert-style regional briefs on current weather across the Alps and beyond. It uses a specific verb ('briefs') and resource ('Daily Snow editorial'), and the phrase 'actually doing' implies current conditions rather than forecasts. However, it does not explicitly contrast with sibling tools like conditions or snow_forecast, so it is not fully differentiated by description alone.

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

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

The description implies use for a daily editorial summary of current conditions, but it never explicitly says when to prefer this over sibling tools such as snow_forecast or conditions. There is no mention of alternatives or specific exclusions, leaving the agent to infer the appropriate context. The 'Today's' and 'actually doing' hints, but the guidance is not explicit.

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

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

Annotations already mark the tool as read-only (readOnlyHint: true) and non-destructive (destructiveHint: false). The description goes beyond that by disclosing the maximum result count (up to 20 matches), the absence of pagination/bulk access, and that the returned slug is the identifier used by every other tool. This adds meaningful behavioral context about limitations and how the tool fits into the larger workflow.

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

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

The description is compact and front-loaded: the purpose is stated in the first sentence, followed by the key return values and a limitation. No redundant wording. Every sentence adds value, and the structure helps an agent quickly grasp what the tool does and how to use it.

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 search tool with three simple optional parameters and no output schema, the description covers all essential aspects: what it takes (name/country), what it returns (slug, elevations, 3-day snow), the maximum result cap, and the absence of bulk access. The safety profile is already handled by annotations. Nothing critical is missing for an agent to call this tool correctly.

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

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

The input schema has zero description coverage, so the description must compensate. It explains that 'query' is the resort name and 'country' is an ISO-2 country code. The 'limit' parameter is implied by the statement 'Returns up to 20 matches', though the description does not explicitly tie the parameter to that limit. Still, agents can reasonably infer that limit controls the number of results. This addition is useful 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 ('find'), a clear resource ('European ski resorts'), and the two search dimensions (name and ISO-2 country code). It also specifies the output (slug, elevations, 3-day snow) and distinguishes itself from sibling lookup tools by noting that the slug is the ID every other tool takes. This makes the tool's purpose unambiguous and differentiates it from nearby tools like where_to_ski or plan_trip.

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

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

The description clearly indicates when to use the tool — to search resorts by name or country. It also gives operational guidance: refine the query rather than paging, since there is no bulk catalogue access. It does not explicitly mention alternatives or when not to use it, but the context of siblings implies that this is the primary lookup tool and that other tools consume its output. This is clear context without 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?

The description discloses important behavioral details beyond the annotations: first-ever routes can take minutes, the caller should retry after a timeout, flight entry_url appears only when an origin is known, and mode supports drive or transit. This gives the agent realistic expectations about latency and conditional output. 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: purpose first, then output details, then parameter formats and latency guidance. Every sentence adds necessary information with no repetition of schema fields or filler.

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

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

For a tool with no output schema, it covers the main return values, conditional behavior, and timeout retry guidance. The only notable gap is the lack of explicit resort value format, but an agent can still invoke the tool correctly with the information provided.

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 meaningfully explains origin as city name, IATA code, or lat,lon, and clarifies mode as drive or transit. The resort parameter is implied as the destination but its accepted value format is not explicitly described.

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 what the tool does: plan how to reach a resort by returning arrival airports with drive times and, when an origin is provided, a door-to-door itinerary. It does not explicitly distinguish itself from siblings like plan_trip or choose_path, but the specific outputs are clear enough to infer its role.

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 actionable context: origin is optional but changes the output, mode is drive or transit, and timeout handling is explained. It does not explicitly say when to use this over sibling tools, but the conditions under which the tool behaves differently are clearly 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context: the data is sourced from OpenStreetMap mappers, is static (never live), and is limited to built infrastructure. It also clarifies the tool does not report current conditions, which is a meaningful behavioral boundary beyond the annotations.

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

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

The description is concise and well-structured. It front-loads the core definition, then adds the key distinction from `conditions` in a separate sentence. Every sentence earns its place, and the formatting with line breaks improves readability.

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 parameter and no output schema, the description is largely complete. It explains what data is returned, the data source, and the key limitation (static, not live). The only minor gap is not specifying the expected format of the `resort` parameter, but this is a small omission given the tool's simplicity.

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. The description does not explicitly explain the `resort` parameter, but it implies the tool takes a resort name and returns facts about that mountain. Since there is only one parameter and the tool's purpose is clear, an agent can infer the parameter's meaning. However, it would be stronger if it explicitly stated the expected format (e.g., resort name as used in OpenStreetMap).

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

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

The description clearly states the tool's purpose: it reports static mountain facts (lift counts by type, piste kilometres by difficulty, vertical drop, nursery lifts) as tagged in OpenStreetMap. It explicitly contrasts itself with `conditions`, which reports live operator-verified data, making it easy for an agent to distinguish between the two.

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

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

The description explicitly says when to use this tool vs. alternatives: use it for 'what is BUILT there' and use `conditions` for 'what is open today'. It also notes that `conditions` fails closed when no operator has reported, which helps an agent choose correctly.

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

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

Beyond annotations, the description discloses the click-recording side effect and that resolving vs. presenting both record identically. This clarifies non-idempotence and expected side effects, though it omits failure cases or auth/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 sentences with no filler; the core purpose and side effect are front-loaded, and the conditional guidance is concise.

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 covers purpose, side effects, when to use, and the alternative. The return behavior is implied by 'resolve to its live partner destination,' which is sufficient.

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

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

With 0% schema description coverage, the description compensates by explaining the entry_url is resolved to a live partner destination and that the destination domain is the key information sought. It doesn't provide URL format details, but the single self-named parameter is otherwise clear.

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

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

Description specifies a concrete verb ('resolve') and resource ('one entry_url') and states the outcome ('live partner destination'). It distinguishes itself from the alternative of presenting/navigating the entry_url directly.

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?

Explicitly states the only condition for use ('when you must know the destination domain in advance') and says what to do otherwise. Names the alternative approach and notes both record identically.

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 mark it read-only and non-destructive, so the safety profile is covered. The description adds substantial behavioral context: model behavior by forecast horizon, per-day and per-window outputs, dominant risk, and the explicit instruction to phrase results as likelihood. This goes well beyond the structured 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 dense and front-loaded: purpose and key contrast come first, followed by output semantics and operational details. It is slightly run-on but every sentence contributes useful information, 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?

Because there is no output schema, the description appropriately defines the key returned values: p80, p_any, dominant risk, and expected_open_days. It also covers date constraints, forecast horizons, and communication style. The main missing piece is how to specify the resort, though sibling tools like find_resorts may 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?

With 0% schema description coverage, the description must compensate, and it does explain start/end format, defaults, and max window. However, the required resort parameter is only referred to as 'one resort' without saying what value it expects (name, slug, or ID), which is a meaningful gap for a required parameter.

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

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

The description clearly states the tool computes the chance that lifts run, per day, for one resort over a date window, and explicitly frames it as a forecast, not a report. It also distinguishes itself from conditions by naming what that sibling does. The resource, action, and scope are all 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?

It explicitly says to use conditions when the human needs verified current status, which is direct alternative routing. It also gives practical boundaries: default 10 days, max 61 days, date format, and instructions to phrase outputs as likelihood rather than fact. This is strong when-to-use guidance.

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

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

Annotations declare readOnlyHint=false, so the description's 'start research' is consistent. Beyond that, the description adds valuable behavioral context: the 5-minute duration, the daily slot consumption, the polling mechanism (trip_status), and the crucial claim_url handoff behavior (guest vs sign-in permissions). This is exactly the kind of non-obvious behavior an agent needs to know and that annotations do not provide.

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

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

The description is front-loaded with purpose, then packs essential operational details into three sentences. The example brief is efficient and illustrative, and the claim_url explanation is compact but complete. No fluff, every sentence adds 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?

There is no output schema, so the description must explain return values, which it does: trip_id, grant, and claim_url, plus the polling instruction. It also covers the human handoff and permission implications. It does not address edge cases like slot exhaustion or error handling, but for the core usage it is sufficiently complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the 'brief' parameter in detail with an example, which is the core input. However, it does not mention 'lang' or 'origin' at all. These have defaults and are relatively self-explanatory, but for a tool with only three parameters, the description should at least acknowledge them. It partially compensates but leaves gaps.

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 clear, specific verb-resource pair ('Start REAL Skym trip research') and immediately differentiates from sibling tools by stating it works from a natural-language brief. It also lists the exact inputs (who, when, vibe, budget) and gives a concrete example, so an agent can unambiguously identify this as the trip-initialization tool versus alternatives like trip_status or find_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?

The description provides strong contextual guidance: it states the research takes ~5 minutes, costs one of 3 daily slots, and that the caller should poll with trip_status. It does not explicitly name alternatives or say when NOT to use it, but the cost and async nature imply this is a heavy, one-shot action. Slight gap: no mention of when to prefer other tools.

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 destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond that: image URLs are direct from the tool's own domain, size variants are specified, and every image carries credit/licensing information that must be preserved. No annotation contradiction.

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 tight sentences: the first states purpose, the second describes the URL/size format, and the third gives the licensing requirement. There is no filler, and the important purpose 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?

For a simple, read-only media tool with one parameter and no output schema, the description covers content type, URL format, dimensions, and licensing—enough to invoke the tool and understand its output shape at a high level. It does not specify the exact JSON structure or behavior when no media exists, but those gaps are minor given the tool's simplicity.

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

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

The schema has zero description coverage for the only parameter, 'resort'. The tool description only says 'of a resort', which essentially restates the parameter title and adds no new meaning about accepted values, identifier format (slug, ID, or display name), or how to obtain valid values. With 0% schema coverage, the description needed to compensate 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 clearly identifies the resource ('Pictures of a resort') and the specific content types (approved winter photography and topography circuit renders), which distinguishes it from live/conditions-oriented siblings like webcams. However, it lacks an explicit verb such as 'get' or 'retrieve', so it falls just short of a 5.

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

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

The description implies when to use the tool ('so an agent can show its user the terrain', 'for vision-capable agents') and even includes licensing instructions for reuse, but it never directly contrasts this tool with alternatives such as webcams or where_to_ski, nor states 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it is a human-written editorial piece, available for 673 resorts, and localized 'in the reader's language where we have it'. This goes beyond the annotations and helps the agent set expectations about content type and coverage.

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 purpose, the second adds coverage and context, and the third gives a clear usage rule. Every sentence earns its place with no fluff.

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

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

For a simple read-only tool with 2 parameters and no output schema, the description is largely complete. It explains what the content is, when to use it, and its coverage. The only minor gap is not explicitly stating what the return value looks like (e.g., a text block), but the description's characterization of it as a 'written piece' makes that reasonably clear.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'resort' parameter implicitly (the write-up is about a resort) and mentions 'lang' indirectly via 'in the reader's language where we have it'. However, it doesn't explicitly state that 'lang' controls the language of the write-up or that 'resort' is the resort identifier. The description adds some meaning but leaves the parameter mapping somewhat implicit.

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 what the tool does: it returns a written editorial piece about a resort, covering what the mountain is like, who it suits, and what it does badly. It also distinguishes itself from forecast tools by explicitly saying it answers 'what is X like?' rather than 'how much snow'.

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 tells the agent when to use this tool: when someone asks 'what is X like?' rather than 'how much snow'. It also contrasts with forecast tools, which are siblings like snow_forecast and conditions, making the routing decision 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond that, such as the number of years behind each fortnight so a thin sample is indicated, which informs the agent about data reliability. It also lists the specific data types returned, enriching the operational understanding without contradicting annotations.

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

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

The description is moderately detailed but each sentence adds value: the first explains the core concept, the second details the data fields and quality, and the third covers the band filter. It is front-loaded with the primary purpose and avoids fluff. Slightly longer than necessary but not verbose enough to hinder readability.

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

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

For a read-only data retrieval tool with two parameters and no output schema, the description covers the essential aspects: what data is returned, how to filter by elevation band, and the data's historical depth. It does not describe the response format, but without an output schema that is expected. The description is sufficient for an agent to decide when to call this tool and what arguments to provide.

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 explicitly explains the 'band' parameter with its possible values (base/mid/summit) and that it is optional. The 'resort' parameter is not elaborated, but it is required and likely self-explanatory given the tool's domain. The description also clarifies the output content, which indirectly helps understand the parameters' purpose.

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: splitting ten winters into twelve fortnights per elevation band, with specific data fields (fresh snow, snow days, temperatures) and a filtering option for band. This is a specific verb-resource pair that distinguishes it from siblings like daily_snow or conditions, which focus on different time granularities. The mention of 'the granularity a trip is actually booked at' adds purpose context.

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

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

The description implies usage for trip planning by noting the granularity at which trips are booked, but it does not explicitly state when to use this tool versus alternatives like daily_snow or snow_forecast. It also does not provide exclusions or conditions under which another tool would be preferable. The band filtering is described, but no guidance on selecting this tool over others is given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: the data is measured (not forecast), spans ten winters, and covers specific metrics and elevation bands. However, it does not reveal details like units, whether values are averages, or how month=0 behaves, which the agent would need for interpreting 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 sentences with no filler. The first sentence front-loads the core value proposition and data scope; the second cleanly specifies the optional filter. Every phrase contributes, and the structure is immediately scannable by an agent.

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

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

For a two-parameter tool with no output schema, the description adequately specifies the inputs (resort, optional month) and the nature of the results (typical snow, snow days, day/night temps, elevation bands). It stops short of giving exact response formatting or units, but the invocation requirements are clear enough for a correct 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 description must compensate. It does clarify that month is an optional 1-12 filter, which adds meaning beyond the bare integer type. However, it does not explain the default value 0 or explicitly define that resort must identify a single resort, leaving some semantics to the schema's field names 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 clearly identifies the tool's purpose: providing ten winters of measured historical snow and temperature data for a specific resort, broken down by month and elevation band. It is distinct from siblings like snow_forecast or daily_snow, though it does not explicitly name them. The use-case phrase 'is February reliable here' reinforces the historical, climatological scope.

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 a clear context for when this tool is appropriate: answering questions about historical reliability and typical conditions for a resort. It does not name alternatives or state when not to use it, but the 'history' framing and the explicit optional month filter imply it is for seasonal/climatological queries rather than current conditions or forecasts.

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 destructiveHint=false, so safety is covered. The description adds useful behavioral context: newest-first ordering, each note carries the day it describes, and notes are editor-reviewed human accounts rather than raw measurements. This goes beyond the annotation baseline and helps the agent treat the output appropriately.

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 moderately long but front-loaded with the core purpose and then adds usage guidance and warnings. There is minor redundancy between 'what people who were actually there wrote' and 'somebody's own sentence about their own day', but overall every sentence contributes orientation or usage context.

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 two parameters and no output schema, the description covers the kind of content returned, ordering, and how to interpret it. The main missing pieces are explicit parameter documentation (especially limit) and a more concrete statement about the response shape, but these are low-stakes gaps given the simplicity and read-only annotation.

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 only implies the resort parameter through 'about a resort' and is silent about the limit parameter, its default, or how the limit affects the returned list. This leaves the agent to guess at the meaning of half the tool’s parameters.

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

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

The description clearly states the tool returns skier-written short notes/reviews about a resort, newest first, each tied to a day. It explicitly distinguishes this from models/measurements by calling it 'the one lane on Skinow that is not a model and not a measurement', which separates it from siblings like conditions and snow_forecast.

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 gives explicit use cases: 'queues, beginner-area ice, bus actually ran' – the things no forecast holds. It also warns not to present the notes as conditions. It does not name an alternative tool, but the contrast with forecasts and measurements is clear enough for an agent to route correctly.

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 destructiveHint=false. The description adds useful behavioral context by outlining exactly what the forecast includes: per-elevation-band snow, ensemble range, temperatures, freezing level, 48h hourly details, and storm context, which goes beyond simple read-only status.

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 dense sentence with no filler. It front-loads the core purpose and then lists the forecast components in a compact, scannable way.

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 adequately enumerates the major return components. It could be slightly more explicit about overall response shape, but for a read-only forecast tool with one parameter, the provided detail is sufficient for an agent to invoke and interpret the tool correctly.

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

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

The schema only provides the parameter name 'resort' with no description. The description compensates by explaining that the value is a slug from find_resorts, giving the agent a clear source and format for the parameter.

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

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

The description clearly states that this tool provides a full 10-day forecast for a single resort, with explicit details like elevation bands, daily snow in cm, ensemble range, temperatures, freezing level, hourly detail, and storm context. This differentiates it from siblings such as conditions and daily_snow by specifying the forecast horizon and data granularity.

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 tells the agent to use a slug from find_resorts, which is important usage guidance. It implies this is for one resort's detailed forecast, though it doesn't explicitly name alternative tools or conditions under which to prefer them.

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 description goes well beyond the annotations by disclosing the confirmation email flow: nothing is created until the link is opened, and a wrong or unwanted address leads to no watch, no account, and no record. This adds important side-effect and consent details that annotations do not convey.

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

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

The description is longer than minimal but every sentence serves a purpose: the first sentence states the core action, the second covers consent and confirmation, and the last explains the parameter and the sibling alternative. There is slight redundancy around 'nothing created' and 'no record', but it reinforces an important privacy behavior without being wasteful.

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 three parameters, no output schema, and mutation side effects, the description covers the main operational concerns: what the tool does, how to obtain the email, the confirmation behavior, the cm threshold, and the alternative tool. It does not describe the immediate return value or failure behavior, but those are secondary given the detailed consent and side-effect 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?

Schema description coverage is 0%, so the description must compensate. It explains `cm` with range and default semantics (5-100, house bar 20 cm) and clarifies that `email` must come from the user with consent. `resort` is implied as the mountain being discussed, though not formally spelled out, which is a minor gap.

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

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

The description states a specific action ('Set a standing powder alert up') for a specific resource (the person being talked to, using their email, for a mountain), with a clear outcome: emailing them when that mountain is forecast a real dump. It also distinguishes itself from sibling watch_resort by contrasting the address-based flow with a link-based flow.

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

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

The description explicitly says to ask the person for their email address in their own words and only pass it if they consent to being emailed. It also names the exact alternative, watch_resort, and gives the condition for using it instead: when you would rather hand a link than ask for an address.

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

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

Beyond the annotations, it discloses async behavior ('allow a minute or two'), side effects ('updates the plan, may rework the research'), where results land (requirements, skym_says), and conversation visibility via claim_url. This is substantial behavioral context that annotations alone do not provide.

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

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

Dense but efficient: the first clause states the purpose, and the remaining sentences add async behavior, result locations, and conversation visibility without fluff. Every sentence earns its place.

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

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

Behavior and result locations are well covered despite no output schema, and the polling instruction adds important operational guidance. However, the required `grant` parameter is unexplained, and the description assumes familiarity with concepts like `requirements.inputs.question` and `skym_says`, which may not be obvious to an agent.

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 compensate, and it does richly explain `message` content. However, the required `grant` parameter is never explained, `lang` is not mentioned, and no explicit mapping of parameters is given. This leaves a required invocation field opaque.

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 ('Speak to Skym inside a planned trip') and enumerates concrete request types: answer `inputs.question`, correct an assumption, or ask for a rework. This clearly distinguishes it from siblings like plan_trip and trip_status by tying it to an ongoing trip conversation.

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?

Provides clear usage context: only inside a planned trip, one message per turn, and poll trip_status afterwards. It does not explicitly name alternatives to avoid, but the trip-scoped examples and the explicit routing to trip_status are strong guidance.

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

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

Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral context: it highlights that bed prices are modelled, that modelled-vs-measured flags are included, and that sources are provided. This gives the agent useful caveats beyond the schema and 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 a single dense sentence that efficiently conveys the input scope, key output metrics, and data-quality flags. Every phrase adds information, and there is no redundant or filler content.

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

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

For a one-parameter read-only tool with no output schema, the description covers the main return values: lift pass cost, bed price per person/night, sources, and modelled-vs-measured flags. It is largely complete, though it does not specify currency or the exact meaning of the flags in more detail.

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 compensates by specifying that 'country' should be an ISO-2 code. This adds real meaning beyond the bare 'Country' string field, though it stops short of giving examples or format clarifications such as uppercase/lowercase.

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 reports ski-week costs for a single country, including median 6-day adult lift pass and modelled bed price. This is specific enough to distinguish it from condition, booking, and route-focused siblings, though it does not name an alternative explicitly.

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 about when to use this tool versus alternatives such as plan_trip, booking_options, or where_to_ski. The intended use can be inferred from the cost-focused wording, but explicit when-to-use or when-not-to-use guidance is absent.

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 description goes well beyond the annotations by detailing state-dependent behavior, instructing that entry_urls must be 'presented exactly as given' and that booking navigation should occur 'on the user's behalf.' It also mandates re-showing claim_url to the human, which is critical behavioral context not captured by readOnlyHint, openWorldHint, or destructiveHint.

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 front-loaded with the core purpose and then efficiently conveys conditional outputs and action rules. It is somewhat dense, but every clause earns its place and no content is redundant with the schema or annotations.

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

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

The description covers both output states, the handling of entry_urls, and the claim_url requirement, which is substantial given no output schema. However, it omits guidance on what grant is, how to handle polling intervals or errors, and what status/eta values may look like, leaving meaningful gaps for a tool with sparse structured metadata.

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

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

Schema description coverage is 0%, and the description does not explain what trip_id or grant mean or how to obtain them. While trip_id is somewhat inferable from 'planned trip,' grant is entirely opaque and could prevent an agent from correctly constructing the call.

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

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

The description opens with a specific verb and resource: 'Poll a planned trip.' It further clarifies the purpose by describing two distinct response states (while research runs vs. once delivered), which distinguishes it clearly from siblings like plan_trip, booking_options, and trip_costs.

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 when to use the tool through temporal cues like 'While research runs' and 'Once delivered,' so an agent can infer it is used to monitor an in-progress planning flow. However, it does not explicitly name alternatives or state when not to use this tool versus siblings such as trip_costs or open_booking.

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 provide idempotentHint=true and destructiveHint=false, but the description adds valuable behavioral context: no email is collected by the tool, it returns a URL with the alert preselected and the form open, and the URL must be presented exactly as given. This clarifies that the tool does not create the alert itself and gives practical handling instructions.

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 front-loaded: the first sentence states the core purpose, the second gives the usage trigger, and the final block covers exclusions and URL handling. Every sentence earns its place, including the rationale for not taking the user's email, which helps the agent understand the intended interaction flow.

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 no output schema, the description usefully names the return artifact (`entry_url`) and explains the user completion flow)Skip. The main gaps are that `lang` and the expected format or allowed values for `resort` are not addressed, but for a low-complexity tool the core behavior, trigger, and output are adequately covered.

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 does explain `cm` as the snowfall threshold with a 5-100 range and default 'house bar', and it identifies `resort` as the mountain. However, `lang` is not described at all, and the relationship between the schema default of 0 and the stated 5-100 range is left ambiguous.

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

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

The description opens with a specific, actionable purpose: it 'hands the user a one-tap door' to a standing powder alert for one resort. It clearly distinguishes the watch/alert-signup flow from forecast, conditions, or booking sibling tools, so an agent can tell what this tool does without reading other tool schemas.

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 explicitly says 'Use it the moment snow is the answer' and gives concrete conversational triggers: after mentioning 40 cm on Thursday, or when comparing a quiet week with a better next week. It also draws a clear boundary by stating 'WHAT THIS TOOL DOES NOT DO, deliberately', explaining that it does not collect an email address and instead returns an entry_url.

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 destructiveHint=false, so no additional safety disclosure is needed. The description adds meaningful behavioral context: webcams are provided by windy.com and must be credited, and the result consists of preview image URLs and links rather than embedded streams. 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, each earning its place: the first states the core behavior and output, the second the mandatory attribution requirement. The information is front-loaded and there is no redundant boilerplate.

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

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

For a one-parameter, read-only tool with no output schema, the description sufficiently covers purpose, output format, and external attribution. The main gap is parameter-value semantics and explicit differentiation from resort_media when a photo gallery rather than live webcams is requested.

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

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

The schema has one required string parameter, resort, with 0% schema description coverage. The description only says 'at a resort' and does not explain whether the value should be a resort name, ID, slug, or how to obtain valid values, so it adds essentially no semantic meaning beyond the property name.

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 resource ('live webcams at a resort') and the output ('preview image URLs + links'), while the 'RIGHT NOW' wording conveys that these are current visuals. This distinguishes it from siblings like snow_forecast or conditions, which return forecasts/data rather than live imagery.

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 'RIGHT NOW' framing implies the tool is for current visual conditions, and the licence note indicates the content is external. However, the description does not explicitly say when to choose this tool over resort_media or conditions, nor does it name alternatives, leaving usage routing mostly 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 read-only and non-destructive behavior, so the bar is lower. The description adds beyond that: every ranked row includes a `why` list, presets are 'bundles of published thresholds' not moods, and the output caps at 'Top 20 max.' This gives helpful behavioral detail without contradicting annotations.

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

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

The description is compact for the amount of semantic content it packs. It leads with the purpose, then lenses, then filters, then presets, then output behavior. Nothing feels redundant, and the list style makes dense threshold information readable, though it is on the long side.

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 a high parameter count, zero schema description coverage, and no output schema, this tool does a good job: it covers lens meaning, filter semantics, preset bundles, and row-level output shape. `limit` is under-explained, and a full response-shape example could improve completeness, but the essential calling context is present.

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 carries the full parameter burden. It describes every lens value with a semantic gloss, adds ISO-2 format for country, metres for min_summit, glacier-only meaning for glacier, and gives concrete threshold definitions for most presets. Only the `limit` parameter is not explicitly explained, though the 'Top 20 max' sentence helps.

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 first sentence states a concrete action and resource: 'Rank resorts by live conditions, optionally shaped by who is going.' This distinguishes the tool from sibling tools like find_resorts or snow_forecast, because the emphasis is on ranking by current conditions through selectable lenses and returned evidence rows.

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 the use case clearly: ranking resorts based on live conditions with optional group-shaped presets. However, it never names sibling tools or says when NOT to use it in favor of, say, find_resorts or conditions. With 18 siblings, explicit routing would be valuable.

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