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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description goes beyond them by disclosing the underlying models, the self-hosted provenance, and importantly the confidence asymmetry between days 1-7 and 8-16, which materially affects how an agent should present results.

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?

Two dense sentences, front-loaded with the core capability, then the variable list, then the source and the confidence caveat. No filler; every clause carries information an agent can act on.

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?

With no output schema, the description compensates by enumerating the returned fields (snowfall, temperatures, freezing level, gusts, precipitation probability) and their availability limits. It is nearly complete; the only gap is guidance on the resort parameter format.

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?

Schema description coverage is 0%, so the description must carry parameter meaning. It conveys the 16-day ceiling and the 1-7 vs 8-16 split, implicitly documenting the days parameter, but says nothing about the required resort parameter's accepted values/format and never mentions the default or lower bound.

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 (Get), resource (16-day daily outlook), the exact variables returned, and the data sources (GFS/ECMWF IFS). It explicitly distinguishes itself from get_forecast by noting the days 1-7 overlap, so an agent can tell the two apart.

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?

Clearly frames when this tool is worthwhile: days 8-16 as low-confidence trend guidance, and it flags that days 1-7 duplicate get_forecast. It stops short of an explicit directive ('use get_forecast for days 1-7'), but the routing intent is unmistakable.

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