Skip to main content
Glama

ROVE Snow Forecast

Compare Ski Resorts Side by Side

compare_resorts
Read-onlyIdempotent

Compare 2 to 5 specific named ski resorts side by side across forecast snowfall, snowpack, lift status, pass, and verified accuracy; use find_powder instead when discovering top resorts across a whole region or pass. 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": {
      "resorts": "<resorts>"
    },
    "name": "compare_resorts"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoOutput language: en or zh. Default en; untranslated upstream text is unavailable in English.
resortsYesTwo to five distinct resort names, slugs or resort: IDs. Required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description does not need to repeat safety semantics. It adds useful behavioral context by noting the result units ('in' for snowfall, 'F' for temperature) and returned fields ('canonicalUrl' and 'observedAt'), plus the 2–5 resort scope. It does not cover error behavior or result ordering, but with the annotations carrying the safety profile this is strong.

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 definition is two sentences with no wasted wording. It front-loads the core purpose and scope, then adds the alternative tool and output-format details in a tight second sentence.

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?

For a simple two-parameter comparison tool with rich annotations and no output schema, the description supplies enough information to select and invoke it correctly. It names the comparison dimensions, the 2–5 resort limit, the relevant alternative, and key result units and fields.

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 input schema already documents the resorts array, its 2–5 item bounds, accepted name/slug/ID formats, and the lang enum. The description reinforces the 2–5 specific-resort requirement but adds little syntax or meaning beyond what the schema provides, so the baseline of 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 uses a specific verb and resource ('Compare 2 to 5 specific named ski resorts side by side') and enumerates the comparison dimensions: forecast snowfall, snowpack, lift status, pass, and verified accuracy. It also explicitly names the sibling tool find_powder as the alternative, so an agent can distinguish the two 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 Guidelines5/5

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

The description clearly states when to use this tool: comparing a small set of specific named resorts. It also states when not to use it, directing the agent to find_powder for discovering top resorts across a region or pass.

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.