Skip to main content
Glama
Sign In

ROVE Snow Forecast

by com.rove-ski
OverviewDiscussionsAdmin

Read Season Opening and Closing Targets

get_opening_dates
Read-onlyIdempotent

List ski resort opening dates, closing targets, and season operating status by region or pass; use get_conditions instead for one resort's live lift and snow depth details. 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": "get_opening_dates"
  }
}

Input Schema

NameRequiredDescriptionDefault
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.2/5.0
Behavior4/5

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 description's job is to add context. It does, disclosing output conventions ('in' for snowfall, 'F' for temperature) and guaranteed fields (canonicalUrl, observedAt). The snowfall/temperature note sits oddly on an opening-dates tool and is not explained, which keeps it below a 5.

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

Conciseness4/5

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

Two sentences, front-loaded with purpose followed by the alternative routing rule, with no filler. The trailing clause about units and fields is relevant context but slightly mismatched to the tool's stated subject, a small efficiency and coherence cost.

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?

With no output schema, the description carries the burden of describing returns and does so by naming key fields (canonicalUrl, observedAt) and unit conventions. Combined with 100% schema coverage on six parameters and annotations covering safety, 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.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents lang, pass, limit, offset, region, and country in detail, including defaults and enum normalization. The description only echoes the filter dimensions ('by region or pass') and adds no syntax, precedence, or combination semantics beyond that, so the baseline 3 is 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?

The description opens with a specific verb and resource set: 'List ski resort opening dates, closing targets, and season operating status by region or pass.' It immediately disambiguates from the nearest sibling by naming get_conditions as the tool for a single resort's live lift and snow data, so an agent can route correctly without opening either schema.

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?

It provides one explicit alternative ('use get_conditions instead for one resort's live lift and snow depth details'), which is the most likely confusion for this tool. It does not address other plausible alternatives such as compare_resorts or plan_trip, so the routing guidance is clear but not exhaustive.

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

All ROVE Snow Forecast toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources