status.live ski

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

Annotations already declare readOnly and openWorld, but the description adds real behavioral context: data is operator-reported, results are sorted by share of lifts open, and missing counts carry a distinguishing reason (listed none vs. unreadable). That last point is genuinely useful because it tells the agent not to treat a blank as zero. No auth or rate-limit detail, which is a minor gap.

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 tight sentences led by the primary purpose, then the data-quality caveat. Every clause carries information the agent needs and there is no filler or repetition of the tool name.

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 usefully describes the return shape (lift counts, sorted by share open) and how to interpret absent values. It is nearly complete for this tool; only the unavailable-count reason wording and error behavior for invalid resort names are unspecified.

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% and the single parameter is fully described in the schema as 'Resort ids or names' with min/max items. The description's 'up to 10 resorts' largely restates maxItems without adding accepted format or disambiguation rules for names vs. ids, so baseline 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?

States a specific verb (compare) and resource (open-lift counts) plus the scope limit of 10 resorts and the sort order, so the agent knows exactly what comes back. It never names the sibling it complements (e.g. ski_get_resort_status for a single resort), so differentiation is implied rather than stated.

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?

Multi-resort comparison is clearly implied by 'side-by-side ... for up to 10 resorts', which tells the agent to reach for this tool when several resorts are in play. However, there is no explicit when-not guidance or named alternative for single-resort lookups, so the routing decision is left to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds two genuinely useful behavioral facts the annotations do not: proximity is measured as straight-line (not travel) distance, and include_status triggers one request per resort, warning of cost/latency. It omits ordering of results and any failure behavior.

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 short sentences with zero filler; the primary behavior (nearest resorts by straight-line distance) is front-loaded and the optional cost-bearing flag follows. Nothing could be cut without losing 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?

With no output schema, the description carries the burden of explaining returns, and it only partially does so: it implies a list of resorts ordered by distance plus optional lift counts, but does not say how results are ordered, truncated by limit, or shaped. Adequate but with clear gaps for a 5-parameter tool.

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 only 40% (limit has no description anywhere, and lat/long carry only range constraints), so the description should compensate more. It does clarify that latitude/longitude define 'a point' and that include_status fetches live lift counts at a per-resort request cost, but limit and max_km semantics are left entirely to the schema or unstated.

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 with scope: 'Resorts closest to a point, by straight-line distance.' The distance metric distinguishes it from routing-style tools, and it is clearly not a comparison, listing, or status tool. It stops short of naming which sibling (e.g., ski_search_resorts) to prefer when proximity is not the criterion.

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?

'Optionally fetches live open-lift counts' implies when to set include_status, and 'by straight-line distance' hints at the proximity use case. But there is no explicit when-to-use-this-vs-alternatives guidance against six siblings such as ski_open_now or ski_search_resorts, so the agent must infer routing.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), but the description adds a real operational constraint: it 'Fetches every resort in the region, so it is limited to 40 resorts,' which warns the agent about truncation on large regions. It does not describe error behavior for an invalid region tag, so it stops short of full behavioral disclosure.

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 sentences, no filler, with the core purpose and the scoping constraint front-loaded before the tag-source detail. Every clause earns its place.

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?

For a single-parameter read-only tool with no output schema, the description covers what it returns ('each resort's count') and the 40-resort ceiling. It leaves the handling of an unrecognized region tag unspecified, which is a minor but real gap.

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% and the schema already documents the parameter as a case-insensitive region tag, so baseline is 3. The description adds value beyond the schema by supplying concrete example values and identifying the authoritative source tool for tags, which helps the agent construct a valid call.

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 names a specific verb+resource ('Open-lift totals for a whole region') and explicitly distinguishes itself from resort-level siblings by saying it returns 'each resort's count' for the whole region. It also anchors the 'region' concept to ski_list_regions, so an agent can tell it apart from ski_get_resort_status 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?

It states where the region value comes from ('a tag from ski_list_regions, e.g. "Utah", "Dolomiti"'), which is genuine routing guidance. It gives no explicit when-not-to-use or comparison against ski_get_resort_status / ski_open_now, so context is clear but alternatives are not named.

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

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

Annotations already establish that this is a read-only, open-world tool. The description goes much further, explaining lift-state semantics (reported, none_listed, source_error), operator-reported provenance with an as-of time, and the distinction between none_listed and closed. It also clarifies which data are modeled versus official.

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 overview is front-loaded and every clause describes actual return content, so the length is largely justified for a rich status tool. However, it is a dense single sentence, and slightly better structure would improve scanability.

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 high complexity, the description carries the burden of explaining the return payload and does so across lifts, opening dates, forecasts, snow estimates, road conditions, and webcams. It also explains data quality states, leaving little ambiguity about what the agent will receive.

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 100%, so the schema already documents both parameters, including that resort accepts an id or name. The description repeats the id-or-name input but does not add meaning for include_lifts 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.

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

The description opens with a specific scope: 'Everything known about one resort,' then enumerates the exact data returned. It clearly distinguishes a full single-resort status lookup from siblings like ski_compare_resorts, ski_find_nearby_resorts, and ski_get_region_summary.

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?

The single-resort scope is implied by 'one resort,' but the description does not explicitly state when to use this tool versus alternatives such as ski_open_now or ski_search_resorts. There are no exclusions or routing conditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe local read. The description adds that results include resort counts, which is useful output context, but says nothing about ordering, pagination, or how large the tag set is.

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?

A single sentence that front-loads the verb and resource and packs in the grouping semantics and the included resort counts with zero 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?

With no output schema, the description carries the burden of describing what comes back, and it does so at a high level (region tags plus resort counts). The remaining thinness — no ordering or size expectations — is minor for such a simple listing tool.

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?

The tool takes no parameters, so there is nothing for the description to disambiguate; per the rubric a parameterless tool baselines at 4. No parameter-level gaps exist.

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 (list) and resource (region tags), and even clarifies what a 'region' is here — tags resorts are grouped by, such as states, countries, ranges — plus that each carries a resort count. It is distinguishable from ski_get_region_summary by being an enumeration rather than a single-region detail call, though it never names that sibling explicitly.

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?

The enumeration framing implies the use case (discovering valid region tags, likely for filtering in ski_search_resorts), but there is no explicit when-to-use statement or comparison to ski_get_region_summary. For a zero-argument list endpoint the intended usage is largely self-evident, so implied guidance is acceptable.

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

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with them by framing this as a lookup over a fixed set of resorts. It adds that results are ids, but says nothing about pagination, the 25-default/250-max limit, or behavior when a query matches nothing — gaps that matter for a search tool.

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 tight sentences: capability first, return value second, empty-query fallback last. Every sentence carries information and nothing is padded.

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 correctly discloses the return shape (resort ids), which is the key thing an agent needs to chain into other tools. The remaining hole is limit/pagination behavior, which is neither in the schema nor the description.

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 only 50% (query documented, limit not). The description compensates by expanding query semantics well beyond the schema's 'Name, id, or region, case-insensitive', adding region tag examples and season pass matching. It leaves the limit parameter undocumented in both places, so it is not fully compensatory.

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 states a specific verb and resource ('Find the ski resorts this server covers') and enumerates the searchable dimensions, plus notes it returns resort ids for other tools, which implicitly separates it from siblings like ski_get_resort_status or ski_compare_resorts. It does not explicitly disambiguate against ski_list_regions, which also surfaces regions, so it falls short of full sibling differentiation.

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?

Clear workflow positioning: it produces resort ids 'to pass to the other tools', and the empty-query case is explicitly defined ('Leave query empty to list everything'). No explicit when-not or named alternative is given, so it stops short of a 5.

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