SnowSure — Snow & Ski

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable behavioral context: response is text-only, fast (~1s), and does not render UI cards. There is no contradiction with annotations. The description enhances transparency 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 extremely concise: three sentences covering purpose, positive use cases, negative guidance, and a note on UI behavior. It is front-loaded with the core purpose in the first sentence. Every sentence earns its place with no redundancy or wordiness.

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 6 parameters with full schema descriptions and an output schema, the description covers the essential context: what it does, when to use it, what it cannot do, and a performance hint (~1s). It could optionally elaborate on 'grounded in SnowSure data' or response structure, but the output schema likely handles that. The description is nearly complete; a minor gap is not explaining the 'SnowSure' data source.

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% (all 6 parameters have descriptions in the schema). The description does not add parameter-specific details beyond the schema, which already documents each parameter's purpose. Baseline 3 is appropriate since the description does not need to compensate for missing schema descriptions, but it also does not significantly augment parameter 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 that this tool provides text-only Q&A grounded in SnowSure data, with specific use cases (open-ended questions, terrain %, expert-run counts, comparisons, advice). It explicitly distinguishes from siblings by telling the agent NOT to use it for photo/gallery/picture requests (use get_resort_photos) or resort guide cards (use get_resort_info). The verb 'ask' and resource 'SnowSure' are well-specified.

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 (open-ended questions, terrain %, expert-run counts, comparisons, advice) and when-not-to-use guidance with alternative tool names (get_resort_photos for photos, get_resort_info for resort guide cards). It also clarifies that this tool 'does NOT render UI cards', eliminating confusion about output format.

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 destructiveHint=false. The description adds deprecation status and backward-compatibility timeframe, which is useful but does not reveal additional behavioral traits. 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 a single, front-loaded sentence that conveys all necessary information with zero wasted words. It is optimally concise for a deprecated alias tool.

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

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

Given the deprecation context and the presence of an output schema, the description is sufficiently complete. It directs agents to the replacement tool, and the output schema covers return values. It omits detailed behavior, but that is inherited from ask_snowdata.

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% coverage for parameter descriptions, so the schema itself documents the parameters. The description adds no additional meaning about parameters beyond what is already in the schema. 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 explicitly states that this tool is a deprecated alias for ask_snowdata, clearly indicating its purpose as a backward-compatibility shim. It directly tells the agent what the tool is (an alias) and what to use 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 guidance: use this tool only for backward compatibility during the 90-day window, and otherwise use ask_snowdata. This effectively differentiates when to use this tool versus its 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 readOnlyHint=true and destructiveHint=false, indicating safe read behavior. The description adds value by explaining the multi-model comparison and output of agreement/uncertainty, but does not disclose additional behavioral traits like response structure or data freshness.

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 succinctly state the action, scope, models, output, and recommended use. No filler or repetition.

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

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

With 1 parameter, full schema coverage, and an output schema, the description covers all necessary aspects: what it does, which models, what output shows, and when to use it. Nothing is missing.

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

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

The schema covers all parameters (100% coverage) with a clear description for 'slug'. The description mentions 'for a resort' but does not add semantically richer meaning beyond what the schema provides. 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 a concrete verb ('Compare'), a clear resource ('14-day snow forecasts across 7 weather models'), and the output ('model agreement and uncertainty'). It effectively distinguishes from sibling tools like get_weather_forecast (likely single model or basic forecast).

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

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

The description explicitly advises use for 'forecast reliability queries,' which provides clear context. While it does not mention when to avoid this tool or suggest alternatives, the sibling list includes get_weather_forecast, implying that tool is for single-model forecasts.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is known. The description adds 'right now' implying real-time data but no further behavioral traits (e.g., rate limits, data freshness). 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 three concise sentences with no fluff. Purpose, functionality, and usage examples are front-loaded. 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 optional parameters and existing output schema, the description covers the core use case well. It does not mention region filtering or limit behavior, but these are documented in the schema. Adequate for common queries.

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 does not elaborate on parameters beyond what the schema provides; it only mentions sorting by snowfall, which aligns with minSnowfall. No additional semantic value added.

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 with freshest powder snow and sorts by 24-hour snowfall, using strong verbs like 'Find' and 'Returns'. It is easily distinguishable from siblings like find_resorts_by_criteria which likely uses different 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 provides explicit usage context with example queries ('where is it snowing?', 'fresh powder'), but does not compare to alternatives or state when not to use this tool. It is clear but lacks exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description provides limited additional behavioral context. It describes the filtering action but does not explain behaviors like result ordering, default values, or what happens when no criteria are given.

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-loading the purpose and then providing context. Every sentence serves a purpose 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?

Given 7 optional parameters, annotations, and an output schema, the description is mostly complete. It covers the core filtering purpose but omits mention of the limit parameter and pagination implications, though the 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 coverage is 100%, so the baseline is 3. The description adds value by grouping parameter examples (minDepth, minElevation, minRuns, minScore) but does not provide additional semantics beyond the 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's purpose: 'Find resorts matching specific criteria' and lists example criteria (snow depth, elevation, runs, SnowSure rating). It distinguishes from siblings like search_resorts (general search) and get_resort_info (specific resort) by calling it '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 filtering resorts by criteria via 'Advanced filtering for trip planning', but does not explicitly state when not to use it or mention alternatives from the sibling list, such as search_resorts for broader search.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. Description adds that it returns a table of member ski areas and mentions slug/alias. Does not discuss rate limits or auth, but given annotation coverage, it adds useful context 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?

Two tightly written sentences. The first sentence states the tool's function; the second provides usage guidelines. No unnecessary words, perfectly 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 an output schema exists, no need to explain return values. Description covers purpose, usage distinctions, and parameter hints. The tool is well-contextualized among 19 siblings with clear differentiators.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. Description adds minor value by mentioning slug aliases but does not elaborate on limit behavior 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?

Clearly states it is a multi-mountain destination hub returning a table of member ski areas, specifying the resources (Niseko, Chamonix, Aspen Snowmass). Distinguishes from siblings by mentioning what it is not for (photo gallery → get_resort_photos, resort guide cards → 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?

Explicitly states when to use (when user names the hub itself) and when not to, with direct alternatives (get_resort_photos for photo gallery, get_resort_info for resort guide cards). Provides clear context and 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining the tool returns analysis and filtering options, though it doesn't detail pagination or response limits. Overall, it enhances transparency 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 consists of two concise sentences with no wasted words. The first sentence front-loads the purpose with examples, and the second immediately provides filtering guidance. Every sentence serves a purpose.

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 optional enum parameters, output schema exists), the description fully covers the tool's role, what it returns, and how to filter. It references the prerequisite call to list_insight_categories, making it self-contained for an AI agent.

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

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

With 100% schema description coverage, the baseline is 3. The description adds value by explaining how to use insightType to skip leaderboards and implies the need to call list_insight_categories first (as per schema). This provides functional guidance beyond the schema alone.

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

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

The description clearly states the tool retrieves categorized SnowSure intelligence insights, not just snow totals, and gives specific examples like season vs 5yr norm. It distinguishes from siblings by specifying the type of insights, making the purpose unambiguous.

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

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

The description provides clear usage context: answers specific questions about trends and leaderboards. It advises filtering by category or insightType=intelligence to skip simple leaderboards. While not explicitly listing when not to use, the context and sibling list offer sufficient 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 it fetches from the public REST API, consistent with annotations (readOnlyHint=true). It adds context about the type of data returned, and there is no contradiction. Annotations already cover the safety profile, and the description reinforces with additional detail.

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

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

The description is three sentences: action, use cases, best practice. Every sentence adds value, no fluff. Front-loaded with the main verb and resource.

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 (10 parameters, 13 datasets), the description provides enough context to understand what the tool does, how to start, and when to use alternatives. Output schema exists, so return values are covered elsewhere. No obvious 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%, so baseline is 3. The description mentions dataset=catalog and lists use cases that map to datasets, but does not add new parameter meaning beyond what the schema already provides. Some usage hints are present but not strictly new param 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 fetches SnowSure-unique ML/AI trend datasets and specifies many use cases. It explicitly distinguishes from sibling get_insights by saying 'prefer get_insights for narrative intelligence cards; use this for raw rankings and time series.'

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, including 'Start with dataset=catalog' and the suggestion to use get_insights for narrative cards instead. This gives clear context for when to choose this tool over 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 and destructiveHint=false. The description adds no additional behavioral context beyond 'Get a summary', such as response format, pagination, or rate limits. For a read-only tool, minimal added value.

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, efficient sentence conveying the core functionality without extraneous words. It is appropriately 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 that an output schema exists and the tool has 0 required parameters with simple inputs, the description adequately captures the tool's purpose. It mentions the key outputs (statistics, top resorts) and complements the schema.

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 clear descriptions for region (enum) and country. The description adds 'statistics and top resorts' but does not enhance parameter understanding. Baseline 3 is appropriate as the schema already documents parameters well.

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 a summary of snow conditions across a region or country, including statistics and top resorts. It distinguishes from sibling tools that focus on single resorts or specific forecasts, though it does not explicitly contrast with them.

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

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

The description lacks guidance on when to use this tool versus alternatives. No explicit when-to-use, when-not-to-use, or references to sibling tools like get_snow_report or find_resorts_by_criteria.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context about card-driven UI behavior but no further safety or side-effect info. No contradiction, 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?

5 sentences with zero waste. Front-loads the core concept and then lists options efficiently.

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

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

With output schema present (not shown but known), description covers all parameter behavior, sibling differentiation, and usage context. Complete for 2-param read-only tool.

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

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

Schema coverage is 100% and description enriches card parameter with natural language mappings, going beyond enum labels. Slug is clear from 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?

States 'Single-resort data' with specific verb 'get' and resource 'resort data'. Clearly distinguishes from siblings by advising to prefer get_resort_info / get_resort_photos when available.

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

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

Provides explicit mapping from user intents to card values ('Resort guide' → card=guide) and recommends alternative tools for the same cards. Clear when-to-use guidance.

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

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

Annotations already mark it as read-only and non-destructive. The description adds context that it returns a UI card with specific data sets and clarifies it is non-weather, which is a useful behavioral disclosure 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?

Concise, front-loaded with purpose, then usage guidelines, examples, and a clear do-not-use note. 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 tool with one parameter, full schema coverage, annotations, and output schema, the description fully covers what the tool does, when to use it, and its output content.

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

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

Only one parameter (slug) with 100% schema coverage. The description does not add any semantic details beyond what the schema already provides in the property description.

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

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

The description clearly states the tool provides a 'Resort guide card' with specific data (elevation, vertical, lifts, etc.). It distinguishes from sibling 'get_resort' by noting that tool shows snow conditions 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?

Explicitly lists use cases (e.g., 'resort guide', 'mountain profile', 'lifts/runs') and provides examples. Also explicitly warns against using get_resort, which shows different content.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds source information ('official SnowSure resort photos (hero + Sanity gallery)') but doesn't describe interactive behavior or potential loading states. 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?

Front-loaded with a clear purpose label and succinct usage guidance. The ALL-CAPS emphasis is slightly jarring but does not harm clarity. Every sentence adds value, though the tone could be softened.

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, the description doesn't need to detail return values. It covers purpose, trigger phrases, and sibling exclusions. However, it omits any mention of prerequisites (e.g., resort slug format) or edge cases.

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 single slug parameter. The description adds no additional parameter details beyond the schema description, 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?

Description clearly states it's a photo gallery carousel for official resort photos, explicitly listing trigger keywords (photos, pictures, images, gallery) and distinguishing it from sibling tools by instructing not to use get_destination or get_resort_info 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 guidance: required for photo-related queries, and explicitly warns against using web search or inline images. Also names specific sibling tools to avoid, leaving no 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 provide readOnlyHint and destructiveHint, and description adds that it returns season totals, averages, and best months. This gives useful behavioral context beyond annotations, though doesn't mention rate limits or data freshness.

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, no redundant words. All information is front-loaded and essential.

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

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

Covers core purpose and return elements. Output schema exists, so missing details about structure are acceptable. No mention of pagination or limitations, but adequate for a straightforward historical data 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?

Only one parameter 'slug' with schema description 'Resort slug'. Schema coverage is 100%, so baseline is 3. Description does not add additional context about slug format or sourcing (e.g., from search_resorts).

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 specifies verb 'Get' and resource 'historical snowfall data for a resort', including specific elements (season totals, averages, best months). Distinguishes from siblings like get_snow_report or get_weather_forecast which cover current or forecast data.

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

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

Implies use for historical analysis, but no explicit guidance on when to prefer this over siblings like compare_forecasts or find_best_powder. No alternatives or exclusions 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 and destructiveHint=false, indicating a safe read operation. Description adds sorting details but no additional behavioral context beyond what annotations imply.

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, concise and front-loaded with the core purpose, 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?

Description is complete for a filtered list tool with output schema present. Covers sorting and usage context, but could briefly mention result limit.

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 clear descriptions for all three parameters. Description mentions sorting options but does not add significant new meaning 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?

Description specifies 'Get the global snow report with top-ranked resorts by snow conditions' and explicitly states usage for 'where has the best snow?' or 'top ski resorts right now' queries, distinguishing it from sibling tools like find_best_powder or get_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?

Provides clear context for when to use ('where has the best snow?', 'top ski resorts right now'), but does not explicitly mention when not to use or list alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds 'Prefers operator-verified data when available', which is a helpful behavioral detail about data sourcing but does not provide deeper behavioral context like error handling or rate limits.

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

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

The description consists of two terse, front-loaded sentences. The first sentence states the core function, and the second provides usage guidance. No extraneous 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 the tool has 3 optional parameters with enums and a known output schema, the description covers the main context: region, season, and data preference. It does not explain behavior when out of season or when no data is available, but the output schema likely handles that. Overall, it is 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 coverage is 100%, meaning each parameter has a description and enum values. The tool description does not add any parametric information; it focuses on purpose and usage. Baseline score of 3 is appropriate as the schema already defines the parameters clearly.

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 'Get snow conditions for Southern Hemisphere ski resorts', clearly stating the verb and resource. It specifies the countries (Australia, New Zealand, Argentina, Chile) and adds 'currently in season', distinguishing it from general snow reports or Northern Hemisphere 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 explicitly says 'Use for "best snow in Australia/NZ/Argentina" or June–October ski trip queries', providing clear usage context. It does not name sibling alternatives explicitly, but the context signals regional focus, making it easy for the agent to differentiate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds value by specifying the scope (14-day forecast, day-by-day details), which is beyond the annotations. However, it does not disclose potential rate limits or data freshness, so not a 5.

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

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

The description is a single, well-constructed sentence that front-loads the key action and result. Every word is necessary and there is no redundancy or 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?

Given the tool has an output schema (not shown but present) and only 2 parameters, the description provides sufficient context for what the tool does. It could mention that the forecast is for the next 14 days to be more precise, but it's already complete enough 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% with descriptions for both parameters (slug as 'Resort slug', days as 'Number of days to forecast (default: 7, max: 14)'). The main description adds no extra parameter details 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 the tool retrieves a detailed day-by-day weather forecast for a resort, including specific metrics like temperature, snowfall, wind, and conditions for up to 14 days. This distinguishes it from sibling tools like get_snow_report (which focuses on snow) and compare_forecasts (which compares multiple 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 does not explicitly state when to use this tool versus alternatives like 'get_snow_report' or 'compare_forecasts'. There is no guidance on when not to use it or any prerequisites. The purpose is implied, but the lack of explicit usage context limits score.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds no further behavioral context (e.g., rate limits, auth needs). With annotations present, this is acceptable 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?

A single, front-loaded sentence efficiently conveys the tool's purpose without any extraneous words. Every part is meaningful.

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

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

For a simple read-only tool with one parameter and an existing output schema, the description adequately explains what the tool returns (webcam information and links). It could be more complete by mentioning the output schema role, but is not insufficient.

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' with description 'Resort slug'. The description does not provide additional parameter-specific information beyond what the schema already gives, earning the baseline 3.

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 information and links for a resort, using the specific verb 'Get'. It distinguishes itself from siblings like get_resort_photos by focusing on live webcams, not static 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?

No guidance on when to use this tool versus alternatives like get_resort_photos or get_snow_report. The context of 'live' versus 'static' is implied but not explicit, and no exclusions or alternatives are 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 indicate readOnlyHint=true and destructiveHint=false. The description adds value by specifying the content (categories) and noting that results are retrospective and verification-backed, which is behavioral 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?

Two concise sentences that front-load the purpose and include examples. Every sentence provides useful information without 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?

The output schema exists to document return values. The description covers purpose, usage context, and behavioral traits completely for a parameterless 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?

No parameters exist; schema coverage is 100%. The description does not need to add parameter information, and the baseline for zero parameters is 4. No additional semantic value 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 lists SnowSure insight categories and provides specific examples. It explicitly distinguishes itself from the sibling tool get_insights, indicating this is a precursor for selecting a category filter.

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 before get_insights to choose a category filter.' It also contrasts with raw leaderboards, clarifying when this tool is appropriate.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's claim of 'Get ski trip recommendations' is consistent. However, the description mentions 'conditions' which is not an input parameter, slightly overpromising. No major behavioral gaps beyond what annotations 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?

Two concise sentences that front-load the core purpose and add a brief elaboration. No redundant or unnecessary information; every word earns its place.

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

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

Given the optional parameters and existence of an output schema, the description adequately covers the tool's function. It could mention that all inputs are optional or describe the output format, but the output schema reduces the need. Minor gap in not stating that the output is a list of recommended resorts.

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 description adds minimal value beyond the existing parameter descriptions. It loosely references 'dates, preferences, and conditions' but does not specify which parameters correspond. 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 it provides ski trip recommendations based on dates, preferences, and conditions. This distinguishes it from sibling tools like get_resort or find_resorts_by_criteria, though it doesn't explicitly contrast with similar planning 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 guidance is provided on when to use this tool versus alternatives like find_resorts_by_criteria or ask_snowdata. The description does not mention exclusions or specific scenarios, leaving the agent without decision context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's claim of returning basic conditions adds some context but does not significantly expand on safety or 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 extremely concise with two sentences, front-loading the purpose and immediately providing usage guidance. 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 the presence of an output schema and low complexity (3 optional params, no enums), the description adequately covers purpose and usage. It does not need to detail return values.

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

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

The description mentions searching by name, country, or region, but the parameter schema only includes query (name/partial match) and country, not region. This inaccuracy reduces the value added over the schema, which already has 100% description 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 searches for ski resorts by name, country, or region, and returns matching resorts. It gives example queries, but does not explicitly differentiate from similar sibling tools like 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 provides explicit usage examples ('find resorts in [location]' or 'search [name]'), giving clear context for when to use the tool. However, it lacks guidance on when not to use it or mention of alternatives.

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