Skip to main content
Glama
Sign In

ROVE Snow Forecast

by com.rove-ski
OverviewDiscussionsAdmin

Read Official Backcountry Avalanche Danger

get_avalanche_danger
Read-onlyIdempotent

Get the official backcountry avalanche danger rating (1 Low to 5 Extreme) from the regional US avalanche center whose forecast zone covers one ski resort; use get_conditions instead for in-bounds snow depth and lift status, and get_forecast for upcoming snowfall. Returns center, zone, rating, travel advice, valid period and the official forecast link from the Avalanche.org public map layer (cached up to 1 hour). Ratings describe terrain outside resort boundaries and never replace ski patrol status; resorts outside US center coverage return not_covered with no invented rating. Read-only results use in for snowfall, F for temperature, and include canonicalUrl and observedAt.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "resort": "<resort>"
    },
    "name": "get_avalanche_danger"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoOutput language: en or zh. Default en; untranslated upstream text is unavailable in English.
resortYesResort name, slug, or resort: ID from search_resorts. Required unless explicitly optional.

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), and the description adds genuinely useful behavior beyond them: caching up to 1 hour, the not_covered fallback with no invented rating, and the source layer (Avalanche.org public map). It loses a point for the trailing sentence about 'in for snowfall, F for temperature, canonicalUrl and observedAt', which does not match the enumerated avalanche return fields and reads as boilerplate from a weather tool.

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

Conciseness3/5

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

Front-loaded with purpose and alternatives, which is good, but it is one dense run-on sentence chain and the final clause about units and canonicalUrl/observedAt does not earn its place in an avalanche tool. That sentence adds confusion rather than information and should be cut or corrected.

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?

There is no output schema, so the description carries the return burden and does so: center, zone, rating, travel advice, valid period, official forecast link, plus the not_covered case. Completeness is slightly undercut by the incongruous units/metadata sentence, which muddies rather than clarifies what actually comes back.

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 baseline is 3 regardless. The description adds only the 'one ski resort' cardinality hint (single resort, not a list); it says nothing about the lang parameter or the resort name/slug/ID forms, both of which are already handled by the schema.

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 and resource (get the official backcountry avalanche danger rating, 1-5 scale) and immediately scopes it to 'the regional US avalanche center whose forecast zone covers one ski resort'. It explicitly names the two sibling tools it is not (get_conditions, get_forecast), so an agent can route correctly 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.

Usage Guidelines5/5

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

Gives explicit alternatives with the condition that selects each: in-bounds snow depth/lift status goes to get_conditions, upcoming snowfall goes to get_forecast. It also states the boundary of applicability (ratings describe terrain outside resort boundaries, never replace ski patrol status) and the out-of-scope outcome (resorts outside US center coverage return not_covered).

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