SnowSure — Snow & Ski

ML/AI trends

get_ml_trends

Read-onlyIdempotent

Fetch SnowSure-unique ML/AI trend datasets from the public REST API. Use for powder-day leaders, bluebird-day leaders, bluebird predictions, improving/stable/declining score pulse, per-model accuracy weights, daily SnowSure score component history, ML extended outlook (days 8–14), global forecast trust, and powder/bluebird event logs. Start with dataset=catalog. Its leaderboards read CURRENT-season counters and are global — they take no season and no country/state filter. For a past season, or for any ranking scoped to a state, province, country or region ("most snow days in Maine last season", "rank BC resorts by season snowfall"), use get_season_leaderboard instead. Prefer get_insights for narrative intelligence cards; use this for raw rankings and time series.

Input Schema

TableJSON Schema

Name	Required	Description
`days`	No	Lookback days for score_components (default 30, max 365).
`slug`	No	Resort slug — required for score_components, vs_last_year, and season_stats; optional for extended_outlook (per-resort).
`limit`	No	Max rows for leaderboards or snow_events (default 25, max 100).
`minCm`	No	Minimum ML days 8–14 snow (cm) when dataset=extended_outlook leaderboard (default 0).
`stats`	No	When dataset=snow_events, return season aggregates instead of events.
`resort`	No	Resort slug filter when dataset=snow_events.
`dataset`	Yes	Trend dataset to fetch. catalog lists all endpoints; powder_days / bluebird_days = season leaderboards; score_components needs slug.
`openOnly`	No	When dataset=extended_outlook, filter to open resorts only (default true).
`eventType`	No	Filter snow_events by event type.
`minSpread`	No	Minimum 14d model spread (cm) when dataset=forecast_disagreement (default 5).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`markdown`	No	Human-readable markdown summary of the tool result (may be omitted when structuredContent carries a typed payload; content[0].text always has the prose).

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that this is a 'public REST API', implying no auth required and free access, which is a behavioral trait beyond the annotations. No contradictions.

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

Conciseness5/5

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

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

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

Completeness5/5

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

Given the complexity (10 parameters, 13 dataset options, output schema exists), the description covers all critical aspects: what the tool does, how to start, dataset scope, dependencies, and when to choose alternatives. It is complete for an AI agent to use correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining usage patterns: 'Start with dataset=catalog', 'score_components needs slug', and 'leaderboards read CURRENT-season counters'. This goes beyond the schema's parameter descriptions.

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

Purpose5/5

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

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

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

Usage Guidelines5/5

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

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

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

All SnowSure — Snow & Ski tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation2/5

Multiple tool clusters have unclear boundaries: get_resort overlaps with get_resort_info and get_resort_photos, ask_snowdata competes with compare_resorts and the El Niño tools, and get_snow_history / get_season_leaderboard / get_insights cover similar retrospective ground. The descriptions try hard to route agents, but with 45 tools an agent will frequently have to choose between near-equivalent options.

Naming Consistency4/5

Most tools follow a clear verb_noun snake_case pattern: get_resort_info, compare_resorts, find_best_powder, book_lodging, save_resort. Minor deviations like ask_snowdata and the very similar get_resort vs get_resort_info names prevent a 5, but overall the naming convention is predictable.

Tool Count2/5

45 tools is well above the 25+ threshold and puts a heavy selection burden on the agent. While the domain is broad, many tools are narrow variations on conditions, history, road data, or trip planning that could be consolidated or exposed as configurable parameters.

Completeness4/5

The toolkit covers an impressively wide lifecycle: resort discovery, photos, live conditions, forecasts, history, comparisons, passes, flights, lodging, road status, alerts, and user saved resorts. Minor gaps exist such as no lift-ticket booking, no lesson/rental booking, and flight search only produces links rather than a booking flow, but agents can generally complete core snow-trip workflows.

Resources

Need Help?