SnowSure — Snow & Ski

Typical snow by month

get_monthly_snow

Read-onlyIdempotent

Typical snow for a resort MONTH BY MONTH, from ~30 years of ERA5 reanalysis — average snowfall, snow days, base and peak depth, and biggest storm, plus per-season totals. Use for date-choosing questions: 'what is February usually like at Vail', 'when should I go', 'is January or March better'. This is HISTORY, not a forecast and not a prediction — for the next 14 days use get_weather_forecast, and for right now use get_resort. Months with too little history are withheld rather than shown thin; every month returned carries yearsTracked so you can cite the evidence.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	No	Resort slug or name, e.g. "portillo" or "Portillo". Required unless `resort` is given.
`resort`	No	Same as `slug`: the resort slug or name. Pass either one.

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).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 16, 2026

addedInput schema / properties / resort

Added value: +{
+  "description": "Same as `slug`: the resort slug or name. Pass either one.",
+  "type": "string"
+}

changedInput schema / properties / slug / description

Previous value: -"Resort slug"New value: +"Resort slug or name, e.g. \"portillo\" or \"Portillo\". Required unless `resort` is given."

removedInput schema / required
```
Removed value: -[
-  "slug"
-]
```

AddedJul 29, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds valuable behavioral context: months with insufficient history are withheld, and returned months carry yearsTracked for evidence. This goes beyond annotations and helps set expectations about data completeness and reliability.

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 well-structured and front-loaded: purpose, metrics, use cases, caveats, and alternatives each have a clear sentence. While longer than minimal, every sentence earns its place and directs the agent to correct invocation and expectations.

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?

The description covers data source, time range, output contents, typical use cases, non-forecast status, alternative tools, and data-quality caveats. With an output schema present and annotations covering safety, nothing needed for correct invocation or interpretation appears missing.

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% and both parameters (slug and resort) are sufficiently documented in the schema. The description does not add extra parameter semantics, but it does not need to since the schema carries the burden. 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 states a specific purpose: typical snow for a resort month by month, from ERA5 reanalysis, and lists the specific metrics returned. It clearly distinguishes itself from siblings like get_weather_forecast and get_resort by explicitly positioning itself as historical climate data.

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?

The description explicitly tells when to use this tool ('date-choosing questions') with concrete examples, and explicitly says what it is NOT for ('HISTORY, not a forecast and not a prediction'). It names alternative tools for those cases, leaving no ambiguity about tool selection.

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

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

Need Help?