Skip to main content
Glama

ROVE Snow Forecast

Find Resorts with Forecast Powder

find_powder
Read-onlyIdempotent

Rank ski resorts by forecast snowfall over the next 1 to 15 days starting today; use plan_trip instead for a specific future calendar date range (start to end). Read-only results use in for snowfall, F for temperature, and include canonicalUrl and observedAt.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_powder"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoRolling forecast window of 1 to 15 days starting TODAY at the resort. Default 5; undated or stale coverage is unavailable.
langNoOutput language: en or zh. Default en; untranslated upstream text is unavailable in English.
passNoMulti-resort pass filter. Default all passes when optional; legacy names and MC are normalized.
limitNoMaximum results returned. Default 20; full membership counts are reported separately.
offsetNoZero-based result offset for pagination. Default 0.
regionNoRegion name or hub slug, such as Lake Tahoe or tahoe. Default all regions.
countryNoISO country filter. Default all countries.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description still adds real value beyond them by disclosing output units (in for snowfall, F for temperature) and two returned fields (canonicalUrl, observedAt), though it says nothing about ordering ties or result volume.

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

Conciseness4/5

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

Two sentences, front-loaded with the core ranking behavior and the alternative-tool escape hatch before the output-format note. The trailing clause is telegraphic in places ('use in for snowfall'), which costs a little readability but wastes no space.

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

Completeness4/5

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

For a 7-parameter, all-optional list tool with no output schema, the definition covers the distinguishing scope, the alternative tool, and the key output conventions. Remaining gaps, such as pagination interaction between limit/offset and full membership counts, are minor since the schema documents those parameters directly.

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

Parameters3/5

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

Schema description coverage is 100%, so defaults, ranges, and enums are already fully documented per parameter. The description reinforces the rolling-window semantics of 'days' but adds no format or edge-case detail the schema does not already carry, making the baseline 3 appropriate.

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?

States a specific verb (rank), resource (ski resorts), and ranking measure (forecast snowfall over 1-15 days from today). The scope 'starting today' immediately separates it from the sibling plan_trip, which handles future calendar date ranges.

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

Usage Guidelines4/5

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

Explicitly routes the agent to plan_trip for a specific future start-to-end date range, which is the main ambiguity here. It does not address how this differs from get_forecast, compare_resorts, or search_resorts, so a few sibling distinctions are left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.