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?

Despite annotations providing idempotentHint and openWorldHint, the description adds critical behavioral context: 'we never charge', 'we hold the rate + attribute the booking', 'payment always completes on LUXSKI'. It also notes OAuth requirement, going 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 concise at 4 sentences, front-loading the purpose. It could be slightly more structured (e.g., bullet points) but is efficient 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's complexity (two modes, auth, external payment), the description covers all major aspects: what it does, prerequisites, and side effects. Output schema exists, so return values need not be explained.

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% (baseline 3). The description adds meaning by explaining that hotelName+dates trigger prebooking and checkout URL, and that powderEventId is optional for attribution. This enhances understanding beyond schema 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 finds lodging near a resort via LUXSKI for the signed-in user. It distinguishes two modes: with hotelName+dates prebooks and returns a checkout URL, without returns availability+booking link. The verb 'find' and 'prebook' are specific and differentiate from siblings like find_flights_to_powder.

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 explains when to use which mode (with vs without hotelName) and requires a SnowSure user access token. However, it does not explicitly state when not to use the tool or mention alternatives, though it is clear in 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 show readOnlyHint and idempotentHint, but description adds that it shows model agreement and uncertainty, which are behavioral details 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 with front-loaded purpose and clear usage. Every word 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 output schema exists, description fully covers purpose, models, and output nature. No missing behavioral info.

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?

Only one parameter 'slug' with schema description 'Resort slug to compare forecasts for'. Description adds no extra meaning beyond schema; baseline 3 due to 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?

Description clearly states verb 'compare', resource '14-day snow forecasts across 7 weather models', and purpose 'forecast reliability queries'. Distinguishes from sibling tools like get_weather_forecast (single model).

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 'Use for forecast reliability queries.' Implicitly distinguishes from single-model tools but lacks explicit when-not-to-use or direct 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 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the data source ('every value comes from the SnowSure conditions resolver/contract') and mentions 'live conditions', but does not disclose additional behavioral traits such as rate limits or specific side effects.

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 long, with the first sentence front-loading the core purpose. The second sentence is long but packed with useful examples. No unnecessary filler, though it could be slightly more concise by trimming redundant 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?

Given the output schema and annotations, the description adequately covers purpose, usage, and data source. It lacks explicit edge-case behavior (e.g., invalid slugs, too many resorts), but these are not critical for a tool with a clear output schema and annotation safety profile.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (slugs and dimensions). The description adds minimal semantic value beyond the schema—only restating that dimensions are optional ('Optionally restrict to specific dimensions'), which is already in the schema. It doesn't provide new parameter-level insight.

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

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

The description clearly states the tool's function: 'Compare 2–4 resorts side by side across snow, terrain, and live conditions'. It specifies the resource (resorts), the action (compare), and the scope (2-4), and distinguishes it from sibling tools like compare_forecasts and compare_passes by focusing on resort-specific stats.

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 scenarios: 'Use for head-to-head stat questions phrased as either/or' with concrete examples. It does not explicitly state when-not-to-use or name alternative tools, but the usage context 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 declare readOnlyHint=true and idempotentHint=true, so the description adds that it returns results sorted by 24-hour snowfall. No contradictions; the description enhances understanding 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 sentences: first states action and sorting, second gives use cases. No wasted words, front-loaded with key information.

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

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

With output schema present, description need not detail returns. It covers core functionality and use cases. Minor omission: does not mention optional nature of parameters, but schema covers that.

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 (limit, region, minSnowfall) are well-documented. The description does not add extra semantics 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 clearly states it finds resorts with the freshest powder snow, sorted by 24-hour snowfall. This distinguishes it from sibling tools like get_snow_report (single resort) and find_resorts_by_criteria (general search).

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 recommends use for 'where is it snowing?' or 'fresh powder' queries. However, it does not mention when not to use or contrast with alternatives like get_weather_forecast or get_snow_history.

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?

Description adds value beyond annotations by stating it returns flight-search links (not actual bookings) and uses resort slug with optional origin. Annotations already indicate read-only and idempotent, and description aligns 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?

Extremely concise: three sentences, front-loaded with main action, then pairing context, then argument details. No wasted words.

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

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

Despite having an output schema, the description provides complete context: what the tool does, how to use, argument details, and integration with workflow. No gaps.

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

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

Schema coverage is 100%, and description enriches both parameters: explains resort slug requires using search_resorts, and origin can be omitted for origin-less search. Adds practical guidance beyond schema 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 explicitly states it finds nearest gateway airports and provides flight-search links, using specific verbs and resource. It distinguishes from siblings by mentioning pairing with find_best_powder/find_powder_trips and book_lodging.

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

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

Clearly states when to use: 'Complete the trip' and 'the get there leg of the funnel'. Provides explicit context for usage, including pairing with other tools, and advises using search_resorts first for resolution.

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, idempotentHint, destructiveHint. Description adds booking flow details (links to LUXSKI) and reliance on forecast data, 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?

Description is moderately long but well-structured, front-loading purpose and examples. Each 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?

With output schema present, description doesn't need to detail return values. Covers purpose, parameters, usage, and external booking, making it fully adequate for the tool's complexity.

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 3 params (100% coverage). Description adds context for vibe filter ('handpicked hotels in that tier') and default limit, enhancing semantic understanding.

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 powder forecast and returns handpicked luxury hotels, differentiating it from siblings like find_best_powder or plan_ski_trip by focusing on bookable trips with accommodation.

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 example queries ('where should I book for powder', 'best powder trip this month') and lists optional vibe filter. Lacks explicit when-not-to-use or alternatives, but usage 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, 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 readOnlyHint, idempotentHint, destructiveHint. Description adds that the bulletin is relayed from official warning service with issuer and link, and specifies behavior when no bulletin exists. 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?

Two sentences: first states purpose, second covers edge cases and warnings. No unnecessary words, front-loaded with key action and scope.

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?

Description is complete for a read-only tool with output schema present. Covers geographic scope, behavior for missing data, source attribution, and important caveat about training. No missing context.

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 'slug' described adequately. Description does not add further parameter details beyond what schema provides, meeting the baseline for high 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?

Description clearly states verb 'get' and resource 'avalanche danger bulletin' with geographic scope (US, Canada, Switzerland). It distinguishes from sibling tools like get_snow_report or get_weather_forecast by focusing specifically on official avalanche bulletin.

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 context for when to expect 'no bulletin' (off-season, no forecast service) and includes a caveat about not being a substitute for official bulletin or training. However, it does not explicitly compare to sibling tools or state when NOT to use it 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 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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses what the result contains, when the in-season scorecard is included, and important limitations: 'Tilt, not fate — n=3 disclosed; D/E tiers are timing plays.' This gives the agent useful behavioral and interpretability context.

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 dense sentences, front-loaded with the core purpose, followed by output detail, usage context, and caveat. No filler or redundancy.

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

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

With a single required parameter and an output schema already present, the description covers scope, data source, return inventory, timing, methodology, and limitations. It is fully sufficient for an 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?

The schema already documents 'slug' with examples and has 100% coverage. The description only adds that this is resort-level info, which is mild context rather than new parameter semantics. 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 'Resort-level El Niño / ENSO outlook' and then lists the concrete outputs returned (rank, tier, signal, analogs, forecast paragraph). It clearly distinguishes itself from fleet-level or ranking-level tools like get_elnino_rankings while scoping itself to a specific 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?

It gives explicit use guidance: 'Use for ANY El Niño, ENSO, or 2026-27 winter-outlook question about a named resort.' It does not explicitly name alternatives or say when not to use it, which prevents a 5, but the context is clear.

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

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

Annotations already declare 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context: uses ~30 years of ERA5 data, months with too little history are withheld, and each month carries yearsTracked. No 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?

Description is slightly long but well-organized and front-loaded with key purpose. Every sentence adds value, with clear examples and usage guidance.

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 and only one parameter, the description covers purpose, usage, and behavioral nuances thoroughly. No gaps for the complexity level.

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?

Only one parameter (slug) with full schema coverage (100%). Description does not add specific parameter semantics beyond the schema, but provides overall context for the tool. 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 provides typical snow history from ERA5 reanalysis, listing metrics like average snowfall, snow days, depths, and biggest storm. It distinguishes from siblings by naming get_weather_forecast and get_resort as alternatives.

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 to use for date-choosing questions (e.g., 'what is February usually like at Vail', 'when should I go') and clarifies it's not a forecast or prediction, pointing to specific 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 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, idempotentHint, destructiveHint. Description adds valuable behavioral context: modeled guidance, not official, caveat to check live status. 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 perfectly front-loaded: first states purpose with key details, second adds critical caveat. No wasted words.

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

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

Tool has output schema, and description covers purpose, time horizon, factors, and limitations. Complete for a risk-estimation tool among many siblings.

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?

Only one parameter 'slug' with schema description 'Resort slug'. Schema coverage is 100%, so description adds no extra meaning. Baseline 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?

Description clearly states the tool provides a 48-hour operating-risk estimate for lifts, listing specific factors (wind-hold, visibility, cold, heavy-snow). It distinguishes from both the resort's own decision and sibling tools like get_weather_forecast 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?

Explicitly states 'Modeled guidance, NOT the resort's own operating decision — always check live lift status.' This tells the agent when to use (risk estimate) and when not to rely solely on it, effectively guiding usage 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 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=true, idempotentHint=true, destructiveHint=false, indicating a safe read operation. The description adds behavioral context beyond annotations: it mentions that accumulation data is burned into frames ('Proof of Powder'), that results are returned newest-first, and that watch links are provided. 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 a single paragraph that front-loads the tool's core purpose, then lists example queries, and ends with the return behavior. It is efficient but could be slightly more structured with bullet points. 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 an output schema exists (not shown but acknowledged), the description does not need to explain return values. It covers filtering options (resort, date), ordering, the nature of the data (verified accumulation), and typical use cases. This is sufficient 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 coverage is 100% with all three parameters (date, limit, resort) having descriptions. The description does not add significant new semantics beyond the schema; it restates that resort is optional and date requires resort (already in schema). The use-case examples indirectly guide parameter usage but do not provide deeper meaning. Baseline 3 is appropriate given high 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 clearly states the tool retrieves Powder Reels — archived storm timelapses with verified accumulation data. It provides specific example queries like 'how much did it snow at X last night' and mentions the output ordering (newest-first with watch links). This distinguishes it from sibling tools focused on forecasts, webcams, or snow reports.

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 use cases for storm footage, timelapses, and powder receipts. While it does not explicitly state when not to use this tool, the context makes it clear it is for historical, verified storm recaps rather than live conditions or forecasts. The sibling tools like get_webcam_status and get_snow_report provide alternatives, but the description does not directly call them out.

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, destructiveHint=false, idempotentHint=true. Description adds behavioral context: the tool returns an 'interactive UI' based on card parameter, and details content of each card. 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?

Description is somewhat lengthy but necessary to cover all four card types and usage mappings. Front-loads the key point about the required card parameter. Could be slightly more structured (e.g., bullet list) but still effective.

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 (4 card options, 2 parameters, output schema exists), the description fully covers usage: explains each card's content, gives request mapping, and provides alternatives. 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?

Schema provides descriptions for both parameters (100% coverage). Description adds significant value: natural language mapping for the card parameter (e.g., 'Resort guide' → card=guide) and example slug values. This enriches the schema definitions.

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

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

The description clearly states it provides 'Single-resort data' and explains each card type (guide, photos, snow, full). It explicitly distinguishes from sibling tools like get_resort_info and get_resort_photos, which are mentioned as alternatives.

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?

Explicit instructions: 'REQUIRED card parameter', mappings from user requests to card values, and a preference note to use get_resort_info/get_resort_photos when available. 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 readOnly/idempotent/non-destructive, and the description adds contextual behavioral traits: it returns a UI card, focuses on single-resort stats, and is explicitly non-weather. No contradictions exist between the description and annotations.

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

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

The description is front-loaded with the main purpose and uses structured lists and examples. Every sentence earns its place; despite length, there is no redundancy, and the formatting (caps, examples, exclusions) improves scannability.

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?

Considering the tool's moderate complexity and the presence of an output schema, the description covers all necessary aspects: what it does, when to use it, when not to use it, and how it relates to siblings. The output schema handles return-value details.

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 and examples for the single 'slug' parameter. The description does not add further parameter-level detail, but the schema already sufficiently documents it, 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 opens with a specific verb-resource pair ('INTERACTIVE RESORT GUIDE CARD') and immediately enumerates the content areas (elevation, lifts, runs, etc.). It also explicitly differentiates itself from sibling tools by stating 'Do NOT use get_resort' and 'use compare_resorts' for 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?

Provides explicit 'REQUIRED when' trigger phrases, concrete example queries, and clear alternatives/exclusions. This gives the agent unambiguous directives for when to select this tool and when to select a sibling.

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 safe read-only behavior. The description adds useful context about the output format (interactive carousel, official SnowSure photos) but doesn't contradict annotations. No additional behavioral traits needed beyond what's provided.

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?

Extremely concise with no wasted words. Key information is front-loaded with capitalization for emphasis, and 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 the simple single-parameter tool with output schema and annotations, the description is fully complete. It covers purpose, usage, and exclusions without missing any essential context.

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 description adds minimal value beyond the schema's parameter definition. It provides example slugs but no extra semantic meaning.

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: retrieving interactive photo galleries for resorts, using specific verbs like 'get photos' and resources. It distinguishes from siblings by explicitly forbidding use of web search or other tools 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?

Provides explicit when-to-use and when-not-to-use guidance, listing trigger keywords (photos, pictures, images, gallery) and naming sibling tools to avoid (get_destination, get_resort_info, ask_snowdata).

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 and idempotent. The description adds that the tool links to official DOT maps and notes that the resort's road status is authoritative, clarifying data sources. It also states the fallback return value, which is helpful context 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 that efficiently pack purpose, scope, examples, coverage limitations, and a link to authoritative sources with no wasted words.

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

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

The description covers geographic scope, return behavior for uncovered areas, and a reference to official maps. With an output schema present (not shown), the description provides sufficient context for an agent to understand what the tool returns and its limitations.

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?

Only one parameter 'slug' exists with schema description 'Resort slug'. The tool description does not add further detail about this parameter, but schema coverage is 100%, so the baseline score 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 clearly states the tool provides driving access info for resorts, answering specific questions about chain requirements and road conditions. It lists covered states (California, Washington, Colorado, Utah) and the type of data returned (chain-control, mountain-pass, road-surface).

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 what the tool does and its geographic scope, noting that outside coverage it returns 'no road data'. However, it does not explicitly contrast with sibling tools like get_road_cameras or get_road_weather, nor does it advise when not to use it.

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

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

Annotations already indicate safe, read-only behavior (readOnlyHint, destructiveHint). The description adds valuable behavioral context: coverage limited to specific states, returns 'no road cameras' for areas outside coverage, and each camera includes a live image URL. 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, well-structured sentence that front-loads the core action and key details. Every piece of information is relevant and no words are wasted.

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

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

For a simple tool with one parameter and existing output schema, the description covers all essential aspects: purpose, regional coverage, edge case handling, and output content. 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?

The parameter 'slug' is fully described in the schema with 100% coverage. The description does not add further detail about the slug parameter's format or expected values, which is adequate given 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 specifies the tool's purpose: retrieving live roadside camera stills near a resort from specific DOT/CCTV sources (Caltrans, WSDOT, UDOT). It explicitly distinguishes from resort webcams and explains the output behavior, making it clear and distinct from sibling 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 notes that it is 'distinct from resort webcams,' providing some guidance on when not to use this tool. However, it does not explicitly list alternative tools for similar queries (e.g., get_webcam_status), 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 already declare readOnly, idempotent, and non-destructive nature. The description adds valuable context: data sources (CDOT, WSDOT, UDOT), that the data is measured sensor data (not modeled), and the edge case behavior ('returns 'no road weather' outside covered area'). 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 plus a phrase, efficiently conveying purpose, data points, geographic scope, source distinction, and edge case. No unnecessary words, and key 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?

Given the existence of an output schema to document return values, the description covers the tool's purpose, data types, geographic coverage, distinction from a sibling tool, and edge case behavior. It lacks explicit prerequisites or limitations (e.g., that the resort slug must correspond to a valid resort in one of the three states), but overall it is fairly complete.

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

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

Schema coverage is 100% with one parameter (slug) described as 'Resort slug'. The description does not add further details about the parameter itself but provides overall context about the data returned, which helps interpret the parameter's role. 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 specifies the tool measures roadside weather (RWIS) with detailed data points (surface+air temperature, visibility, wind, precipitation) and lists specific state data sources. It distinguishes itself from the modeled get_operating_risk tool, providing clear differentiation.

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 for when to use this tool ('sensor data on the actual road') and explicitly contrasts with get_operating_risk ('distinct from the modeled'). However, it does not mention alternatives among other road-related sibling tools like get_road_access or 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 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 description's job is lighter. It adds value by explaining the scope constraint (single resort) and the specific data returned (season totals, averages, best months), which goes 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?

Two sentences, zero waste. The first sentence delivers purpose and outputs; the second sentence provides usage guidance and sibling differentiation. Highly 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 low complexity (1 required param, no nested objects, no enums), the presence of an output schema, and comprehensive annotations, the description is complete. It covers what the tool does, its outputs, its scope, and when to use 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% for the single parameter 'slug', but the description does not add any meaning beyond the schema's description 'Resort slug'. However, since the schema already fully describes the parameter, a baseline of 3 is appropriate; the description earns a 4 because it provides context (that the slug identifies a single specific resort) and distinguishes the tool's 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 clearly states the specific verb ('get' implied) and resource ('snow history'), listing concrete outputs: season totals, averages, and best months. It explicitly distinguishes from the sibling tool 'get_season_leaderboard', which is a different 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?

Explicitly states when to use this tool (single resort history) and when not to ('for which resort in <state/country/region> led <metric> last season'), naming the alternative tool 'get_season_leaderboard'. This provides clear guidance for the agent.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating safe read behavior. The description adds no new behavioral context beyond what annotations provide, which is adequate but not enhanced.

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

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

The description is two sentences with no filler, front-loaded with the core purpose, and efficiently conveys use cases.

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 a full output schema, the description doesn't need to explain return values. It covers the tool's primary function and query intent, but omits mention of region filtering and limit, which are in the schema. Still, the context is sufficient for most agents.

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 description need not repeat all parameter details. However, the description mentions only three sort options (snowsure, forecast, recent) while the schema includes 'depth', and it does not explain 'limit' or 'region' parameters, providing partial but incomplete 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 clearly states the tool returns a global snow report with top-ranked resorts by snow conditions, providing specific use cases. However, it does not differentiate from similar sibling tools like 'get_my_snow_report' or 'find_best_powder'.

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 for when to use the tool, but lacks guidance on when not to use it or mention of alternatives among the many sibling tools.

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

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

Annotations already declare readOnlyHint=true, 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 indicate readOnlyHint and idempotentHint. Description adds that it returns a forecast for up to 14 days with specific weather data, which is consistent and informative 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?

Single sentence, front-loaded with action, no extraneous words. Efficiently communicates purpose and scope.

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 forecast tool with full schema coverage and existing output schema and annotations, the description is complete enough for an agent to understand what it does without additional clarification.

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 fully describes parameters (slug, days). The description does not add meaning beyond what the schema provides; it mentions output content but not 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?

Description clearly states the tool retrieves a day-by-day weather forecast for a resort, including specific weather elements (temperature, snowfall, wind, conditions). It distinguishes from siblings by specifying 'forecast' for the next 14 days, unlike historical or report 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?

No explicit guidance on when to use this tool vs alternatives. The description does not mention when not to use or provide references to sibling tools like 'get_snow_report' or 'get_monthly_snow'.

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 a safe, read-only, idempotent operation. The description adds behavioral context by stating it returns live links and status, and supports named-cam lookups. This goes beyond annotations but lacks details like caching behavior or response size.

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, front-loading purpose and examples with zero waste. Every part earns its place, making it highly 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 annotations cover safety, the output schema exists (though not shown), and the tool has a single parameter, the description is sufficiently complete. It could mention return structure briefly, but the output schema fills that gap.

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

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

The input schema has 100% description coverage for its single parameter 'slug', which is described as 'Resort slug'. The description does not add further meaning or format constraints, so it adds no semantic value beyond the schema. 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 retrieves live webcam links and status for a resort to visually assess current on-mountain conditions, and includes example queries. It is specific about the resource (webcams) and purpose, effectively distinguishing it from sibling tools like get_snow_report or get_resort_photos.

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 by listing example queries it answers, so an agent can infer when to use it (when asked about webcams). However, it does not explicitly mention when not to use it or suggest alternatives, which limits guidance for selecting among sibling 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 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?

The description adds the authentication requirement beyond annotations, which already indicate destructiveness and idempotency. However, it does not disclose behavior for invalid slugs or non-existent resorts.

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 front-load the purpose and follow with a necessary prerequisite, with no extraneous information.

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

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

For a simple one-parameter delete operation with an output schema, the description covers purpose and auth. Slightly incomplete regarding error handling, but sufficient given the complexity.

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 describes the parameter 'slug', and the description adds context that the resort slug refers to one in the user's saved list, providing marginal extra value beyond the schema.

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

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

The description clearly states the action ('Remove a resort from the signed-in user's saved list') and distinguishes it from sibling tools like save_resort and list_saved_resorts by specifying the target is the user's own saved list.

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

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

The description mentions an authentication prerequisite ('requires a SnowSure user access token') but does not explicitly state when to use this tool versus alternatives or provide exclusions.

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

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

Annotations specify idempotent and non-destructive; description adds context about token and slug validity. No contradictions. Could add detail on duplicate handling, but annotations already imply safety.

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 with no irrelevant information. Purpose stated first.

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 one parameter and output schema present, the description covers essential input and behavior. Could mention output structure if not obvious, but schema handles that.

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

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

The single parameter slug has a description and example in schema. The description adds validation requirement ('must be a real SnowSure resort'), enhancing 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 clearly states the action (save), resource (resort), and destination (user's favorites). It effectively distinguishes from sibling tools like remove_saved_resort and list_saved_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?

Mentions prerequisites: requires OAuth token and real slug. Provides clear context for when to use the tool, though no explicit 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?

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?

The description goes beyond annotations by requiring a SnowSure user access token (OAuth) and detailing the trigger semantics for each alert type (e.g., powder is based on observed fresh snow in 24h). This adds useful behavioral context; 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?

At roughly three sentences, the description is compact yet dense with information, starting with the primary action and using parentheticals to efficiently explain each alert type. Every sentence earns its place without unnecessary verbosity.

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

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

The description covers the auth prerequisite, all alert types, and their trigger logic, while schema covers parameter defaults and formats; the presence of an output schema further reduces the need for return-value documentation. This is sufficient for an agent to correctly invoke the 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?

Although the schema already documents all five parameters, the description thoroughly explains the meaning of each 'type' value and clarifies how thresholdCm and windowDays apply differently per type, greatly aiding parameter selection. This is a prime example of description adding 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 first sentence, 'Subscribe the signed-in user to snow alerts,' clearly specifies the action (subscribe) and resource (snow alerts), and the enumeration of alert types distinguishes it from siblings like list_alerts and unsubscribe_alerts. The description is precise and leaves 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 clear context on when each alert type is appropriate (e.g., 'forecast' is the proactive watcher) and notes the OAuth requirement, but it does not explicitly contrast with alternative tools such as list_alerts or unsubscribe_alerts. This is a minor omission since the purpose is so distinct, but not fully 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 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.