Live snow reports, SNOTEL measurements, webcams and powder rankings for 150 ski resorts.
Scored across 8 tools
Each tool has a clearly distinct purpose: search for slugs, retrieve single-resort conditions, view history, get forecasts, inspect cams, check opening dates, compare multiple resorts, or rank powder. Overlaps between compare_resorts and get_resort_conditions are resolved by the multi-resort vs single-resort distinction.
All tool names use consistent snake_case verb_noun patterns (compare_resorts, find_powder, get_forecast, search_resorts, etc.). The convention is predictable throughout the set.
Eight tools are well-scoped for a resort snow-reporting service, with each tool covering a distinct query type. The set is neither bloated nor thin.
Core workflows are covered: discovery, current conditions, history, forecast, cams, opening dates, comparison, and powder ranking. Minor gaps include no explicit list-all-resorts tool and no lift/trail status, though search_resorts and conditions largely work around these.
Side-by-side latest snow, season status and cam counts for 2–6 resorts. Every slug must resolve; an unknown one returns suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | 2–6 resort slugs. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| resorts | Yes | |
| generatedAt | Yes | ISO-8601 UTC instant the result was generated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description does add one genuine behavioral fact beyond the annotations — an unresolvable slug still returns suggestions rather than failing outright — but says nothing about ordering, partial failures, or the response shape.
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 tight sentences with no filler: the first states scope and payload, the second states the failure behavior. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description only needs to set scope and edge-case behavior, which it does. The remaining gap is routing — it never tells the agent when this beats the single-resort or discovery siblings, which matters in a seven-tool family.
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 the schema already documents the slug format, its kebab-case convention, its origin (search_resorts), and the 2–6 bounds. The description only echoes the count constraint, adding no syntax or format detail beyond what the schema 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?
Names a specific verb+resource ('compare_resorts') and specifies the payload (latest snow, season status, cam counts) plus an arity range of 2–6 resorts, which implicitly separates it from single-resort siblings like get_resort_conditions. It never names an alternative explicitly, so sibling differentiation is by inference rather than statement.
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 '2–6 resorts' framing implies this is the multi-resort comparison tool, and the slug-resolution note tells the agent what happens on bad input. However, it gives no explicit when-to-use-vs-alternatives guidance (e.g., single resort → get_resort_conditions, or discovery → search_resorts), leaving the agent to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank resorts by new snow in the last 24 or 48 hours, optionally within one state/province and above a minimum. Pass sourceOnly="snotel" to answer "where did it snow most, measured only" with station data alone. Resorts with no report are left out; zero inches is a measurement. Sources: snotel = measured at a USDA NRCS SNOTEL station near the resort (station elevation, not the summit), open_meteo = weather-model estimate for resorts without a station.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return, 1–25. | |
| state | No | US state or Canadian province code (`CO`, `UT`, `BC`), or for the Andes the country name PeakCam lists (`Chile`, `Argentina`). Case-insensitive. | |
| window | No | Which window ranks first; the other breaks ties. | 24h |
| minInches | No | Keep only resorts with at least this many inches in the window. | |
| sourceOnly | No | `snotel` keeps only station-measured reports and drops model estimates. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| window | Yes | |
| filters | Yes | |
| license | Yes | |
| results | Yes | |
| attribution | Yes | |
| generatedAt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive, so the description adds valuable context about data sources (SNOTEL station elevation vs model estimate) and that missing reports are omitted while zero inches counts as a measurement. It doesn't cover rate limits or response format, but output schema exists.
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 action and then adds useful clarifications in three sentences, but the source definitions at the end are somewhat dense and could be more compact.
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 complete parameter documentation, the description provides all necessary behavioral context: ranking scope, exclusion rule, zero-inch semantics, and source distinctions. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all parameters; the description adds meaning for sourceOnly and minInches but mostly repeats 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 states a specific verb and resource ('Rank resorts by new snow') with the scope of the ranking window, and distinguishes itself from siblings like compare_resorts or get_snow_history by focusing on ranking rather than comparison or history.
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 clearly explains when to use sourceOnly='snotel' ('where did it snow most, measured only') and that resorts without reports are excluded, but it doesn't explicitly name alternative tools or say when not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Five-day National Weather Service forecast for a US resort (daily high/low, text forecast, precipitation chance, wind) with a rough snow estimate derived from the forecast wording. NWS covers US resorts only; Canadian and Andes resorts return available=false.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | PeakCam resort slug, lowercase kebab-case, e.g. `breckenridge` or `ski-portillo`. Get it from search_resorts. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| note | Yes | |
| slug | Yes | |
| periods | Yes | |
| provider | Yes | |
| available | Yes | |
| generatedAt | Yes | ISO-8601 UTC instant the result was generated. |
| canonicalUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety and idempotency are covered. The description adds genuinely useful behavior beyond that: the snow figure is explicitly a 'rough estimate derived from the forecast wording' (an accuracy caveat) and the US-only coverage with an available=false sentinel rather than an error.
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 tight sentences with no filler; the core purpose and output contents lead, and the geographic limitation is placed immediately after so it is read before the call is made.
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?
An output schema exists, so return values need not be explained, and the description covers the key caveats (derived snow estimate, US-only coverage, available=false). The only omission is guidance on sibling selection, which is a minor gap for a single-parameter read 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% and the single slug parameter is fully documented there, including the kebab-case format and the pointer to search_resorts. The description adds nothing about the parameter, which is the expected baseline when the schema already does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Five-day National Weather Service forecast') plus the exact payload fields (high/low, text forecast, precipitation chance, wind) and an added derived snow estimate. An agent can distinguish this from get_resort_conditions and get_snow_history without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear negative condition — NWS covers US resorts only, so Canadian and Andes resorts return available=false — which prevents wasted calls and misinterpretation of empty results. It does not, however, name when to prefer this over siblings like get_resort_conditions or find_powder, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Season opening and closing dates with status (open / closed / unknown) for every resort, or those in one state/province, soonest opening first. Confirmed dates come from the resort; projected ones are third-party estimates.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return, 1–150. | |
| state | No | US state or Canadian province code (`CO`, `UT`, `BC`), or for the Andes the country name PeakCam lists (`Chile`, `Argentina`). Case-insensitive. |
| Name | Required | Description |
|---|---|---|
| asOf | Yes | YYYY-MM-DD (US Pacific) the statuses were evaluated for. |
| count | Yes | |
| filters | Yes | |
| resorts | Yes | |
| generatedAt | Yes | ISO-8601 UTC instant the result was generated. |
| totalMatching | Yes | Resorts that matched before `limit` was applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description adds real context beyond them: data provenance distinguishing resort-confirmed dates from third-party projections, plus the possible values of the status field. It still does not state refresh cadence or how stale projected dates can be.
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, both load-bearing: the first covers scope, status values and ordering; the second covers data provenance. Nothing is repeated and the most important scope 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?
An output schema exists, so return shape need not be described. Between the description (scope, ordering, status vocabulary, data provenance) and the fully documented 2-parameter schema, an agent has everything needed to call this 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% and the schema already documents both parameters in detail, so the baseline is 3. The description adds the behavior of omitting `state` (returns every resort) and the output ordering ('soonest opening first'), neither of which the schema expresses; only `limit` receives no additional explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (opening/closing dates per resort) plus the returned status values and sort order, which is far more than a restatement of the name. It does not explicitly name or contrast any sibling tool, so an agent infers distinctness from the resource alone rather than being routed.
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 scope clause ('for every resort, or those in one state/province') implies when to pass `state` versus leaving it out, which is genuine usage guidance. There is no when-not-to-use guidance and no mention of alternatives such as get_resort_conditions or get_forecast when the agent actually wants live status rather than season dates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The resort's webcams as links: PeakCam page URL, the operator's stream or page URL, a still-image URL when one exists, and health (live / down / unchecked, from PeakCam's probe, not proof of a live broadcast). Frames are never returned inline.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | PeakCam resort slug, lowercase kebab-case, e.g. `breckenridge` or `ski-portillo`. Get it from search_resorts. |
| Name | Required | Description |
|---|---|---|
| cams | Yes | |
| name | Yes | |
| slug | Yes | |
| license | Yes | |
| updatedAt | Yes | |
| attribution | Yes | |
| canonicalUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond annotations: health comes from PeakCam's probe and is not proof of a live broadcast, and frames are never returned inline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with every phrase adding useful information about returned link types or health caveats. There is no redundant or filler language.
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 lookup with full schema coverage, annotations, and an output schema, the description is complete enough. It additionally clarifies that frames are not inline and that health is probe-based rather than live-broadcast proof.
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 is only one parameter and schema description coverage is 100%, so the schema already fully documents the slug argument. The description adds no parameter-level details, which is acceptable given the high schema coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource clearly: the resort's webcams returned as links, with enumerated URL types and health status. It is more specific than a generic webcam fetch, though it does not explicitly distinguish itself from sibling tools like get_resort_conditions or compare_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 intended use is implied by the tool name and description, but there is no explicit guidance on when to choose this over sibling tools. No alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The latest snow report for one resort with provenance: new snow 24 h / 48 h, base depth, snow water equivalent, percent of normal, 7-day trend, rating, season status, plus a cam summary and the canonical PeakCam URL to cite. Sources: snotel = measured at a USDA NRCS SNOTEL station near the resort (station elevation, not the summit), open_meteo = weather-model estimate for resorts without a station.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | PeakCam resort slug, lowercase kebab-case, e.g. `breckenridge` or `ski-portillo`. Get it from search_resorts. |
| Name | Required | Description |
|---|---|---|
| cams | Yes | |
| name | Yes | |
| slug | Yes | |
| snow | Yes | Null when the resort has never had a snow report. |
| score | No | Today's 0–100 score, once the scorer is live. |
| apiUrl | Yes | |
| season | Yes | |
| license | Yes | URL of the terms that govern reuse. |
| profile | Yes | |
| forecast | No | Latest run per model and point, once stored forecasts are live. |
| location | Yes | |
| stations | No | Observation stations serving the resort, once the station layer is live. |
| updatedAt | Yes | Newest instant among the snow report and cam checks/captures. |
| websiteUrl | Yes | |
| attribution | Yes | |
| measuredNow | No | Latest observation per station, once the station layer is live. |
| canonicalUrl | Yes | The resort's PeakCam page. Cite this. |
| forecastScores | No | Per-model verification at this resort, once computed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world, so the safety profile is handled. The description adds genuinely non-obvious behavioral context: the provenance split between `snotel` (measured at a station near the resort, at station elevation rather than the summit) and `open_meteo` (model estimate for resorts without a station), plus the canonical URL to cite. This data-quality caveat is exactly the kind of disclosure annotations cannot carry.
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 the core purpose, then a compact field inventory, then source semantics. The enumerated field list is longer than strictly necessary given an output schema exists, but every item is informative and there is no filler or hedging.
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?
An output schema exists, so return values need not be explained, yet the description still names the payload fields and adds provenance semantics and a citation URL, which fully covers the complexity of a single-param read tool. Minor gaps remain around freshness/update cadence and invalid-slug behavior, but nothing that would cause a mis-call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single `slug` parameter is fully documented in the schema (format, examples, and where to obtain it via search_resorts). The description adds nothing about the parameter, so the baseline 3 for schema-documented params is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('The latest snow report for one resort') and enumerates exactly what is returned (new snow 24h/48h, base depth, SWE, percent of normal, trend, rating, cam summary, canonical URL). The phrase 'for one resort' cleanly separates it from compare_resorts and find_powder, so an agent can route without opening a schema.
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?
Usage is only implied: the singular 'one resort' and 'latest' suggest this is the point-lookup for current conditions rather than history (get_snow_history) or multi-resort comparison (compare_resorts). No explicit when-to-use/when-not statement or named alternative is given, so the agent must infer the boundary from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily snow depth, snow water equivalent, precipitation accumulation and temperatures for the last 1–30 days at the resort's station (SNOTEL where there is one, Open-Meteo model otherwise), newest first. Use it for "how has the base changed this week" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days back, 1–30. | |
| slug | Yes | PeakCam resort slug, lowercase kebab-case, e.g. `breckenridge` or `ski-portillo`. Get it from search_resorts. |
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| name | Yes | |
| rows | Yes | |
| slug | Yes | |
| count | Yes | |
| source | Yes | |
| station | Yes | |
| generatedAt | Yes | ISO-8601 UTC instant the result was generated. |
| canonicalUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds important behavioral context: the data source varies by resort (SNOTEL vs model), and results are sorted newest first. It doesn't mention rate limits or authentication, but those are less critical for a read-only tool.
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. The key information (metrics, time range, source, ordering) is front-loaded, and the usage tip follows naturally.
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 and rich annotations, so the description needn't explain return values. It covers the data source variability and temporal scope, which are important. It could mention pagination or limits, but the 30-day cap is in the schema. Overall, complete enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are fully documented in the schema. The description implies the 'days' window but doesn't add syntax beyond what the schema provides. Baseline 3 is appropriate because the schema carries the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact metrics (snow depth, SWE, precipitation, temperatures), the time window (1–30 days), the data sources (SNOTEL vs Open-Meteo), and the ordering (newest first). This level of specificity makes it distinct from siblings like get_forecast or get_resort_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?
It gives a clear usage example ("how has the base changed this week"), which implies retrospective questions. However, it doesn't explicitly say when to prefer this over get_resort_conditions or get_forecast, leaving alternatives implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find PeakCam resorts by name (or part of one, or a region) and get their slugs with a one-line snow summary each. Call this first when the user names a resort; then use the slug with the other tools. Covers about 150 resorts in the US, Canada, Chile and Argentina.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return, 1–20. | |
| query | Yes | Resort name or fragment, e.g. `vail`, `big sky`, `portillo`, `tahoe`. Also matches region names. | |
| state | No | US state or Canadian province code (`CO`, `UT`, `BC`), or for the Andes the country name PeakCam lists (`Chile`, `Argentina`). Case-insensitive. | |
| country | No | ISO 3166-1 alpha-2 country code: `US`, `CA`, `CL` or `AR`. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| query | Yes | |
| resorts | Yes | |
| generatedAt | Yes | ISO-8601 UTC instant the result was generated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive and closed-world. The description still adds real context on that closed world: coverage of about 150 resorts across the US, Canada, Chile and Argentina, which bounds what the tool can possibly return.
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: the first states what it returns, the second states when to call it and how to use the output. No filler, and the entry-point guidance 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?
An output schema exists and the input schema is fully documented, so the description's job is routing and scope, both of which it nails. An agent knows when to call it, what it gets back, and how to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents query, state, country and limit with examples. The description's mention of partial names and region matching largely restates what the query schema description already provides, so it adds little beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (find resorts by name/fragment/region) plus the concrete payoff: slugs with a one-line snow summary each. The 'call this first' framing clearly separates it from lookup siblings like get_resort_conditions that presumably require a slug.
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 call it ('when the user names a resort') and what to do with the result ('then use the slug with the other tools'), which is genuinely useful routing. It stops short of stating when NOT to use it, e.g. that it is unnecessary when a slug is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_resorts9 fields changedOutput schema / properties / resorts / items / properties / forecastAdded value: +{
+ "description": "Latest run per model and point, once stored forecasts are live.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "days": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "date": {
+ "description": "YYYY-MM-DD, local to the resort.",
+ "type": "string"
+ },
+ "precipProb": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "0–100."
+ },
+ "snowfallCm": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "snowfallHi": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "snowfallLo": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Low end of the spread across models / members; null for a single model."
+ },
+ "tempMax": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "°C as the models report it."
+ },
+ "tempMin": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "weatherCode": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "WMO weather interpretation code."
+ },
+ "windGust": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "km/h."
+ }
+ },
+ "required": [
+ "date",
+ "snowfallCm",
+ "snowfallLo",
+ "snowfallHi",
+ "tempMax",
+ "tempMin",
+ "precipProb",
+ "windGust",
+ "weatherCode"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "horizonDays": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "type": "string"
+ },
+ "issuedAt": {
+ "type": "string"
+ },
+ "model": {
+ "description": "Model id as the provider names it, or `blend` for PeakCam's skill-weighted blend.",
+ "type": "string"
+ },
+ "point": {
+ "enum": [
+ "summit",
+ "base"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "point",
+ "model",
+ "issuedAt",
+ "horizonDays",
+ "days"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / resorts / items / properties / forecastScoresAdded value: +{
+ "description": "Per-model verification at this resort, once computed.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "biasRatio": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Sum(forecast) / sum(observed); above 1 means the model over-forecasts snow."
+ },
+ "computedAt": {
+ "type": "string"
+ },
+ "day1Mae": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Mean absolute error of the day-1 snowfall forecast, cm."
+ },
+ "day3Mae": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "day7Mae": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "model": {
+ "type": "string"
+ },
+ "periodDays": {
+ "description": "Trailing verification window, days.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "samples": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "model",
+ "periodDays",
+ "day1Mae",
+ "day3Mae",
+ "day7Mae",
+ "samples",
+ "biasRatio",
+ "computedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / resorts / items / properties / location / properties / summitElevationFtAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / resorts / items / properties / location / requiredPrevious value: -[
- "state",
- "region",
- "country",
- "lat",
- "lon",
- "baseElevationFt"
-]New value: +[
+ "state",
+ "region",
+ "country",
+ "lat",
+ "lon",
+ "baseElevationFt",
+ "summitElevationFt"
+]Output schema / properties / resorts / items / properties / measuredNowAdded value: +{
+ "description": "Latest observation per station, once the station layer is live.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "newSnowIn": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "New snow since the previous observation, inches."
+ },
+ "observedAt": {
+ "description": "ISO-8601 instant of the observation.",
+ "type": "string"
+ },
+ "snowDepthIn": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "stationId": {
+ "type": "string"
+ },
+ "sweIn": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tempF": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "windMph": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "stationId",
+ "observedAt",
+ "snowDepthIn",
+ "sweIn",
+ "newSnowIn",
+ "tempF",
+ "windMph"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / resorts / items / properties / profileAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "aliases": {
+ "description": "Other names the resort is known by, e.g. `A-Basin`.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "annualSnowfallIn": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Operator-stated average annual snowfall, inches."
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "descriptionSource": {
+ "anyOf": [
+ {
+ "enum": [
+ "operator",
+ "generated",
+ "editor"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "`operator`: the resort's own copy. `generated`: a model-written draft, labelled as such on the page. `editor`: hand-written by PeakCam."
+ },
+ "liftsTotal": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "longestRunMi": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "passes": {
+ "description": "Multi-resort passes the resort is on.",
+ "items": {
+ "enum": [
+ "ikon",
+ "epic",
+ "mountain-collective",
+ "indy",
+ "power"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "runsTotal": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "skiableAcres": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "trailMapUrl": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The operator's trail map (linked, never copied)."
+ },
+ "verticalFt": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "wikidataId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "runsTotal",
+ "liftsTotal",
+ "skiableAcres",
+ "verticalFt",
+ "annualSnowfallIn",
+ "longestRunMi",
+ "description",
+ "descriptionSource",
+ "trailMapUrl",
+ "wikidataId",
+ "aliases",
+ "passes"
+ ],
+ "type": "object"
+}Output schema / properties / resorts / items / properties / scoreAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "components": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "date": {
+ "description": "YYYY-MM-DD the score is for.",
+ "type": "string"
+ },
+ "rating": {
+ "anyOf": [
+ {
+ "enum": [
+ "great",
+ "good",
+ "fair",
+ "poor"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "scoredBy": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Scorer version, e.g. `score-v1`."
+ }
+ },
+ "required": [
+ "date",
+ "score",
+ "rating",
+ "components",
+ "scoredBy"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Today's 0–100 score, once the scorer is live."
+}Output schema / properties / resorts / items / properties / stationsAdded value: +{
+ "description": "Observation stations serving the resort, once the station layer is live.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "distanceKm": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Great-circle distance from the resort's coordinates."
+ },
+ "elevationFt": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "description": "PeakCam station id (UUID).",
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "snotel",
+ "scan",
+ "nws_obs",
+ "metar",
+ "ghcn",
+ "bc_asws",
+ "eccc",
+ "road_cam"
+ ],
+ "type": "string"
+ },
+ "lat": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "lon": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "rank": {
+ "description": "1 = the preferred station for its role.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "role": {
+ "description": "Where the station sits relative to the resort.",
+ "enum": [
+ "summit",
+ "mid",
+ "base",
+ "approach"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "description": "Provider, e.g. `nrcs`, `nws`, `eccc`, `udot`.",
+ "type": "string"
+ },
+ "sourceId": {
+ "description": "The provider's own identifier (SNOTEL triplet, ICAO code, GHCN id).",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "source",
+ "sourceId",
+ "name",
+ "kind",
+ "role",
+ "lat",
+ "lon",
+ "elevationFt",
+ "distanceKm",
+ "rank"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / resorts / items / requiredPrevious value: -[
- "slug",
- "name",
- "canonicalUrl",
- "apiUrl",
- "location",
- "snow",
- "season",
- "websiteUrl",
- "attribution",
- "license",
- "updatedAt",
- "camCount",
- "liveCamCount"
-]New value: +[
+ "slug",
+ "name",
+ "canonicalUrl",
+ "apiUrl",
+ "location",
+ "profile",
+ "snow",
+ "season",
+ "websiteUrl",
+ "attribution",
+ "license",
+ "updatedAt",
+ "camCount",
+ "liveCamCount"
+]get_resort_cams5 fields changedOutput schema / properties / cams / items / properties / creditAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Attribution line to show with the frame. Null means credit the resort."
+}Output schema / properties / cams / items / properties / kindAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "summit",
+ "mid",
+ "base",
+ "snow-stake",
+ "village",
+ "approach"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "What the cam looks at. Null when not classified."
+}Output schema / properties / cams / items / properties / sourceTermsUrlAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The operator's terms governing reuse of this feed, when known."
+}Output schema / properties / cams / items / properties / timelapsesAdded value: +{
+ "description": "Rendered clips, once PeakCam renders them for this cam.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "frames": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "renderedAt": {
+ "description": "ISO-8601 instant the clip was rendered.",
+ "type": "string"
+ },
+ "stormDate": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "YYYY-MM-DD of the storm a `storm` clip covers."
+ },
+ "url": {
+ "description": "Public MP4 URL.",
+ "type": "string"
+ },
+ "window": {
+ "description": "Which clip: `24h` (rolling day), `storm` (one storm, see `stormDate`), or another label.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "window",
+ "url",
+ "frames",
+ "renderedAt",
+ "stormDate"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / cams / items / requiredPrevious value: -[
- "id",
- "name",
- "elevation",
- "live",
- "lastCheckedAt",
- "stillUrl",
- "capturedAt",
- "embedType",
- "pageUrl",
- "sourceUrl"
-]New value: +[
+ "id",
+ "name",
+ "elevation",
+ "live",
+ "lastCheckedAt",
+ "stillUrl",
+ "capturedAt",
+ "embedType",
+ "pageUrl",
+ "sourceUrl",
+ "kind",
+ "credit",
+ "sourceTermsUrl"
+]get_resort_conditions14 fields changedOutput schema / properties / cams / items / properties / creditAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Attribution line to show with the frame. Null means credit the resort."
+}Output schema / properties / cams / items / properties / kindAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "summit",
+ "mid",
+ "base",
+ "snow-stake",
+ "village",
+ "approach"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "What the cam looks at. Null when not classified."
+}Output schema / properties / cams / items / properties / sourceTermsUrlAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The operator's terms governing reuse of this feed, when known."
+}Output schema / properties / cams / items / properties / timelapsesAdded value: +{
+ "description": "Rendered clips, once PeakCam renders them for this cam.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "frames": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "renderedAt": {
+ "description": "ISO-8601 instant the clip was rendered.",
+ "type": "string"
+ },
+ "stormDate": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "YYYY-MM-DD of the storm a `storm` clip covers."
+ },
+ "url": {
+ "description": "Public MP4 URL.",
+ "type": "string"
+ },
+ "window": {
+ "description": "Which clip: `24h` (rolling day), `storm` (one storm, see `stormDate`), or another label.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "window",
+ "url",
+ "frames",
+ "renderedAt",
+ "stormDate"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / cams / items / requiredPrevious value: -[
- "id",
- "name",
- "elevation",
- "live",
- "lastCheckedAt",
- "stillUrl",
- "capturedAt",
- "embedType",
- "pageUrl",
- "sourceUrl"
-]New value: +[
+ "id",
+ "name",
+ "elevation",
+ "live",
+ "lastCheckedAt",
+ "stillUrl",
+ "capturedAt",
+ "embedType",
+ "pageUrl",
+ "sourceUrl",
+ "kind",
+ "credit",
+ "sourceTermsUrl"
+]Output schema / properties / forecastAdded value: +{
+ "description": "Latest run per model and point, once stored forecasts are live.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "days": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "date": {
+ "description": "YYYY-MM-DD, local to the resort.",
+ "type": "string"
+ },
+ "precipProb": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "0–100."
+ },
+ "snowfallCm": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "snowfallHi": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "snowfallLo": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Low end of the spread across models / members; null for a single model."
+ },
+ "tempMax": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "°C as the models report it."
+ },
+ "tempMin": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "weatherCode": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "WMO weather interpretation code."
+ },
+ "windGust": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "km/h."
+ }
+ },
+ "required": [
+ "date",
+ "snowfallCm",
+ "snowfallLo",
+ "snowfallHi",
+ "tempMax",
+ "tempMin",
+ "precipProb",
+ "windGust",
+ "weatherCode"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "horizonDays": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "type": "string"
+ },
+ "issuedAt": {
+ "type": "string"
+ },
+ "model": {
+ "description": "Model id as the provider names it, or `blend` for PeakCam's skill-weighted blend.",
+ "type": "string"
+ },
+ "point": {
+ "enum": [
+ "summit",
+ "base"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "point",
+ "model",
+ "issuedAt",
+ "horizonDays",
+ "days"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / forecastScoresAdded value: +{
+ "description": "Per-model verification at this resort, once computed.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "biasRatio": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Sum(forecast) / sum(observed); above 1 means the model over-forecasts snow."
+ },
+ "computedAt": {
+ "type": "string"
+ },
+ "day1Mae": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Mean absolute error of the day-1 snowfall forecast, cm."
+ },
+ "day3Mae": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "day7Mae": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "model": {
+ "type": "string"
+ },
+ "periodDays": {
+ "description": "Trailing verification window, days.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "samples": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "model",
+ "periodDays",
+ "day1Mae",
+ "day3Mae",
+ "day7Mae",
+ "samples",
+ "biasRatio",
+ "computedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / location / properties / summitElevationFtAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / location / requiredPrevious value: -[
- "state",
- "region",
- "country",
- "lat",
- "lon",
- "baseElevationFt"
-]New value: +[
+ "state",
+ "region",
+ "country",
+ "lat",
+ "lon",
+ "baseElevationFt",
+ "summitElevationFt"
+]Output schema / properties / measuredNowAdded value: +{
+ "description": "Latest observation per station, once the station layer is live.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "newSnowIn": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "New snow since the previous observation, inches."
+ },
+ "observedAt": {
+ "description": "ISO-8601 instant of the observation.",
+ "type": "string"
+ },
+ "snowDepthIn": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "stationId": {
+ "type": "string"
+ },
+ "sweIn": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tempF": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "windMph": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "stationId",
+ "observedAt",
+ "snowDepthIn",
+ "sweIn",
+ "newSnowIn",
+ "tempF",
+ "windMph"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / profileAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "aliases": {
+ "description": "Other names the resort is known by, e.g. `A-Basin`.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "annualSnowfallIn": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Operator-stated average annual snowfall, inches."
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "descriptionSource": {
+ "anyOf": [
+ {
+ "enum": [
+ "operator",
+ "generated",
+ "editor"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "`operator`: the resort's own copy. `generated`: a model-written draft, labelled as such on the page. `editor`: hand-written by PeakCam."
+ },
+ "liftsTotal": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "longestRunMi": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "passes": {
+ "description": "Multi-resort passes the resort is on.",
+ "items": {
+ "enum": [
+ "ikon",
+ "epic",
+ "mountain-collective",
+ "indy",
+ "power"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "runsTotal": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "skiableAcres": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "trailMapUrl": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The operator's trail map (linked, never copied)."
+ },
+ "verticalFt": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "wikidataId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "runsTotal",
+ "liftsTotal",
+ "skiableAcres",
+ "verticalFt",
+ "annualSnowfallIn",
+ "longestRunMi",
+ "description",
+ "descriptionSource",
+ "trailMapUrl",
+ "wikidataId",
+ "aliases",
+ "passes"
+ ],
+ "type": "object"
+}Output schema / properties / scoreAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "components": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "date": {
+ "description": "YYYY-MM-DD the score is for.",
+ "type": "string"
+ },
+ "rating": {
+ "anyOf": [
+ {
+ "enum": [
+ "great",
+ "good",
+ "fair",
+ "poor"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "scoredBy": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Scorer version, e.g. `score-v1`."
+ }
+ },
+ "required": [
+ "date",
+ "score",
+ "rating",
+ "components",
+ "scoredBy"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Today's 0–100 score, once the scorer is live."
+}Output schema / properties / stationsAdded value: +{
+ "description": "Observation stations serving the resort, once the station layer is live.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "distanceKm": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Great-circle distance from the resort's coordinates."
+ },
+ "elevationFt": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "description": "PeakCam station id (UUID).",
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "snotel",
+ "scan",
+ "nws_obs",
+ "metar",
+ "ghcn",
+ "bc_asws",
+ "eccc",
+ "road_cam"
+ ],
+ "type": "string"
+ },
+ "lat": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "lon": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "rank": {
+ "description": "1 = the preferred station for its role.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "role": {
+ "description": "Where the station sits relative to the resort.",
+ "enum": [
+ "summit",
+ "mid",
+ "base",
+ "approach"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "description": "Provider, e.g. `nrcs`, `nws`, `eccc`, `udot`.",
+ "type": "string"
+ },
+ "sourceId": {
+ "description": "The provider's own identifier (SNOTEL triplet, ICAO code, GHCN id).",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "source",
+ "sourceId",
+ "name",
+ "kind",
+ "role",
+ "lat",
+ "lon",
+ "elevationFt",
+ "distanceKm",
+ "rank"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "slug",
- "name",
- "canonicalUrl",
- "apiUrl",
- "location",
- "snow",
- "season",
- "cams",
- "websiteUrl",
- "attribution",
- "license",
- "updatedAt"
-]New value: +[
+ "slug",
+ "name",
+ "canonicalUrl",
+ "apiUrl",
+ "location",
+ "profile",
+ "snow",
+ "season",
+ "cams",
+ "websiteUrl",
+ "attribution",
+ "license",
+ "updatedAt"
+]compare_resortsfind_powderget_forecastget_opening_datesget_resort_camsget_resort_conditionsget_snow_historysearch_resortsLive verified resort snow, forecasts, powder search, trip planning & grounded Q&A for 430+ resorts.
Live ski snow, multi-model forecasts, powder rankings & a grounded Answer Engine for 500+ resorts.
Ski resort conditions, forecasts, avalanche danger, sun, routes and snow history for 5,000+ resorts.
Free snow reports, forecasts and season history for ~400 US and Canada ski resorts, with citations.
Add one secure layer between your agents and this server.
