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

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful non-obvious context: data comes from each resort's own lift board, is refreshed roughly every 90 minutes, and each line carries an as-of time — i.e., it discloses staleness characteristics. It stops short of noting behavior on empty results or rate limits.

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?

Three sentences, front-loaded with the core purpose, then freshness semantics, then the routing hint. Every clause carries information an agent needs; no filler.

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?

No output schema exists, but the description still explains the return shape ('each line gives its as-of time') and ordering. For a two-parameter, read-only query tool with annotations covering safety, nothing needed 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.

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

Schema coverage is 50% (region documented, limit not), so the description must compensate. It does so well for region by explaining the accepted value classes (country, state, season pass like 'Ikon Pass', or any tag from ski_list_regions) and case-insensitivity is in the schema. The limit parameter is never addressed in either place, which is the remaining gap.

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 and resource — resorts whose lift board lists running lifts right now — plus scope ('across all resorts at once') and ordering ('most open lifts first'). It is clearly separable from ski_get_resort_status, which the description explicitly contrasts.

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 the exact question it answers ('where can I ski today?') and names the alternative with its condition: use ski_get_resort_status for a live, per-lift answer about one resort. It also enumerates valid region inputs (country, state, pass, tag from ski_list_regions), leaving nothing to inference.

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