SnowSure — Snow & Ski

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

Beyond annotations declaring readOnly, idempotent, and non-destructive behavior, the description adds meaningful context: the tool is text-only, does not render UI cards, responds in ~1s, and is grounded in SnowSure data. This helps set agent expectations about response format and scope without contradicting the annotations.

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

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

The description is long but front-loaded with the core purpose and then organized into use-case categories, examples, and exclusions. Each section earns its place given the tool's broad Q&A nature and the large sibling tool list, though it could be tightened slightly.

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

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

With an output schema present, a 6-parameter fully-documented input schema, and strong annotations, the description still adds important routing information, exclusions, latency, and grounding context. It is complete enough for an agent to select and invoke 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 description coverage is 100%, so parameters like question, format, locale, and resortSlug are already well documented. The description adds usage context and example questions but does not provide additional parameter-level semantics beyond what the input schema already states.

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 defines the tool as 'Text-only Q&A grounded in SnowSure data' and enumerates concrete use cases like El Niño outlooks, head-to-head resort comparisons, and season-opening norms. It also explicitly distinguishes itself from siblings by directing photo requests to get_resort_photos and guide cards to get_resort_info.

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

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

The description provides explicit when-to-use guidance with many examples and clear exclusions ('NEVER use for photo/gallery/picture requests... or resort guide cards'), including named alternative tools. It also mentions when specialized El Niño tools are appropriate instead.

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 adds significant behavioral context beyond the annotations: it discloses that the tool never charges, that payment completes externally on LUXSKI, that it holds the rate, and that it attributes the booking. It also clarifies the OAuth requirement and the prebooking side effect. These details meaningfully inform an agent about what actually happens when the tool is invoked.

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, front-loaded with the core purpose, and every sentence adds necessary information. It explains both modes, the OAuth requirement, and the external payment flow without repetition 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 7-parameter tool with high schema coverage and an output schema, the description is complete enough for correct invocation. It covers the essential mode switch, the user-auth prerequisite, and the external-payment side effect. Nothing critical is missing for an agent to decide when and how to call this tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how combinations of parameters change behavior: hotelName + checkIn + checkOut triggers prebooking, while omitting them yields availability. This conditional semantics is not fully captured by the individual parameter descriptions and helps an agent assemble valid calls.

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: it returns lodging availability and a booking link, or prebooks a live rate for a specific hotel and returns a LUXSKI checkout URL. It uses action-oriented language ('PREBOOKS', 'returns') and differentiates itself from the many read-only sibling tools by framing this as a user-specific booking action via LUXSKI.

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

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

The description explicitly states the two operating modes: with hotelName + checkIn + checkOut it prebooks, without those it returns availability and a booking link. It also specifies a prerequisite (SnowSure OAuth token). It does not name alternative sibling tools, but the conditional logic itself gives clear guidance on when to call this tool and what inputs trigger each behavior.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context beyond annotations: it warns that 'the model table and days 8–14 need SnowSure Pro, or a favourite resort when signed in; otherwise this returns the seven-day blend alone.' This discloses paywall/auth-dependent output changes, which is exactly the kind of behavior an agent needs to know and is not present in 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?

Three sentences, each earning its place: purpose, usage, and the paywall condition are all front-loaded and tightly written. No filler or redundant detail.

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 comparison tool with an output schema present, the description covers the essential context: the exact models compared, what the output shows (agreement, uncertainty), the intended use case, and the critical restriction on accessing full model data without Pro. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, with both `slug` and `resort` already documented as 'Resort slug or name...'. The description only says 'for a resort' without adding any extra meaning about parameters, so the baseline of 3 applies. It neither adds nor undermines schema-provided semantics.

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

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

The description states a specific verb and resource: 'Compare snow forecasts across 7 weather models... for a resort.' It goes beyond a generic action by naming the exact models and the unique value ('shows model agreement and uncertainty'), which clearly differentiates it from single-forecast siblings like get_weather_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?

The phrase 'Use for forecast reliability queries' gives explicit when-to-use context. However, it does not name any alternative tool or state when not to use this tool versus, say, get_weather_forecast or get_snow_report. The guidance is clear but lacks explicit sibling differentiation.

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=true, idempotentHint=true, destructiveHint=false, which the description aligns with by describing a comparison operation. The description adds behavioral context (e.g., 'which pass covers them and whether it beats buying window lift tickets') beyond annotations, though no detailed edge cases are mentioned.

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: first states purpose with an example, second provides optional parameter usage. Front-loaded with the most critical information, 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 tool with 4 optional parameters and an existing output schema, the description adequately explains the core functionality, usage scenario, and how inputs affect outputs. No gaps identified.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by showing how parameters interact in a meaningful example (e.g., passing resortSlugs and tripDays to see coverage and value), which clarifies the intended use beyond the schema's individual descriptions.

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 compares ski passes on price, resort coverage, and value. It gives a concrete example ('which season pass includes <resort> — Epic or Ikon?'), distinguishing it from sibling tools like compare_resorts or find_pass_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 clear context: 'the tool for...' and instructs to optionally pass resortSlugs and tripDays to get coverage and value analysis. It lacks explicit when-not-to-use alternatives, but the example strongly implies its primary use case.

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 readOnlyHint, idempotentHint, and destructiveHint, so safety is established. The description adds behavioral context by sourcing values from the 'SnowSure conditions resolver/contract' and noting 'live conditions', which implies data freshness. This goes beyond annotations without contradicting them.

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 three sentences with zero filler: it fronts the core purpose, then usage context, then the optional restriction. Every sentence contributes unique value, and the structure is scannable for 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?

Given the output schema exists (so return format is documented elsewhere), annotations cover safety, and the schema fully explains both parameters, the description is complete for proper tool invocation. It covers what the tool does, when to use it, and data provenance—nothing needed for correct usage is missing.

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

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

Schema description coverage is 100% — both `slugs` and `dimensions` are fully described in the schema (including an example for slugs and an explicit list of dimension values). The description adds little beyond restating the optional restriction, so it does not materially enhance parameter understanding beyond the schema.

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

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

The description states a specific verb ('Compare'), a specific resource ('resorts'), and a precise scope ('2–4 resorts side by side across snow, terrain, and live conditions'). It also provides concrete example queries that clarify intent, and clearly distinguishes itself from sibling tools like compare_forecasts and compare_passes by focusing on resort attributes.

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 frames when to use the tool: 'Use for head-to-head stat questions phrased as either/or' with multiple examples. It does not name alternatives or exclusions (e.g., when to use compare_passes instead), but the provided context is clear enough that an agent can infer applicability from the examples and sibling names.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds behavioral value by stating results are sorted by 24-hour snowfall and are current ('right now'), which are not captured in 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 sentences with no wasted words. The primary purpose is front-loaded, followed by the sorting behavior and two concrete use-case queries.

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 list tool with full schema coverage, an output schema, and safety annotations, the description covers the essential purpose, usage context, and sort behavior. No critical information is missing for an agent to decide whether and how to call it.

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

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

Schema description coverage is 100%, and each parameter has its own description. The tool description does not add extra meaning to the parameters beyond what the schema already provides, so the baseline of 3 applies.

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 'Find resorts with the freshest powder snow right now' and specifies the output is 'sorted by 24-hour snowfall.' This goes beyond a generic 'find resorts' and differentiates it from sibling tools like find_resorts_by_criteria or get_snow_report by focusing on real-time freshness and a specific sort order.

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 for "where is it snowing?" or "fresh powder" queries, giving clear context. However, it does not mention when not to use it or name alternative sibling tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the tool returns 'flight-search links' rather than bookings, and it selects 'nearest gateway airport(s)', which explains the underlying logic. It does not describe edge cases like no flights found, but given the strong annotation coverage 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 dense but efficient: it front-loads the core purpose, then gives funnel context, then summarizes args in a compact line. The funnel metaphor is useful but slightly verbose; still, every sentence contributes either purpose, usage, or parameter guidance. It is appropriately sized for a tool with three parameters.

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

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

With an output schema present and annotations covering the read-only/idempotent behavior, the description only needs to carry usage and selection context, which it does well. The main gap is the unresolved ambiguity between the slug and resort parameters, which could confuse an agent about which to pass. Overall, the agent can select and 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 100%, so the baseline is 3. The description adds value by marking the resort argument as required (clarifying logical necessity despite the schema showing no required fields) and by advising use of search_resorts to resolve names. However, it does not explicitly explain the relationship between the duplicate slug and resort parameters, which introduces minor ambiguity.

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

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

The description states a specific verb and resource: 'find the nearest gateway airport(s) and get flight-search links from your home airport.' It differentiates itself from siblings by explicitly labeling itself the 'get there' leg of the funnel and naming find_best_powder/find_powder_trips and book_lodging as the surrounding steps. This leaves no doubt about what the tool does.

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 funnel chain 'find fresh snow → this → book_lodging' explicitly positions the tool in the trip workflow and names its natural alternatives. It also instructs the agent to use search_resorts to resolve a resort name, providing concrete pre-processing guidance. This is clear when-to-use and when-to-use-other-tools information.

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, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, read-only operation. The description adds that the tool returns names and SnowSure slugs, which is useful output context. With strong annotations, the description need not repeat safety info, and it adds value beyond the structured fields.

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 only two sentences, yet it conveys the main purpose, example questions, output details, and chaining hint. Every sentence earns its place, and there is no fluff. The structure is front-loaded with the core action.

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

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

For a tool with only 2 parameters, no enums, and an output schema (not shown but present), the description covers everything: what it does, when to use it, what it returns, and how to chain it. It is fully informative without being verbose.

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?

Input schema coverage is 100%, with both parameters having descriptions. The description adds semantics by explaining that the passId is like 'ikon-pass' and that region is an optional filter that matches the pass's region labels. This provides context beyond the schema's basic descriptions, such as example values and usage patterns.

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

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

The description uses specific verbs ('List', 'answers') and clearly identifies the resource ('resorts on a ski pass'). It provides example questions that agents might ask, making the purpose unmistakable. It distinguishes from sibling tools like get_pass (which gives pass details) and compare_passes (which compares passes) by focusing on listing resorts on a single pass.

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

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

The description provides explicit use cases ('is <resort> on the Ikon Pass?' and 'what resorts does the Epic Pass include') which tells the agent when to invoke this tool. It also hints at chaining by noting that it returns SnowSure slugs that can be passed to get_resort. However, it does not explicitly state when NOT to use it or compare with siblings, which would push it to 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that each hotel carries a booking link and that booking completes on LUXSKI, clarifying that the tool itself does not perform bookings but returns links. 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 moderately concise, containing marketing-like phrasing and a few redundant elements (e.g., 'bookable' and 'booking links'). However, it is well-structured with clear examples and filter explanations, and it avoids unnecessary detail.

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 fully captures the tool's core functionality, expected output (ranked resorts with hotels and links), and relevant context (14-day forecast, booking completion on LUXSKI). It is sufficient for an agent to understand when and how to use the tool without missing critical 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 schema descriptions already cover all parameters (100% coverage), but the description adds clarity about the default behavior of the vibe filter (showing both Lux and Hip when no filter is applied) and provides context on how limit and region affect results. This goes beyond the schema but not extensively.

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 ranks resorts by 14-day forecast and returns handpicked hotels with booking links, distinguishing it from siblings like find_best_powder or book_lodging. It includes a specific purpose: 'where to go AND where to stay' for powder trips.

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 lists example queries and the intended use case: 'Use for "where should I book for powder"...' It provides guidance on optional filters (vibe, limit, region) and implies when this tool is appropriate compared to alternatives.

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, destructiveHint, and idempotentHint. The description adds context about filtering criteria (snow depth, elevation, etc.) but does not disclose additional behavioral traits beyond what annotations 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 two sentences, front-loads the purpose, and contains no wasted words. 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?

Given that output schema exists and annotations cover safety, the description is largely sufficient for a filter tool. It could mention that all parameters are optional, but schema already indicates no required parameters.

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

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

Schema coverage is 100%, so baseline is 3. The description lists some parameter examples from the schema but does not add new meaning or explain parameter interactions or format.

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 finds resorts matching criteria like snow depth, elevation, runs, and SnowSure rating. It distinguishes this from sibling tools like get_resort (single resort) and search_resorts (likely broader search) by emphasizing 'advanced filtering for trip planning.'

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 with filters but does not explicitly state when to use it versus alternatives like search_resorts or find_pass_resorts. There is no mention of exclusions or specific contexts.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context: data is relayed from an official warning service, includes issuer and link, returns 'no bulletin' for missing/off-season services, and explicitly warns against using it as a substitute for official bulletins or training. No contradictions with annotations.

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

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

The description is two sentences with zero waste. The first sentence immediately states the core function and scope, followed by the fallback behavior and a safety disclaimer. Front-loaded and efficiently structured.

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, the description covers the essential context: source, fallback behavior, geographic limits, and safety caveat. The output schema handles return structure details. It could mention update frequency or delay, but that is minor. Overall well-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?

The input schema fully documents both parameters (slug and resort) as equivalent aliases with 100% coverage. The description adds no parameter-specific meaning, so the baseline of 3 applies—the schema handles the semantics.

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 precisely states the tool's function: retrieving a current avalanche danger bulletin for a resort's forecast zone, with specific geographic scope (US, Canada, Switzerland) and the source (official warning service). It clearly distinguishes this from other resort info tools like get_snow_report or get_weather_forecast by topic.

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 avalanche bulletins but does not explicitly state when to choose this over siblings or provide exclusions. The 'NOT a substitute' line is a safety disclaimer rather than routing guidance. No alternatives are mentioned, so an agent must infer when this is the right tool.

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 readOnlyHint=true and idempotentHint=true; the description adds that it returns 'a table of member ski areas', giving behavioral context beyond the schema/annotations. No contradictions.

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

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

Two sentences with zero waste. The first sentence states purpose and examples; the second provides usage guidelines with alternatives. Every sentence earns its place.

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

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

The tool has an output schema, so return values need not be explained. The description covers purpose, usage constraints, and sibling differentiation. Complete for a read-only list tool.

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

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

Schema description coverage is 100% (both slug and limit have descriptions). The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description starts with 'Multi-mountain destination hub' and explicitly lists example hubs, clearly stating the tool's verb (get) and resource (destination hub). It distinguishes from siblings 'get_resort_photos' and 'get_resort_info' by naming exact conditions.

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 tells exactly when to use: 'Use ONLY when the user names the hub itself'. It provides explicit when-not and alternatives: 'NOT for photo gallery (→ get_resort_photos on a specific mountain slug) and NOT for resort guide cards (→ get_resort_info)'.

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?

With readOnlyHint=true and idempotentHint=true annotations already establishing a safe read profile, the description adds meaningful context: the data source (SnowSure's fleet table), the 30-year window, and the tier semantics (A prime / B favored / C ENSO-proof / D late bloomer / E timing play). 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: first states the result, second details filters, third gives usage examples. Every clause adds value, 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 filter tool with 0 required params, a present output schema, strong annotations, and 100% schema coverage, the description fully complements the available context. Nothing material is missing.

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

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

Schema coverage is 100% with tier, limit, and region all documented, so the baseline is 3. The description reinforces region values and explains tier letters, but adds little beyond the schema's own descriptions.

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?

"Ranked El Niño ski resorts from SnowSure's 30-year fleet table" uses a specific verb+resource pair followed by the exact filter dimensions (region, tier). This clearly distinguishes it from siblings like get_elnino_signal or get_regional_summary.

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

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

The 'Use for' clause gives concrete example queries ('best El Niño resorts in Europe', 'is El Niño good for the Alps'), making when to use the tool very clear. It lacks explicit when-not-to-use guidance or named alternatives, but the usage context is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context beyond that: it discloses the small sample size ('n=3 disclosed'), the interpretive caveat ('A pattern, not a promise'), and the nature of D/E tiers as timing plays. It also specifies that the output includes a methodology note and an in-season scorecard when live, which clarifies data freshness. This is valuable added transparency without contradicting annotations.

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

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

The description is three sentences and efficiently packs the essential information: what it does, what it returns, when to use it, and a caveat. It front-loads the core purpose and output list, with the usage rule and caveat following. It is not overly verbose for the amount of content it conveys, though the list of outputs is a bit dense. Overall well-structured and appropriately sized.

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

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

The tool has an output schema, so return structure is already defined. The description supplements with specific output elements (rank, tier, analog winters, forecast paragraph, methodology note, scorecard) and includes important caveats about data limitations (n=3, pattern not promise). For a read-only, idempotent tool with a clear usage rule and output schema, the description is sufficiently complete for an agent to decide when and how to use it.

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

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

Schema coverage is 100% — both slug and resort are fully described in the input schema, so the agent already knows their meaning and format. The description only refers to 'a named resort', which reiterates that the parameter identifies a resort but adds no new semantics beyond the schema. With complete schema coverage, the baseline of 3 is appropriate.

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

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

The description states a clear, specific purpose: it returns a resort-level El Niño/ENSO outlook from a defined dataset (SnowSure's 30-year fleet, 559 resorts). It lists the concrete outputs (rank, tier, signals, analog winters, forecast paragraph, methodology note, scorecard), which precisely defines the tool's scope. It distinguishes from siblings by explicitly targeting 'a named resort', which separates it from the ranking-oriented get_elnino_rankings.

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

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

The description gives an explicit usage rule: 'Use for ANY El Niño, ENSO, or 2026-27 winter-outlook question about a named resort.' This clearly tells an agent when to invoke this tool. However, it does not explicitly mention when not to use it or name alternative sibling tools (e.g., get_elnino_rankings for fleet-wide rankings), so it lacks explicit exclusions, but the context strongly implies the distinction.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds valuable context: insights are narrative cards, hemisphere-scoped, and the last_season category provides comparisons to a 5yr norm. This enriches the agent's understanding of output behavior beyond what annotations 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 four sentences, no filler. It front-loads the core purpose in the first sentence, then provides category-specific advice and sibling differentiation. Every sentence earns its place, making it very efficient for an agent to parse.

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

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

Given the tool has an output schema (so return structure is documented elsewhere) and 4 optional enums, the description covers usage intent, scope (hemisphere-scoped), differentiation from a key sibling, and category-specific tips. It doesn't repeat schema details and is fully adequate for the agent to decide when and how to invoke this tool.

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

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

With 100% schema description coverage, the baseline is 3. The description adds meaning by explaining when to use specific parameters: e.g., 'last_season category is the one to reach for on retrospective questions' and 'Filter by category or insightType=intelligence to skip simple leaderboards.' This helps the agent decide which parameter values to pick for different intents.

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 retrieves 'categorized SnowSure intelligence insights (not just snow totals)' and distinguishes itself from siblings by explicitly saying when to use get_season_leaderboard instead. It lists specific categories (last_season, model accuracy, dry spell) and describes the output format as 'hemisphere-scoped narrative cards', leaving no ambiguity about what the tool does.

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

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

The description provides explicit guidance: 'when the question names a specific state, province, country or region and wants a ranked list, use get_season_leaderboard instead.' It also recommends using insightType=intelligence to skip leaderboards and suggests the last_season category for retrospective questions. It could be improved by noting other sibling tools to avoid, but the guidance given is clear and actionable.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that this is a 'public REST API', implying no auth required and free access, which is a behavioral trait beyond the annotations. No contradictions.

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

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

The description is a single paragraph that front-loads the purpose, then lists datasets, then gives usage guidance and alternatives. Every sentence is substantive; there is no fluff. It is both concise and well-structured.

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

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

Given the complexity (10 parameters, 13 dataset options, output schema exists), the description covers all critical aspects: what the tool does, how to start, dataset scope, dependencies, and when to choose alternatives. It is complete for an AI agent to use 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 description coverage is 100%, so baseline is 3. The description adds value by explaining usage patterns: 'Start with dataset=catalog', 'score_components needs slug', and 'leaderboards read CURRENT-season counters'. This goes beyond the schema's parameter descriptions.

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

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

The description starts with a specific verb+resource: 'Fetch SnowSure-unique ML/AI trend datasets from the public REST API.' It clearly distinguishes from siblings by name-dropping get_season_leaderboard and get_insights, and explains when to use each. No ambiguity.

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 tells the AI to start with dataset=catalog, explains that leaderboards are global and current-season only, and directs to get_season_leaderboard for past or filtered rankings and get_insights for narrative cards. This is comprehensive guidance on when to use this tool vs alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds valuable behavioral context: months with insufficient history are withheld, and returned months carry yearsTracked for evidence. This goes beyond annotations and helps set expectations about data completeness and reliability.

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

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

The description is well-structured and front-loaded: purpose, metrics, use cases, caveats, and alternatives each have a clear sentence. While longer than minimal, every sentence earns its place and directs the agent to correct invocation and expectations.

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 data source, time range, output contents, typical use cases, non-forecast status, alternative tools, and data-quality caveats. With an output schema present and annotations covering safety, nothing needed for correct invocation or interpretation appears missing.

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

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

Schema description coverage is 100% and both parameters (slug and resort) are sufficiently documented in the schema. The description does not add extra parameter semantics, but it does not need to since the schema carries the burden. Baseline 3 is appropriate.

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

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

The description states a specific purpose: typical snow for a resort month by month, from ERA5 reanalysis, and lists the specific metrics returned. It clearly distinguishes itself from siblings like get_weather_forecast and get_resort by explicitly positioning itself as historical climate data.

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 when to use this tool ('date-choosing questions') with concrete examples, and explicitly says what it is NOT for ('HISTORY, not a forecast and not a prediction'). It names alternative tools for those cases, leaving no ambiguity about tool selection.

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

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

Annotations already provide readOnlyHint and other safety hints. The description adds that the tool requires OAuth authentication and ranks resorts best-first with freshest snow on top, providing behavioral context 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 two sentences, front-loaded with the core purpose, and includes the authentication requirement. Every sentence adds value, and there is no redundancy.

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

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

Despite zero parameters, the description fully covers what the tool does, for whom, the required authentication, and the ranking logic. The presence of an output schema means return values are covered elsewhere, so completeness is excellent.

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

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

There are 0 parameters, so the baseline is 4. The description does not need to explain parameters, and no schema descriptions are required.

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 provides a personalized snow report for the signed-in user's saved resorts, including live conditions and ranking. It distinguishes itself from siblings like get_snow_report (general) by specifying personalization and user-specific 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 explicitly mentions the requirement for a SnowSure user access token (OAuth), which is a key usage condition. The personalization aspect implies it should be used when the user wants their own saved resorts, but it does not explicitly compare with alternatives or state when not to use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond those: the 48-hour validity window, the Open-Meteo data source, and the critical epistemic caveat that this is modeled guidance, not the resort's authoritative decision. 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 sentences with zero waste, front-loaded with the hook question 'Will the lifts run?' Each sentence earns its place: the estimate scope, the risk factors, and the cautionary caveat. Efficient and well-ordered.

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

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

With an output schema present and annotations covering the safety profile, the description covers all essential semantics: time window, included factors, data source, and authority caveat. Minor omissions like forecast update cadence or when the 48-hour window starts don't hinder correct invocation.

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

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

Schema description coverage is 100% — both `slug` and `resort` are fully documented in the schema itself. The description adds no parameter-level detail, but the baseline of 3 applies because the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Will the lifts run?' / '48-hour operating-risk estimate') and enumerates the concrete risk factors (wind-hold gusts, visibility, wind-chill, heavy-snow). This specificity clearly distinguishes it from siblings like get_weather_forecast and get_avalanche without opening their 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?

Gives clear usage context — a 48-hour modeled estimate — plus an explicit when-not: 'NOT the resort's own operating decision — always check live lift status.' It steers the agent toward live-status verification but never names a specific sibling alternative, so it stops short of fully explicit routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds concrete return fields (operator, pricing, regions, buy link), which enriches behavioral understanding. No contradictions 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 one efficient sentence, front-loading purpose and listing key outputs. It is concise but could be slightly shortened by removing the ellipsis or examples.

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

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

The tool is simple (1 param, output schema exists). The description covers the return content adequately. No discussion of errors or special conditions, but annotations and schema fill most gaps. Slightly better examples could help.

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

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

Schema coverage is 100% with a clear description for the single parameter 'passId'. The tool description does not add extra semantic value beyond the schema, so baseline score of 3 applies.

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 details for a multi-resort ski pass, listing specific fields (operator, pricing, regions, link). It distinguishes from siblings like 'compare_passes' and 'find_pass_resorts' by focusing on a single pass's details.

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 getting pass details but does not explicitly state when to use this tool over alternatives like 'compare_passes' or 'find_pass_resorts'. No exclusions or alternatives mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: reels are returned newest-first and include watch links. This goes beyond the annotations without contradicting them.

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, no filler. The first sentence front-loads the purpose and value proposition; the second gives use cases and output ordering. Every word 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?

With an output schema present, the description does not need to detail return fields. It covers what the tool does, when to use it, and what to expect (newest-first, watch links). The tool has only optional params, so the agent has enough to decide and call 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 description coverage is 100%, so all four parameters already have clear descriptions in the schema. The description adds no additional parameter semantics beyond the schema, such as format details or relationships. It meets the baseline for high coverage but does not elevate it.

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 resource (archived storm timelapses with burned-in accumulation data), names the tool's purpose ('Proof of Powder'), and provides concrete example queries that differentiate it from siblings like get_storm_watch or get_snow_history. The verb is implicit but the noun and scope are crystal clear.

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

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

It explicitly gives example queries ('how much did it snow at X last night', 'show me the storm at Alta') and states 'Use for ... or any request for storm footage / timelapse / receipts.' It does not name alternatives or exclusions, but the examples are strong enough to guide an agent on when to call 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, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds that the output includes statistics and top resorts, complementing the annotations without 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?

The description is a single, well-structured sentence of 18 words. It front-loads the action and scope, efficiently conveying purpose and output content with no redundancy.

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

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

Given the tool's simplicity (two optional params, but at least one required) and the presence of an output schema, the description adequately covers the core functionality. It could explicitly mention that region or country is required, but the schema provides that 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?

Schema coverage is 100% with descriptions for both parameters, so the baseline is 3. The main description only loosely refers to region/country without adding specifics beyond what the schema already provides.

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

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

The description clearly states the tool provides a summary of snow conditions across an entire region or country, including statistics and top resorts. This distinguishes it from sibling tools like get_snow_report (single resort) or compare_resorts (specific comparisons).

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 broad geographical summaries, and the schema emphasizes providing at least a region or country with preference for region on multi-country areas. However, no explicit alternatives or when-not-to-use guidance is given, though context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about the interactive UI nature and what each card produces, including the distinction that card=full returns markdown only. It doesn't contradict annotations and provides additional useful detail.

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 but well-organized, leading with the required card parameter and then breaking out each card type. It uses bullets and examples effectively. While slightly long, every sentence contributes value, and the structure makes scanning easy.

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

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

Given the enum with four distinct modes and two alternative parameter names, the description covers everything an agent needs: when to use each card, what it returns, and how to route to sibling tools. The output schema handles return details, so no critical information is missing.

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

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

Schema coverage is 100%, so the schema already describes all three parameters. The description adds meaningful semantics: it explains each enum value in context, provides natural-language triggers, and gives an example slug ('portillo'). This enriches understanding beyond the schema's terse descriptions.

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: 'Single-resort data with a REQUIRED card parameter that picks the interactive UI.' It enumerates the specific card types and what each returns, and explicitly distinguishes itself from siblings by naming get_resort_info and get_resort_photos as preferred alternatives. This makes the tool's role 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?

Provides explicit mapping from natural language requests to the correct card parameter ('Resort guide' → card=guide, 'Photos/gallery' → card=photos, etc.) and details what each card outputs. It also states when NOT to use it by preferring sibling tools when available. No ambiguity remains about when to invoke this tool versus alternatives.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that it returns an interactive sidebar UI card, which is minor but useful context. No contradictions; the description aligns with annotations and adds a bit of behavioral detail beyond them.

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 average but every section earns its place: purpose, required scenarios, examples, exclusions. It is front-loaded with the main purpose and uses bolding for key phrases. Slightly verbose but well-organized.

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

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

With an output schema present, the return format is covered elsewhere. The description covers when to use, what data it provides, alternatives, and exclusions. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100% and both slug and resort are well-documented. The description adds clarity by noting 'Pass either one' and giving an example ('portillo' or 'Portillo'), which is extra semantic value beyond the schema.

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

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

The description states a specific verb (get) and resource (resort guide card) with a clear list of content (elevation, vertical, lifts, runs, skiable acres, etc.). It explicitly differentiates from siblings: compare_resorts for X-vs-Y and get_resort for snow conditions. The 'REQUIRED when' clause plus examples make the purpose unmistakable.

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

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

The description gives explicit when-to-use criteria ('REQUIRED when the user asks for...'), concrete examples, and direct exclusions ('For X-vs-Y stat questions use compare_resorts', 'Do NOT use get_resort'). This fully routes the agent to the correct tool.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds useful behavioral context beyond those annotations: the returned content is an interactive carousel sourced from official SnowSure hero and Sanity gallery images, and it is the designated photo-handling tool rather than a general web search.

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 every clause serving a purpose: what the tool returns, when it is mandatory, and which alternatives to avoid. There is no filler or redundant restating of the title.

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 low-complexity tool with full input schema documentation, an output schema, and strong annotations, the description supplies the missing operational context: when to route to it, what content category it covers, and which sibling tools are inappropriate. Nothing essential is missing.

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

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

The input schema already documents both parameters fully, including examples and the note that either slug or resort can be passed. The description adds no new parameter-level meaning, so the baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description names the specific resource (official SnowSure resort photos), the output (interactive photo gallery carousel), and the exact trigger requests it covers. It also distinguishes itself from sibling tools by explicitly excluding get_destination, get_resort_info, and ask_snowdata for photo requests.

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 states explicitly when this tool is required, including example user phrasings like 'show me photos of Vail/Aspen'. It also gives direct negative guidance: never use web search or inline images, and do not use alternative sibling tools for photo requests.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond that: it is a SnowSure drive call, lists the specific highway data sources by state/province, and notes the authoritative nature of the resort's road status plus links to DOT maps. This enriches the safety profile 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 long but information-dense, starting with the primary purpose and then systematically covering data sources and caveats. Every sentence adds value; there is no filler. It is appropriately detailed for a tool with broad geographic scope, though it could be tightened without losing clarity.

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

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

Given the complexity of multiple data sources and output schema availability, the description covers coverage areas, fallback behavior, and authoritative status. It does not explain the exact output structure, but an output schema exists, so that is not required. The description is sufficient for an agent to decide when to call and what to expect.

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

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

Schema description coverage is 100% and both parameters (slug and resort) are documented as the same resort identifier with examples and mutual exclusivity. The description does not add any new parameter-level detail, so it stays at the baseline of 3 – the schema already handles parameter semantics fully.

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 provides driving access for a resort, answering two specific questions: chain requirements and road openness. It enumerates the exact data sources and geographic coverage, making it unmistakable what the tool does and how it differs from generic travel or weather tools.

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

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

The description implies when to use it: when the agent needs road access or chain-control info for a resort. It explicitly states the coverage areas and the fallback 'no road data' outside them. It does not name sibling tools like get_road_cameras or get_road_weather, but the clear scope lets an agent infer the appropriate alternative, so guidance is strong but 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the description only needs extra behavioral context. It adds valuable behavior: returns 'no road cameras' outside the covered area, includes a live image URL for each camera, and names the data sources. This goes beyond the structured annotations without contradicting them.

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

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

The core purpose and return behavior are front-loaded, and the jurisdictional list is useful for scope. The description is slightly long due to the parenthetical list of data sources, but every part contributes to the agent's understanding of coverage and expected output.

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

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

With a high-coverage schema and an output schema present, the description covers the remaining essentials: geographic scope, the 'no road cameras' fallback, and the live image URL per camera. An agent has enough information to call the tool correctly or decide not to.

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

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

Schema description coverage is 100%, and both `slug` and `resort` are already described in the input schema as interchangeable resort identifiers. The tool description adds no additional parameter meaning beyond the schema, so the baseline 3 is appropriate.

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

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

The description clearly states the tool returns live roadside DOT/CCTV camera stills on highways near a resort, which is a specific verb-resource pairing. It distinguishes itself from resort webcams and lists the covered jurisdictions, so an agent can identify it among many similar get_* tools.

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

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

The description gives clear context: use this when you need live visual road conditions near a resort, not resort webcams. It explicitly says 'Distinct from resort webcams' but does not name the alternative sibling tool or mention when to prefer road-weather/access tools, so it is just short of fully explicit guidance.

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

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

Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description reveals concrete behavioral details: data comes from specific state DOT/RWIS sources, it covers only listed regions, it reports 'no road weather' outside that coverage, and the data is measured rather than modeled. This is exactly the kind of context that helps an agent reason about 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?

The description is a single dense sentence that front-loads the core purpose and data types, then adds provenance and edge-case behavior. The state/agency parenthetical is slightly long but earns its place by defining actual data coverage; nothing is redundant.

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 lookup tool with two self-documented optional parameters and an output schema, the description covers the essential operational context: data categories, data sources, geographic coverage, the no-data result, and the distinction from the modeled alternative. An agent has enough to select and invoke it correctly.

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

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

The input schema already documents slug and resort with examples and notes that either may be used, so description value is limited. The description adds that the weather is 'near a resort' and enumerates coverage regions, which indirectly helps interpret the parameter's meaning, but it does not materially extend the schema's 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?

The description clearly identifies the tool as retrieving measured roadside weather (RWIS) near a resort, enumerates the exact data types (surface/air temperature, visibility, wind, precipitation), and explicitly distinguishes it from the modeled get_operating_risk. This gives an agent a precise, unambiguous understanding of what the tool does.

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 tells the agent this is the tool for measured, on-road sensor data rather than modeled conditions, and names the covered regions and the 'no road weather' edge case. It does not explicitly contrast with other nearby siblings like get_road_access or get_weather_forecast, but the distinction from get_operating_risk plus the geographic qualification provides clear enough usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the tool's safety profile is clear. The description adds useful behavioral context: the data source (ERA5 reanalysis), coverage (full season, not only live days), and historical range (back to 1996). There is 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 well-structured, opening with a clear, front-loaded purpose statement. Every sentence adds value, and it avoids redundancy with the schema. The tooltip-style guidance is efficient.

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

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

Given the tool has 7 optional parameters, an output schema, and full schema coverage, the description is quite complete. It explains scoping, metrics, season resolution, data provenance, and provides sibling alternatives. It is slightly verbose on the scoping list but still within reason.

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

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

Schema description coverage is 100%, but the description adds significant value by explaining how season values resolve, clarifying the metric enum, and providing examples for region and state. It also discloses defaults (metric=total_cm, hemisphere=nh, season=latest, limit=10, worldwide). The only small gap is not detailing the limit parameter's behavior beyond the schema.

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

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

The description clearly states the tool ranks resorts by a season metric, scoped to a place. It uses specific verbs ('rank', 'scope') and explicitly distinguishes the tool from siblings like get_snow_history, get_monthly_snow, and get_snow_report.

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 ('which <place> resort had the most <metric> last season'), and when not to, by naming alternatives: get_snow_history for one resort's history, get_monthly_snow for climatology, and get_snow_report for current conditions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe, read-only operation. The description adds value by clarifying the date-scoped focus and explicitly stating that it returns only 'scheduled or confirmed' openings, not all current openings. This goes beyond the annotations to set proper expectations, though annotations already cover the safety aspects well, so a 4 is appropriate.

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

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

The description is relatively concise—a few sentences—and front-loaded with the main purpose. However, the last sentence is somewhat long and could be broken into clearer usage guidance, making it slightly less crisp than ideal. Still, every clause adds value, so a 4 is reasonable.

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 that the tool has 4 parameters with full schema coverage, annotations that cover safety/idempotency, and an output schema (so return format is documented elsewhere), the description covers the core logic well. It does not need to explain return values. It could add a note about the date default behavior more explicitly, but overall it is complete enough for an agent to use 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 description coverage is 100%, so the input schema already documents all 4 parameters with descriptions. The description does not add any additional parameter-level meaning beyond what the schema provides, hence a baseline score of 3 is warranted.

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 is very specific: it identifies the tool as returning resorts whose opening date is a given day, clarifying exactly what it answers (e.g., 'what opens today?') and what it does not return (all currently-open resorts). This sharply distinguishes it from siblings like get_southern_hemisphere_report, achieving full 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?

The description explicitly states when to prefer this tool ('prefer over get_southern_hemisphere_report for opening-day questions') and when NOT to use it, providing two clear alternatives: use get_insights with category=season_calendar for ranked retrospectives, and ask_snowdata for historical norms. This gives the agent unambiguous decision rules.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context about the historical, aggregate nature of the data and what comparisons are included.

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 compact sentences with no filler. The core output is front-loaded and the scoping caveat is stated efficiently.

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

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

The description, annotations, and output schema together give enough information for an agent to invoke this correctly. The single-resort constraint, alternative tool, and expected content are all 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?

The input schema documents both slug and resort parameters with 100% coverage, including examples and the note to pass either one. The description adds no additional parameter-level meaning beyond reinforcing single-resort scope.

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 the tool returns one resort's snowfall history, including season totals, comparisons to 5- and 30-year averages, and best months to visit. The single-resort scope and explicit contrast with get_season_leaderboard make its purpose clear.

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

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

Explicitly says it is scoped to a single resort and tells the agent to use get_season_leaderboard instead for region-level 'which resort led <metric>' questions. This provides clear when-to-use and when-not-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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the sorting behavior (by SnowSure score, forecast, or recent snowfall) and the 'top-ranked' framing, which is useful context beyond the annotations. It doesn't disclose details like default limit or pagination, but the schema covers the limit parameter and the output schema exists, so a 3 is appropriate.

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

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

Two sentences with zero waste. The core action and resource are front-loaded, followed by the sorting behavior and example queries. Every sentence earns its place.

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

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

For a read-only, idempotent list tool with a fully documented schema and an output schema, the description is nearly complete. It covers what the tool returns (top-ranked resorts by snow conditions), the sort options, and example use cases. It doesn't mention the default limit or max value, but the schema already documents those, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (sort, limit, region) with descriptions. The description adds the notion of 'top-ranked resorts' and mentions the sort options, but it doesn't add meaning beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description states a specific verb ('Get'), a clear resource ('global snow report'), and the key behavior (top-ranked resorts by snow conditions, sorted by SnowSure score, forecast, or recent snowfall). It also includes example user queries ('where has the best snow?', 'top ski resorts right now'), which helps an agent recognize when to invoke it. This clearly distinguishes it from siblings like get_my_snow_report or get_regional_summary.

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

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

The description provides explicit example queries that signal when to use this tool ('where has the best snow?' or 'top ski resorts right now'). It does not explicitly name alternatives or state when not to use it, but the query examples plus the global scope give clear context. Sibling tools like get_my_snow_report or get_regional_summary are implicitly differentiated by the global scope.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is well-covered. The description adds value by stating the tool 'Prefers operator-verified data when available,' which is a useful behavioral trait not captured in annotations. The description is fully consistent 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 front-loaded with the core purpose and example queries, then branches into usage guidelines and exclusions. Every sentence earns its place, but the description is somewhat long (6 sentences) and could be tightened slightly. The structure is logical and clear.

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

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

Given the tool has 3 optional parameters, 100% schema coverage, an output schema, and rich annotations, the description is complete. It covers geographic scope, seasonal context, example queries, alternatives, and even edge cases about NH summer glaciers. No gaps remain for an agent to use 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing context for the 'sort' parameter (AI score, 24h snow, base depth) and explaining the default limit. It does not, however, detail the output schema or explain how the country filter interacts with the tool's geographic scope.

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

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

The description uses a specific verb ('Get') with a clear resource ('snow conditions for Southern Hemisphere ski resorts') and explicitly lists the countries (Australia, New Zealand, Argentina, Chile). It distinguishes itself from the 43 sibling tools by providing concrete example queries and noting when to use get_season_openings instead.

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

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

The description provides explicit usage guidance: use for June–October SH ski queries, provides a specific sibling tool to not use (get_season_openings for opening dates), and even details when to use get_resort for NH glacier summer operations. This is exemplary coverage of when, when-not, and alternatives.

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 readOnly, idempotent, and non-destructive. The description goes further by explaining that the data is forecast-only, that events carry a confidence tier (watching / likely / locked), and that returning no events is the normal state outside a storm cycle. This adds meaningful behavioral context beyond the annotation flags.

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 what the tool returns, then gives example use cases, then explains the forecast/observation distinction and the empty-state behavior. Despite using a few sentences, every sentence adds information an agent needs for correct selection and interpretation; there is 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?

Given the output schema already covers return fields, the description covers the remaining contextual needs: when to use it, what the events represent, what confidence tiers exist, how results are ordered, the forecast-vs-observation distinction, and the normal empty result. The tool is self-sufficient for correct invocation and interpretation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying that 'events' are storm systems spanning multiple resorts, which gives semantic meaning to the limit parameter, and by noting events are ranked biggest first. This is useful context the schema alone does not fully convey.

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

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

The description gives a concrete verb and resource: it returns named multi-day storm systems flagged days ahead, grouped as one event across resorts and ranked by size. It clearly distinguishes this from observation-based tools by explicitly saying FORECAST, NOT OBSERVATION, and by naming get_snow_report and find_best_powder as the alternatives for snow that has already fallen.

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

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

It provides explicit example queries ('is a storm coming', 'what's the next big system', 'where will it dump this week') and explicitly states when not to use it: for snow that already exists, use get_snow_report or find_best_powder. This gives an agent clear routing criteria.

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

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

Annotations already declare readOnly/idempotent/non-destructive; description adds methodology (ERA5 monthly history, day-weighted blending), the window-length cap (31 days), and the behavior for under-5-tracked seasons. The honesty about being history rather than prediction goes beyond the structured metadata.

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; each clause adds information: methodology, outputs, constraints, alternatives, and edge-case return behavior. Front-loaded with purpose and examples, with no filler or repetition of schema defaults.

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?

Covers data provenance, output components, the history-vs-forecast distinction, alternative tools, and edge cases. Since an output schema exists, not detailing return structure is acceptable; nothing an agent needs to invoke it correctly is missing.

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

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

Schema covers all four parameters at 100%, so baseline 3; the description adds the crucial 31-day max constraint and clarifies that input is one resort with a date range. It doesn't restate schema details but elevates the schema's semantics with usage constraints.

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 'Historical odds for a SPECIFIC trip window at one resort' – a specific verb/resource/scope. Examples ('Whistler on March 27') and explicit exclusions ('for the next 14 days use get_weather_forecast') distinguish it from siblings without opening 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?

Explicitly differentiates from get_weather_forecast (next 14 days) and get_monthly_snow (whole-month), and clarifies the tool is history, not forecast/prediction. Also notes the data insufficiency edge case ('return insufficient rather than thin odds'). No ambiguity about when to call 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 establish readOnly, idempotent, and non-destructive behavior. Beyond that, the description adds useful behavioral context: forecasts are day-by-day, the default is 7 days, 14 days requires SnowSure Pro, and the signed-in state can affect behavior via a favourite resort. This is valuable context not present in 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?

A single front-loaded sentence contains the action, key result fields, and horizon. It is concise, but the trailing clause 'or for a favourite resort when signed in' is grammatically ambiguous and weakens an otherwise tight structure.

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

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

With a complete input schema, annotations, and an output schema, most context is already supplied. However, the description leaves the favourite-resort behavior under-specified (how it is selected, whether slug/resort are optional when signed in), and there are no required parameters, which could leave an agent unsure about what to pass.

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

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

Schema description coverage is 100%, so parameters are already documented (days default/max, slug vs resort formats). The description adds only a high-level hint that a favourite resort may be used when signed in, which is not enough to raise it above the baseline for fully covered schemas.

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: 'Get detailed day-by-day weather forecast for a resort', and enumerates the returned fields (temperature, snowfall, wind, conditions) and horizon. It is clearly distinguishable from siblings like get_snow_report or get_road_weather, though it never names a sibling explicitly, so it stops short of a fully differentiated 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 the use case: call this when a day-by-day resort weather forecast is needed. It does not state when to prefer another tool, nor does it give exclusions or alternatives, so guidance is only implicit rather than explicit.

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

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

Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns live links and status, but does not disclose behavioral edge cases such as cameras being offline, unavailable, or requiring special access. It is consistent with annotations and adds modest context beyond them.

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 well-structured sentence that front-loads the core action, then immediately provides concrete example queries. Every phrase earns its place; there is no filler or repetition of the title.

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

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

The tool is simple, has an output schema, and the annotations plus parameter descriptions cover most operational context. The one minor gap is that the one-of requirement for slug/resort is stated in the schema but not reinforced in the description, and the description does not mention camera-availability caveats.

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

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

Schema description coverage is 100%, so the input schema already fully documents slug and resort. The description only reinforces that the tool operates on a resort without adding new parameter-level detail, formats, or precedence rules. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Get live webcam links and status for a resort.' It clearly distinguishes this from siblings like get_road_cameras and get_resort_photos by emphasizing live webcams and named-cam lookups. An agent can understand exactly what this tool returns.

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 concrete natural-language triggers: 'show me the webcam / live cam at <resort>', 'current conditions on camera', and named-cam lookups. This gives clear context for when to invoke the tool, though it does not explicitly state when not to use it or name alternatives like get_road_cameras.

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 indicate readOnly, idempotent, non-destructive behavior. The description adds the authentication requirement (OAuth token), which is additional behavioral context beyond annotations. No contradictions.

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

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

The description is a single sentence with two clear clauses, no extraneous text, and front-loads the main action.

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

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

For a simple tool with no parameters, annotations covering safety, and an output schema (present but not shown), the description is complete. It adds the crucial auth requirement, leaving no ambiguity.

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

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

The tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter info, and the baseline for 0 parameters is 4.

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 lists the signed-in user's alert subscriptions. The verb 'list' and resource 'alert subscriptions' are specific, and the sibling tools 'subscribe_alerts' and 'unsubscribe_alerts' are distinct for creation and deletion, so purpose is well-defined.

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 mentions an OAuth token requirement, but does not explicitly state when to use this tool versus alternatives. Usage context is implied by the name and siblings, but not articulated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral context by noting the categories are 'retrospective and verification-backed cards' and 'lighter than raw leaderboards', offering insights 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?

Two sentences, no wasted words, front-loaded with the main purpose, then usage context. Every sentence is informative.

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 zero-parameter tool with an output schema, the description is complete: it explains what is listed, when to use, and the nature of the data. No gaps remain.

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?

Input schema has zero parameters with 100% coverage. The description adds value by listing example categories, effectively providing context for the output without needing parameter details.

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 action ('List SnowSure insight categories') and resource, and distinguishes it from siblings by mentioning it is used before get_insights and is lighter than raw leaderboards.

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 says when to use ('Use before get_insights to choose a category filter') and contrasts with alternatives ('Lighter than raw leaderboards'), providing clear context.

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

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

The description adds behavioral insight beyond annotations by mentioning the OAuth requirement and the authorization error behavior, which annotations alone do not cover.

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: the first states the purpose, the second adds critical auth context. No wasted words, and the most important information is front-loaded.

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

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

With no parameters and an output schema available, the description covers the purpose, auth requirement, and error handling, which is complete for a simple list tool.

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

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

There are no parameters, so schema coverage is 100%. The description does not need to add parameter details; the context about auth is extra and not parameter-related. Baseline 4 for zero 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 'List the signed-in user's saved resorts' with a specific verb and resource, and it distinguishes from sibling tools like save_resort and remove_saved_resort.

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 specifies the requirement for a SnowSure user access token and explains the error response when missing, providing clear context for when to use the tool.

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 indicate readOnlyHint=true and idempotentHint=true. The description adds significant behavioral context: nearest-neighbor routing, minimal backtracking, day allocation, driving leg estimation, and integration of live conditions and chain control. No contradiction with annotations.

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

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

The description is two sentences: first sentence provides a comprehensive functional summary, second lists arguments. It is front-loaded and efficient, though could be slightly more structured with bullet points for clarity.

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

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

Given the tool's complexity (multi-stop routing, allocation, estimation, live conditions) and the presence of an output schema, the description covers all key behaviors and limitations. It is complete enough for an agent to understand the tool's purpose and operation.

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 67%, so baseline is 3. The description restates parameters ('region (required), days, optional pass.') but does not add meaningful new semantics beyond what the schema already provides for the 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 plans a multi-stop ski road trip, detailing specific operations like picking top resorts, ordering into a drivable route, allocating days, estimating driving legs, and incorporating live conditions. This differentiates it from the sibling 'plan_ski_trip' which likely plans a simpler trip without road routing.

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 a user wants a road trip with routing and conditions. However, it does not explicitly state when not to use this tool versus alternatives like 'plan_ski_trip' or when other trip planning tools are more appropriate.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, making the read-only nature clear. The description adds context about inputs (dates, preferences, conditions) and output (suggests best resorts), but does not reveal additional behavioral traits such as how conditions are evaluated or whether the tool accesses real-time data. It adds moderate value beyond annotations.

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

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

The description is two sentences long, with the first sentence stating the core function and the second providing a slight elaboration. It is front-loaded and concise, though the second sentence is somewhat redundant with the first, making it slightly less efficient.

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

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

Given the existence of an output schema and full input schema coverage, the description provides adequate high-level context. However, with many sibling tools, the description misses the opportunity to clarify the tool's unique value proposition (e.g., it recommends resorts based on conditions, but doesn't distinguish from find_powder_trips). It is complete enough for basic use but lacks depth for distinguishing among alternatives.

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

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

Schema coverage is 100%, so the baseline is 3. The description reiterates that the tool uses 'dates, preferences, and conditions,' which aligns with the schema parameters. However, it does not add meaning beyond the schema's own detailed parameter descriptions. The description is consistent but not enhancing.

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

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

The description uses the specific verb 'Get' and the resource 'ski trip recommendations', and mentions 'best resorts for a given time period.' It clearly states the tool's purpose of providing recommendations based on dates, preferences, and conditions. However, it does not explicitly differentiate from sibling tools like find_powder_trips or compare_resorts, which could overlap.

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 offers no guidance on when to use this tool versus alternatives. It does not specify when not to use it, nor does it mention prerequisites or limitations. The tool's relationship to siblings like find_powder_trips or compare_resorts is unaddressed, leaving the agent to infer usage context.

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

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

Annotations already convey destructiveHint=true and idempotentHint=true. The description adds valuable context beyond those: the OAuth token requirement and the 'signed-in user' scope. This provides the agent with the necessary authorization context and clarifies whose saved list is affected, complementing the annotations without 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?

The description is a single, front-loaded sentence with no filler. Every word earns its place, conveying the action, scope, and a key prerequisite in one clear statement.

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

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

For a simple two-parameter tool with an output schema and annotations covering destructive/idempotent behavior, the description is sufficiently complete. It covers purpose, personal scope, and authentication. The only minor gap is that it doesn't explicitly state at least one parameter must be provided, but the schema already conveys that, so the description need not repeat it.

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

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

Schema description coverage is 100%, so both parameters ('slug' and 'resort') are already well-documented as interchangeable aliases. The description adds no additional parameter-level information, which is acceptable given the schema fully explains semantics; the baseline of 3 applies.

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

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

The description uses a specific verb ('Remove') and resource ('resort from the signed-in user's saved list'), leaving no ambiguity about what the tool does. It clearly distinguishes itself from sibling tools like save_resort and list_saved_resorts by specifying the removal action and the personal 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 context is clear: use this tool when the user wants to unsave a resort from their own list. The auth prerequisite ('Requires a SnowSure user access token (OAuth)') adds actionable guidance. It does not explicitly name alternatives or exclusions, but the action is unambiguous enough that an agent can infer when it applies.

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 not read-only, not destructive, and idempotent. The description adds that it requires a signed-in user access token and that the slug must be real, which are behavioral prerequisites not covered by annotations. This adds value without contradicting the annotation profile.

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

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

The description consists of two short, purposeful sentences: the first states the action and destination, the second gives prerequisites. Every word earns its place, 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 two-parameter tool with an output schema, the description covers the essential usage context (auth, validity) and leaves return-value details to the output schema. It does not mention what happens when both slug and resort are provided, but that is already handled in the schema description. Overall, it is sufficient for an agent to call the tool correctly.

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

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

The schema fully describes both parameters (slug and resort) with examples, so the description does not need to repeat that. The description adds a constraint that the slug must be a real SnowSure resort, which is a useful semantic beyond the schema. However, since schema coverage is 100%, the description's contribution is marginal.

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 'Save a resort to the signed-in user's favorites,' which names the specific verb (save), resource (resort), and destination (favorites). This clearly distinguishes it from sibling tools like remove_saved_resort and list_saved_resorts. The additional constraints make the purpose unmistakable.

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

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

The description gives clear context for when to use the tool: to save a resort to the user's favorites, requiring an OAuth token and a real SnowSure resort. It does not explicitly mention alternatives or when not to use it, but the self-explanatory name and context provide sufficient guidance. It lacks a direct comparison to remove_saved_resort or list_saved_resorts.

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

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

The description states 'Returns matching resorts with basic conditions,' which adds minimal behavioral context beyond the annotations (readOnlyHint=true, destructiveHint=false). The annotations already convey safety, so the description is adequate but not rich in behavioral disclosure.

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 concise sentences: first states purpose, second provides usage guidance. No extraneous words. Information is front-loaded and efficient.

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

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

Given the presence of an output schema and thorough annotations, the description covers the essential behavioral and usage aspects. The tool's purpose, parameters, and query patterns are clearly explained, leaving no gaps for an agent to misinterpret.

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?

All three parameters (limit, query, country) are fully described in the input schema (100% coverage). The description adds no new semantic information beyond what the schema already provides, such as default values or exact formats. Baseline score applies.

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

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

The description uses a specific verb ('Search') and resource ('ski resorts') and provides example queries ('find resorts in [location]' or 'search [name]'), which clearly distinguishes it from sibling tools like compare_resorts, get_resort, or find_resorts_by_criteria.

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

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

The description gives explicit usage patterns ('Use for...') which helps the agent know when to invoke this tool. However, it does not mention when not to use it or compare to alternatives like get_resort for detailed info, leaving some ambiguity.

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 indicate this is a mutation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds context by stating it subscribes the user (a write operation) and requires OAuth. It also explains the behavioral semantics of each alert type (e.g., powder is OBSERVED fresh snow, forecast is a 14-day forecast). This goes beyond the schema and covers the key side-effect profile.

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

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

The description is long but every sentence carries essential information. It front-loads the core action, then systematically explains each type with its specific criteria. The density is justified by the complexity of five alert types and their scope rules. No fluff or redundancy; it could benefit from bullet formatting, but as prose it is efficient.

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?

This is a complete description for a tool with five parameters and complex type logic. It covers all type semantics, scope formats (including pass syntax), channel defaults, threshold meanings for both powder and forecast, and the windowDays range. It also states the OAuth requirement. Since an output schema exists, no need to describe return values. Nothing an agent needs to call it correctly is missing.

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

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

The input schema already covers 100% of parameters with descriptions, but the tool description adds meaningful enrichment: it explains the meaning of each enum value for 'type' (e.g., powder = fresh snow >= thresholdCm, trip = powder trip with curated stay) and details the scope options for trips, including pass syntax. This adds value beyond the schema's generic 'Alert type' description.

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 sentence, 'Subscribe the signed-in user to snow alerts', states a specific verb and object. It then enumerates the five alert types with precise definitions, which clearly distinguishes this tool from siblings like unsubscribe_alerts and list_alerts. The scope semantics for trips are also spelled out, leaving no ambiguity about what the tool does.

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 requires a SnowSure OAuth token, which is a critical prerequisite. It defines when each alert type is appropriate (e.g., powder vs forecast vs trip) and gives constraints such as scope 'any' not being accepted for trips. While it doesn't explicitly say 'use this instead of X', the detailed type/scope rules effectively guide selection among related 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 indicate destructive action and idempotency. The description adds the auth requirement and the source of the id, adding value beyond annotations.

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

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

Two concise sentences, no fluff, front-loaded with the action and source.

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 fully covers the tool's purpose, parameter source, and auth requirement. With an output schema present, no further return info is needed.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context that the id comes from list_alerts, which aids the agent in knowing how to obtain it.

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 'Remove one of the signed-in user's alert subscriptions by id', with a specific verb and resource. It also ties to list_alerts, distinguishing it from subscribe_alerts.

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 indicates the source of the id (list_alerts) and the required auth token, providing clear context. It does not explicitly state when not to use it, but the use case is straightforward.

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