Live ski lift status for 260+ resorts from their own lift boards, with snow, weather and webcams.
Scored across 7 tools
Each tool targets a distinct axis: single resort (ski_get_resort_status), user-picked set (ski_compare_resorts), global/region filter (ski_open_now), aggregate region (ski_get_region_summary), proximity (ski_find_nearby_resorts), discovery (ski_search_resorts, ski_list_regions). The only real overlap is between ski_compare_resorts and ski_open_now, since both rank resorts by running-lift counts, but descriptions explicitly clarify when to use each.
All names share a ski_ prefix and use verb_noun phrasing (compare_resorts, get_resort_status, list_regions, search_resorts, find_nearby_resorts). The single deviation is ski_open_now, which omits an explicit verb, a minor break in an otherwise predictable pattern.
Seven tools is well-scoped for a read-only resort-status server, and each one covers a distinct query shape (single, set, region aggregate, proximity, discovery). No tool feels redundant or padded.
The surface covers discovery, live per-lift status, region rollups, comparisons, proximity, and open-now filtering, which is solid for the domain. Minor gaps exist, such as no dedicated season-pass or lift-level listing endpoint and no way to enumerate webcams/roads apart from the all-in-one status call, but these are workable via existing tools.
Side-by-side running-lift counts for up to 10 resorts, sorted by share of lifts running. Operator-reported; a resort without a count says whether it listed no lifts or could not be read.
| Name | Required | Description | Default |
|---|---|---|---|
| resorts | Yes | Resort ids or names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint false, so safety is covered. The description adds valuable behavioral context: data is operator-reported, and missing counts are explained as either no lifts listed or unreadable. It does not mention rate limits or output format, but for a read-only tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first sentence front-loads the core purpose and sorting criterion, and the second adds critical data-handling context. Both sentences earn their 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 simple schema (one parameter, no output schema) and annotations, the description covers purpose, sorting, data source, and missing-data behavior. It could briefly mention the response structure (e.g., list of resorts with counts), but it is largely complete 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%, with the 'resorts' parameter fully described as 'Resort ids or names'. The description reiterates the 10-item limit but adds no new syntax or format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compare) and resource (resorts) with a clear focus on running-lift counts and sorting. However, it does not explicitly name a sibling tool or differentiate itself from ski_get_resort_status, though the comparison nature makes it distinguishable.
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 by specifying 'up to 10 resorts' and sorting, but it does not explicitly state when to use this tool versus alternatives like ski_get_resort_status or ski_search_resorts. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resorts closest to a point, by straight-line distance. Optionally fetches live open-lift counts for each.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| max_km | No | Ignore resorts farther than this | |
| latitude | Yes | ||
| longitude | Yes | ||
| include_status | No | Also fetch live lift counts (one request per resort) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld), so the bar is lower. The description still adds real behavioral value: it discloses that distances are straight-line (not travel distance) and that lift counts are an opt-in live fetch, implying extra per-resort requests and latency beyond the schema's terse note.
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 short sentences with no filler; the core spatial semantics are front-loaded and the optional behavior is appended as a secondary clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should convey what comes back; it identifies the ordering metric and the optional status enrichment, which is close to sufficient. Missing pieces are minor: tie-breaking, whether results include distance values, and the cost of the optional live fetch.
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 only 40%: max_km and include_status are documented in the schema, while latitude, longitude, and limit carry no descriptions. The description implies sorting by distance and an optional status fetch, but adds no units, ordering, or result-count semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource (resorts), the spatial criterion (closest to a point), and the metric (straight-line distance), which is enough to separate it from name-based siblings like ski_search_resorts. It lacks an explicit verb and never names a sibling, so an agent must infer the contrast rather than read it.
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 implied: this is the tool for proximity queries when you have coordinates, as opposed to search or status tools. However, there is no explicit when-to-use statement, no exclusion (e.g. 'do not use for name search'), and no mention of alternatives such as ski_search_resorts or ski_compare_resorts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open-lift totals for a whole region (a tag from ski_list_regions, e.g. "Utah", "Dolomiti"), with each resort's count. Fetches every resort in the region, so it is limited to 40 resorts.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | Region tag, case-insensitive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld), so the description's value-add is the behavioral constraint: it fetches every resort in the region and is capped at 40 resorts, which signals potential latency and truncation. It doesn't say what happens when the cap is exceeded (error vs. partial results), leaving one gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the resource and scope front-loaded and the 40-resort limitation placed last as a caveat. Every clause carries information the agent needs.
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?
No output schema exists, but the description conveys the return shape (open-lift totals plus each resort's count), so the agent knows what to expect. The only missing detail is the failure mode when a region exceeds 40 resorts, a minor but real gap for a tool whose stated limit is the key constraint.
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 'Region tag, case-insensitive', so the baseline is 3. The description adds real value by giving concrete example tags ("Utah", "Dolomiti") and pointing to ski_list_regions as the authoritative source, which the schema does not.
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 aggregation verb and resource ('open-lift totals for a whole region') plus the per-resort breakdown, so the agent knows this is a regional rollup rather than a single-resort lookup like ski_get_resort_status. It also names ski_list_regions as the origin of the region tag, separating the two tools cleanly.
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 tells the agent exactly where to get a valid region value (a tag from ski_list_regions) and discloses the 40-resort cap that governs when this call is appropriate. It stops short of naming an alternative for large regions or when-not-to-use guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything known about one resort: live lift status (each lift open, on hold, scheduled, or closed, read from the resort's own site), opening date if the season has not started, a model weather forecast, model snow estimates (depth and snowfall over the last 7/30 and next 7 days at the lower and upper lift elevations), official road conditions on the access routes where a source exists (California chain controls, the road to Farellones), and webcams. Lift data is operator-reported and comes with an as-of time and a state: reported (the board listed lifts), none_listed (it listed none, usually off-season; not the same as closed) or source_error (it could not be read; unknown). Accepts an id or a resort name.
| Name | Required | Description | Default |
|---|---|---|---|
| resort | Yes | Resort id (e.g. "palisades") or name (e.g. "Palisades Tahoe") | |
| include_lifts | No | List every lift by name; set false for just the counts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical behavioral context: data comes from the resort's own site, lift states include reported/none_listed/source_error with precise semantics (none_listed is not the same as closed; source_error means unknown), and an as-of time is provided. It also distinguishes model-derived forecasts and snow estimates from official road conditions, which is exactly the kind of provenance an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then efficiently lists all returned content in a single long sentence with colons and parentheses. It is dense but every clause adds substantive information; only slightly better visual structuring could push it higher.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only two simple parameters, the description compensates thoroughly by enumerating every category of returned data, including lift state semantics and data provenance. An agent knows exactly what to expect from a call without needing a response 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%, so both parameters are already documented in the input schema. The description only restates that an id or resort name is accepted and does not mention include_lifts or add any syntax or format details beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb+resource: 'Everything known about one resort', then enumerates live lift status, forecasts, snow estimates, road conditions, and webcams. This scope clearly differentiates it from sibling tools like ski_get_region_summary, ski_compare_resorts, and ski_search_resorts, even without naming 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?
Usage is implied by the scope statement 'Everything known about one resort', so an agent can infer this is the detailed status endpoint for a known resort. However, there is no explicit guidance on when to prefer it over ski_open_now, ski_search_resorts, or ski_compare_resorts, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the region tags resorts are grouped by (states, countries, ranges), with resort counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured fields. The description adds that results include resort counts, which is modest but useful context; it does not describe ordering, pagination, or whether the output is flat or nested.
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?
One efficient sentence with the core purpose front-loaded and no filler. Every phrase earns its place by naming the grouping types and the count inclusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and annotations covering the safety profile, the description is sufficient to call the tool. It explains what is listed and that counts are returned, though it could be slightly richer about the shape of the returned regions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. The description adds no parameter detail, but none is needed because there are no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (List) and resource (region tags), and clarifies what a region is (states, countries, ranges) plus that counts are included. It does not distinguish this from the closely named sibling ski_get_region_summary, which an agent might otherwise conflate with it.
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 implied by the listing nature of the tool, but there is no explicit guidance on when to choose this over ski_get_region_summary or ski_search_resorts. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ski resorts whose own lift board lists running lifts right now, most running lifts first, optionally within a region (a country such as "Chile", a state such as "Colorado", a season pass such as "Ikon Pass" or "Epic Pass", or any tag from ski_list_regions). Uses the latest check of every resort, made about every 90 minutes, across all resorts at once. A running lift is what the board says, not that the ski season has started: out of season some boards list sightseeing lifts or are not updated. Each line gives its as-of time. Use ski_get_resort_status for a live, per-lift answer about one resort.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| region | No | Country, state or region tag, case-insensitive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotations, it discloses ordering, update cadence of about every 90 minutes, all-resorts scope, and that each line includes an as-of time. It also warns that 'running lift' means what the board says, not that the season has started, and that out-of-season boards may list sightseeing lifts or be stale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then adds ordering, region options, cadence, caveat, and alternative in a logical order. It is somewhat dense, especially the region parenthetical, but every sentence provides actionable context rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, it explains the key behavior: current lift-board status, ordering, region filtering, update cadence, as-of timestamps, and the out-of-season caveat. It is nearly complete, though it leaves limit/pagination behavior to the schema and does not describe the full return fields.
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 adds useful meaning for region beyond the schema, with examples such as country, state, season pass, and ski_list_regions tags. However, the limit parameter is not mentioned at all, and schema coverage is only 50%, so the description only partially compensates for the undocumented parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and condition: ski resorts whose own lift board lists running lifts right now, ordered by most running lifts. It also distinguishes itself from ski_get_resort_status, which gives a live per-lift answer for one resort.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context for a broad current-open-resorts query and explicitly names ski_get_resort_status as the alternative for a live per-lift answer about one resort. It also points to ski_list_regions for valid region tags, though it does not cover other ski siblings such as ski_search_resorts or ski_compare_resorts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the ski resorts this server covers, by name, id, region tag (e.g. "Colorado", "Alps", "Lake Tahoe") or season pass ("Ikon Pass", "Epic Pass"). Returns resort ids to pass to the other tools. Leave query empty to list everything.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Name, id, or region, case-insensitive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds two useful traits (ids are meant for chaining; empty query returns the full list) but says nothing about the limit parameter's default of 25 or its 250 cap, which is the main undisclosed behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, front-loaded with the searchable keys and followed immediately by the return-value and empty-query behavior. Every clause carries information the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly states what comes back (resort ids for chaining). For a two-parameter list tool with read-only annotations this is nearly complete; only the limit/pagination semantics are unaddressed.
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 only 50% (limit is undocumented), so the description must compensate, and it does: it enumerates the accepted query dimensions and gives concrete examples ('Colorado', 'Alps', 'Ikon Pass'), including the season-pass dimension that the schema's own query description omits. It does not explain limit/pagination, which is the remaining gap.
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 (find) and resource (ski resorts) with the exact lookup keys: name, id, region tag, and season pass. The phrase 'the ski resorts this server covers' also scopes it against the broader park/campground siblings, and it is clearly separable from ski_find_nearby_resorts and ski_list_regions.
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?
Tells the agent the downstream purpose ('Returns resort ids to pass to the other tools') and the empty-query behavior ('Leave query empty to list everything'), which is genuinely actionable context. It stops short of naming alternatives or exclusions, e.g. when to prefer ski_find_nearby_resorts for geographic search.
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.
ski_compare_resortsski_find_nearby_resortsski_get_region_summaryski_get_resort_statusski_list_regionsski_open_nowski_search_resortsLive snow reports, SNOTEL measurements, webcams and powder rankings for 150 ski resorts.
Live status of the physical world: ski lifts, theme park rides, national parks, campgrounds, surf.
Live verified resort snow, forecasts, powder search, trip planning & grounded Q&A for 430+ resorts.
Ski resort conditions, forecasts, avalanche danger, sun, routes and snow history for 5,000+ resorts.
Add one secure layer between your agents and this server.