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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower; the description nonetheless adds real behavioral context: the 30-winter vs 10-winter breakdown, the recent-decade-as-percent-of-30 computation, the >10% divergence note, and an explicit no-station failure mode. It does not mention rate limits or data-availability windows, keeping it from 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.

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

Front-loads the returned metrics and scope, then use cases, with no filler. The first sentence is a dense run-on covering four metrics across two windows, which taxes readability but every clause conveys distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be explained. The description covers what is computed, the comparison semantics, and the failure mode, leaving little an agent needs missing. Minor gaps around data latency are acceptable given the structured output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Single parameter with 100% schema description coverage, which already documents slug format and how to obtain it via search_resorts. The description adds nothing beyond the schema, so baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (compute/return) and resource (per-calendar-month climatology) with precise scope: snowfall, snow days ≥1in, depth, biggest storm, over 30 complete winters plus the recent 10. An agent can distinguish it from siblings like get_season_stats, get_snow_history, or get_percent_of_normal without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives concrete use cases ('which month is snowiest', 'how much does it usually snow in January') and a failure condition ('Resorts without a station normal answer available: false'). No alternatives or siblings are named, so it stops short of full when-not guidance.

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