Skip to main content
Glama

SnowSure — Snow & Ski

by ai.snowsure
OverviewDiscussionsAdmin

Trip window odds

get_trip_window
Read-onlyIdempotent

Historical odds for a SPECIFIC trip window at one resort — 'Whistler on March 27', 'Vail Jan 10–17'. From ~30 years of ERA5 monthly history it blends the window's months (weighted by days) into: the snow-day probability (the headline — for a short window how OFTEN it snows beats how MUCH falls in a season), window-scaled expected snowfall and typical base depth, the same window across the last 5 individual seasons, and the best nearby month (±1) by snow-day odds. Window max 31 days; dates are YYYY-MM-DD. This is HISTORY, not a forecast and not a prediction — for the next 14 days use get_weather_forecast, and for a whole-month question use get_monthly_snow. Windows with under 5 tracked seasons return insufficient rather than thin odds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoWindow end date, YYYY-MM-DD (defaults to start for a single day)
slugNoResort slug or name, e.g. "portillo" or "Portillo". Required unless `resort` is given.
startYesWindow start date, YYYY-MM-DD
resortNoSame as `slug`: the resort slug or name. Pass either one.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
markdownNoHuman-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.

  1. Changed3 schema fields changed
    • changedInput schema / properties / resort / description
      Previous value: -"Resort slug or name, e.g. \"whistler-blackcomb\" or \"Whistler\""New value: +"Same as `slug`: the resort slug or name. Pass either one."
    • addedInput schema / properties / slug
      Added value: +{
+  "description": "Resort slug or name, e.g. \"portillo\" or \"Portillo\". Required unless `resort` is given.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "resort",
-  "start"
-]New value: +[
+  "start"
+]
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive; description adds methodology (ERA5 monthly history, day-weighted blending), the window-length cap (31 days), and the behavior for under-5-tracked seasons. The honesty about being history rather than prediction goes beyond the structured metadata.

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?

Dense but efficient; each clause adds information: methodology, outputs, constraints, alternatives, and edge-case return behavior. Front-loaded with purpose and examples, with no filler or repetition of schema defaults.

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?

Covers data provenance, output components, the history-vs-forecast distinction, alternative tools, and edge cases. Since an output schema exists, not detailing return structure is acceptable; nothing an agent needs to invoke it correctly is missing.

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 covers all four parameters at 100%, so baseline 3; the description adds the crucial 31-day max constraint and clarifies that input is one resort with a date range. It doesn't restate schema details but elevates the schema's semantics with usage constraints.

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 'Historical odds for a SPECIFIC trip window at one resort' – a specific verb/resource/scope. Examples ('Whistler on March 27') and explicit exclusions ('for the next 14 days use get_weather_forecast') distinguish it from siblings without opening schemas.

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 differentiates from get_weather_forecast (next 14 days) and get_monthly_snow (whole-month), and clarifies the tool is history, not forecast/prediction. Also notes the data insufficiency edge case ('return insufficient rather than thin odds'). No ambiguity about when to call it.

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