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

Beyond the annotations, the description discloses critical behavioral context: data comes from the resort's own site, lift states include reported/none_listed/source_error with precise semantics (none_listed is not the same as closed; source_error means unknown), and an as-of time is provided. It also distinguishes model-derived forecasts and snow estimates from official road conditions, which is exactly the kind of provenance an agent needs to interpret results correctly.

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?

The description is front-loaded with the core purpose and then efficiently lists all returned content in a single long sentence with colons and parentheses. It is dense but every clause adds substantive information; only slightly better visual structuring could push it higher.

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 and only two simple parameters, the description compensates thoroughly by enumerating every category of returned data, including lift state semantics and data provenance. An agent knows exactly what to expect from a call without needing a response schema.

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 100%, so both parameters are already documented in the input schema. The description only restates that an id or resort name is accepted and does not mention include_lifts or add any syntax or format details beyond the schema, so the baseline of 3 applies.

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?

The description leads with a specific verb+resource: 'Everything known about one resort', then enumerates live lift status, forecasts, snow estimates, road conditions, and webcams. This scope clearly differentiates it from sibling tools like ski_get_region_summary, ski_compare_resorts, and ski_search_resorts, even without naming them.

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?

Usage is implied by the scope statement 'Everything known about one resort', so an agent can infer this is the detailed status endpoint for a known resort. However, there is no explicit guidance on when to prefer it over ski_open_now, ski_search_resorts, or ski_compare_resorts, and no exclusions are stated.

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