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?

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?

Beyond what annotations convey, it discloses the ~5-minute async duration, the daily slot cost, the polling requirement, and the guest-vs-signed-in ownership semantics. Explaining that claim_url must be given to the human is genuinely useful behavioral context, and nothing contradicts the provided 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 front-load the action, then add timing/cost and the output/action requirement. Every sentence earns its place, and the capitalized instruction 'GIVE claim_url TO THE HUMAN' is an effective, targeted signal.

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 an async mutating tool with no output schema, the description explains the output contract, the polling route, the cost, and the required human handoff. Minor gaps such as what 'grant' actually represents and failure behavior are not critical for tool selection or invocation, but they prevent a perfect score.

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 thoroughly explains the only required parameter, brief, with components and an example, but lang and origin are left semantically unstated. Origin in particular is not self-explanatory despite its default, so the description does not fully carry the load for all 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?

States a clear action and resource: 'Start REAL Skym trip research from a natural-language brief'. The example brief and stated return values (trip_id, grant, claim_url) make the tool's role unambiguous, and the explicit mention of polling with trip_status differentiates it from sibling tools like trip_status and 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?

Provides clear context for when to use the tool: whenever the user gives a natural-language trip brief. It also tells the agent to follow up with trip_status and to pass claim_url to the human. It stops short of explicitly contrasting with alternatives like find_resorts or where_to_ski, so it lacks full when-not guidance.

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

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

The description discloses direct image URLs on skimetric.eu, thumbnail and hero width variants, and a licensing/credit requirement. These behavioral details go well beyond the readOnlyHint and destructiveHint annotations and materially affect how results should be used.

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 with the main purpose front-loaded, followed by URL details and license terms. Every sentence carries distinct information needed to call and use the tool correctly, 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?

For a simple one-parameter read-only media tool with no output schema, the description provides the return form (direct URLs), sizing guidance, and legal handling. Nothing essential to invoking it or presenting results is missing.

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

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

Schema description coverage is 0%, and the description only refers to 'a resort' without specifying the expected identifier format, naming convention, or accepted values. The description does not compensate for the schema's lack of parameter documentation.

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

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

Description clearly states the tool returns pictures for vision-capable agents, specifically approved winter photography and topography circuit renders. It identifies the resource precisely, though it lacks an explicit verb like 'retrieve' and only implicitly distinguishes itself from siblings such as webcams.

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 when an agent needs to show resort imagery or terrain ('so an agent can show its user the terrain'). It does not mention alternatives or when not to use this tool, leaving 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 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. 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?

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 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context like the 'Top 20 max' result cap and the meaning of each lens. It does not describe return shape, ordering direction, or any external data dependencies, but the annotation coverage lowers the burden.

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

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

The description is compact and front-loaded with the core purpose, then lists lenses and filters in an efficient parenthetical style. Every sentence adds useful 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 read-only ranking tool with no output schema, the description provides enough invocation context: purpose, lens options, optional filters, and a result cap. It does not describe the return format or field details, but that is not strictly necessary for selecting and calling the tool successfully.

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 parameters. It compensates well by defining each lens, noting the ISO-2 country format, giving metres for min_summit, and mentioning glacier-only and min_lifts. The limit parameter is only indirectly addressed by 'Top 20 max,' so it does not fully document every 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 names a specific verb and resource: 'Rank resorts by live conditions.' It also lists the available lenses, which clarifies what kind of rankings are provided. However, it does not explicitly differentiate this tool from sibling tools like conditions, snow_forecast, 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 gives clear filter options but no guidance on when to use this tool versus alternatives such as conditions, daily_snow, or snow_forecast. It does not state exclusions, prerequisites, or a decision rule for choosing this ranking tool over its siblings.

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