status.live

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

Goes well beyond the readOnly/openWorld annotations: it discloses per-source freshness (Forest Service refreshed every 6 hours), that California State Parks supplies no status, that 'not listed' means unknown rather than closed, and licensing/attribution constraints. That is exactly the kind of trust-calibration context annotations can't carry.

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-loaded with the core purpose and result fields, then the caveats; every sentence (including the licensing note) carries real information. Slightly dense for a single paragraph, but 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?

With no output schema, the description does the work of describing return values (distance, open today, booking link). Combined with the freshness and licensing caveats, an agent has everything needed to call and interpret the result correctly.

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 carries the burden. It clarifies lat/long as a point and links the output to open-today status, but never explains limit, max_km (the search radius), or the open_today_only filter — the three parameters most likely to be mis-set.

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 ('campgrounds nearest a latitude/longitude') and names the three source datasets, so the agent knows exactly what it retrieves. It distinguishes itself from campgrounds_search only implicitly, via the geo-radius framing, rather than naming the sibling outright.

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 'nearest a point' framing implies when to reach for it (a location-based lookup), but there is no explicit when-to-use/when-not or reference to campgrounds_search or campgrounds_get_status as alternatives. Usage must be inferred from the sibling names.

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?

Beyond the readOnly/openWorld annotations, it discloses provenance per agency (NPS published schedule, Forest Service status refreshed every 6 hours, CA State Parks GIS with no opening status), the semantics of "not listed" (unknown, not closed), and licensing/attribution obligations with a link. That is exactly the extra context annotations cannot carry, including a real caveat about data reliability.

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-loaded with the return contents, then the source caveats, then licensing — a sensible ordering with dense, low-waste sentences. The trailing attribution URL is necessary but makes the entry longer than ideal for a single-parameter lookup.

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?

There is no output schema, and the description compensates by enumerating the fields returned (status, season, booking method, fees, rules, official page, forecast). Combined with the per-agency freshness caveats and the unknown-vs-closed distinction, an agent has what it needs to call and interpret the result.

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?

Only one parameter and schema coverage is 100%, so the schema already documents "Campground id or name." The description largely restates that, adding just the example id format ("upper-pines"), which is a marginal gain over the schema.

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?

"One campground:" plus an enumeration of the returned facts (open today, season, booking method, fees, rules, page, forecast) is a specific verb-and-resource statement. It implicitly separates itself from the plural search/find siblings by the singular framing, but never names them, so the differentiation is inferred rather than explicit.

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 singular "One campground" framing and the id-example imply this is the detail lookup you call once you already know which campground you want, contrasting with the list-style siblings. However, no explicit when-to-use, when-not, or "use X instead for Y" routing is stated.

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?

Goes well beyond the readOnlyHint annotations: it explains per-source status semantics (NPS follows park schedule, Forest Service refreshed every 6 hours, CA State Parks GIS has no status), defines "not listed" as unknown rather than closed, and flags CA attribution and commercial-use permission requirements. Only the result-shape details and pagination behavior are left unexplained.

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-loaded with the searchable dimensions and the get_status handoff, which is the right ordering. The licensing sentence is long and run-on but is genuinely actionable information for a public-data source rather than 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 does the necessary work of stating what comes back: ids, today's open status, and a booking link. Combined with read-only annotations and the source-specific caveats, an agent has enough to call it correctly; only result limits/paging are unaddressed.

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 33%: only query is documented in the schema, and the description does expand it with useful accepted forms and examples ("Yosemite", "Shasta-Trinity", "CO"). But limit (default 25, max 100) and open_today_only get no explanation in either place, so coverage is not fully compensated.

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 (find) and resource (campgrounds) and enumerates the query dimensions: name, id, park/forest, or state, with examples. It also names the downstream sibling campgrounds_get_status. It never mentions campgrounds_find_near, so the split between text search and proximity search is left implicit.

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?

Implicit routing guidance is present: "Returns ids for campgrounds_get_status" tells the agent this is the lookup step before a status call. However, there is no explicit when-to-use versus campgrounds_find_near, and no statement about what to do if the query returns nothing.

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 readOnly/openWorld=false safety, but the description adds genuine behavioral context: the open flag comes from published schedules rather than live alerts, and results carry site counts and reservation links. That is useful beyond the structured fields, though no pagination or ordering behavior is disclosed.

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, zero waste: what is returned is front-loaded and the routing caveat follows immediately. Nothing to trim.

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 enumerates the return payload (open-today, site counts, reservation links) and the schedule-vs-alert caveat. The gap is parameter coverage — limit and max_km defaults/ranges are never surfaced.

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% across 5 params, so the description must compensate. It implies the latitude/longitude point ("nearest a point") and the open_today_only flag ("open today by its published schedule"), but says nothing about limit or max_km, leaving two params — including the distance radius — undocumented.

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?

Specific verb+resource+scope: NPS campgrounds nearest a point, with the fields returned (open-today status, site counts, reservation links). It differentiates from nationalparks_get_park_status by contrast, but it does not distinguish itself from the near-identical sibling campgrounds_find_near, which is a real ambiguity for selection.

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?

Explicitly scopes the tool ("Schedules only") and routes the agent elsewhere for a different need (nationalparks_get_park_status for current alerts). Clear context with one exclusion, though it never addresses the campgrounds_find_near / campgrounds_search overlap.

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, openWorldHint, and destructiveHint=false, so safety is covered. The description adds real context beyond that: it distinguishes live components (which carry an as-of time) from static ones and discloses the upstream sources (NPS alerts, NWS, AQI, satellite hotspots, etc.), which is meaningful behavioral detail.

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-loaded with the scope ('Right now at one park') and then a dense but purposeful enumeration of the data returned; nearly every clause conveys actionable coverage information. It runs long, but the length is justified rather than padding.

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 conveying return content, and it does so thoroughly — listing alerts, weather, air quality, fire, roads, campground/visitor-center schedules, webcams, sun/moon, and forecast per country. Nothing an agent needs to decide and call it 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 100%, so the schema already documents both parameters. The description restates that a park id or name is accepted with examples, but adds nothing about include_campgrounds or any format nuance beyond the schema, so the 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 (get) and resource (park status) and goes further by enumerating exactly what 'status' aggregates for US vs Canadian parks. This cleanly separates it from siblings like themeparks_get_park_status and ski_get_resort_status, and pins down the single-park live scope with 'Right now at one park.'

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 phrase 'Right now at one park' implies this is for live current conditions at one location, which implicitly routes a park-level query here rather than to search tools. However, it never states when NOT to use it or names any alternative (e.g. nationalparks_search_parks for discovery), leaving the routing 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, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds real context beyond that: exactly which park systems are in scope and that returned ids feed nationalparks_get_park_status. It omits pagination/limit behavior and result-count semantics, so not 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?

Two tight sentences: scope/coverage first, then search axes and the handoff tool. Zero filler and nothing redundant with the name or title.

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 fills that gap by stating that ids are returned and what they are for. The only missing piece for correct invocation is guidance on the limit parameter and truncation behavior, which is minor for a read-only search.

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% (limit is undocumented anywhere), so the description must compensate – and it does for query, adding concrete park-code examples ('yose', 'banff') and the special 'canada' token that the schema does not mention. The limit parameter's default/max remain unexplained, keeping it from a 5.

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+resource ('Find the national parks this server covers') and immediately scopes coverage to US NPS units and Parks Canada, which cleanly separates it from themeparks_search_parks and ski_search_resorts. It also names the downstream tool (nationalparks_get_park_status) that consumes the ids.

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 enumerates the supported search axes (name, park id, US state, Canadian province, 'canada') and ties the output to a next step. It does not explicitly say when to prefer this over sibling searches, but the coverage statement implicitly does the 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 declare readOnlyHint, openWorldHint, and destructiveHint false, so safety is covered. The description adds valuable behavioral context: data is operator-reported, and missing counts are explained as either no lifts listed or unreadable. It does not mention rate limits or output format, but for a read-only tool, this is sufficient.

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 with zero waste: the first sentence front-loads the core purpose and sorting criterion, and the second adds critical data-handling context. Both sentences earn their 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?

Given the simple schema (one parameter, no output schema) and annotations, the description covers purpose, sorting, data source, and missing-data behavior. It could briefly mention the response structure (e.g., list of resorts with counts), but it is largely complete for an agent to call it correctly.

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%, with the 'resorts' parameter fully described as 'Resort ids or names'. The description reiterates the 10-item limit but adds no new syntax or format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (resorts) with a clear focus on running-lift counts and sorting. However, it does not explicitly name a sibling tool or differentiate itself from ski_get_resort_status, though the comparison nature makes it distinguishable.

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 description implies usage by specifying 'up to 10 resorts' and sorting, but it does not explicitly state when to use this tool versus alternatives like ski_get_resort_status or ski_search_resorts. No exclusions or alternative routing are provided.

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 (readOnly, non-destructive, openWorld), so the bar is lower. The description still adds real behavioral value: it discloses that distances are straight-line (not travel distance) and that lift counts are an opt-in live fetch, implying extra per-resort requests and latency beyond the schema's terse note.

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 no filler; the core spatial semantics are front-loaded and the optional behavior is appended as a secondary clause.

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 should convey what comes back; it identifies the ordering metric and the optional status enrichment, which is close to sufficient. Missing pieces are minor: tie-breaking, whether results include distance values, and the cost of the optional live fetch.

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 40%: max_km and include_status are documented in the schema, while latitude, longitude, and limit carry no descriptions. The description implies sorting by distance and an optional status fetch, but adds no units, ordering, or result-count semantics beyond what the schema already states.

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 the resource (resorts), the spatial criterion (closest to a point), and the metric (straight-line distance), which is enough to separate it from name-based siblings like ski_search_resorts. It lacks an explicit verb and never names a sibling, so an agent must infer the contrast rather than read it.

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: this is the tool for proximity queries when you have coordinates, as opposed to search or status tools. However, there is no explicit when-to-use statement, no exclusion (e.g. 'do not use for name search'), and no mention of alternatives such as ski_search_resorts or ski_compare_resorts.

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 (readOnly, non-destructive, openWorld), so the description's value-add is the behavioral constraint: it fetches every resort in the region and is capped at 40 resorts, which signals potential latency and truncation. It doesn't say what happens when the cap is exceeded (error vs. partial results), leaving one 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 sentences, zero filler, with the resource and scope front-loaded and the 40-resort limitation placed last as a caveat. Every clause carries information the agent needs.

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 conveys the return shape (open-lift totals plus each resort's count), so the agent knows what to expect. The only missing detail is the failure mode when a region exceeds 40 resorts, a minor but real gap for a tool whose stated limit is the key constraint.

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 'Region tag, case-insensitive', so the baseline is 3. The description adds real value by giving concrete example tags ("Utah", "Dolomiti") and pointing to ski_list_regions as the authoritative source, which the schema does not.

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 aggregation verb and resource ('open-lift totals for a whole region') plus the per-resort breakdown, so the agent knows this is a regional rollup rather than a single-resort lookup like ski_get_resort_status. It also names ski_list_regions as the origin of the region tag, separating the two tools cleanly.

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 tells the agent exactly where to get a valid region value (a tag from ski_list_regions) and discloses the 40-resort cap that governs when this call is appropriate. It stops short of naming an alternative for large regions or when-not-to-use guidance, so not a 5.

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?

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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured fields. The description adds that results include resort counts, which is modest but useful context; it does not describe ordering, pagination, or whether the output is flat or nested.

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?

One efficient sentence with the core purpose front-loaded and no filler. Every phrase earns its place by naming the grouping types and the count inclusion.

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 parameters, no output schema, and annotations covering the safety profile, the description is sufficient to call the tool. It explains what is listed and that counts are returned, though it could be slightly richer about the shape of the returned regions.

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 zero parameters, so the baseline of 4 applies. The description adds no parameter detail, but none is needed because there are no inputs.

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 gives a specific verb (List) and resource (region tags), and clarifies what a region is (states, countries, ranges) plus that counts are included. It does not distinguish this from the closely named sibling ski_get_region_summary, which an agent might otherwise conflate with it.

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 listing nature of the tool, but there is no explicit guidance on when to choose this over ski_get_region_summary or ski_search_resorts. No exclusions or prerequisites are stated.

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?

Beyond the read-only annotations, it discloses ordering, update cadence of about every 90 minutes, all-resorts scope, and that each line includes an as-of time. It also warns that 'running lift' means what the board says, not that the season has started, and that out-of-season boards may list sightseeing lifts or be stale.

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 adds ordering, region options, cadence, caveat, and alternative in a logical order. It is somewhat dense, especially the region parenthetical, but every sentence provides actionable context rather than 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?

For a read-only list tool with no output schema, it explains the key behavior: current lift-board status, ordering, region filtering, update cadence, as-of timestamps, and the out-of-season caveat. It is nearly complete, though it leaves limit/pagination behavior to the schema and does not describe the full return fields.

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 description adds useful meaning for region beyond the schema, with examples such as country, state, season pass, and ski_list_regions tags. However, the limit parameter is not mentioned at all, and schema coverage is only 50%, so the description only partially compensates for the undocumented parameter semantics.

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 resource and condition: ski resorts whose own lift board lists running lifts right now, ordered by most running lifts. It also distinguishes itself from ski_get_resort_status, which gives a live per-lift answer for one resort.

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 gives clear usage context for a broad current-open-resorts query and explicitly names ski_get_resort_status as the alternative for a live per-lift answer about one resort. It also points to ski_list_regions for valid region tags, though it does not cover other ski siblings such as ski_search_resorts or ski_compare_resorts.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds two useful traits (ids are meant for chaining; empty query returns the full list) but says nothing about the limit parameter's default of 25 or its 250 cap, which is the main undisclosed 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 sentences, zero filler, front-loaded with the searchable keys and followed immediately by the return-value and empty-query behavior. Every clause carries information the agent needs.

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 states what comes back (resort ids for chaining). For a two-parameter list tool with read-only annotations this is nearly complete; only the limit/pagination semantics are unaddressed.

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% (limit is undocumented), so the description must compensate, and it does: it enumerates the accepted query dimensions and gives concrete examples ('Colorado', 'Alps', 'Ikon Pass'), including the season-pass dimension that the schema's own query description omits. It does not explain limit/pagination, 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 (find) and resource (ski resorts) with the exact lookup keys: name, id, region tag, and season pass. The phrase 'the ski resorts this server covers' also scopes it against the broader park/campground siblings, and it is clearly separable from ski_find_nearby_resorts and ski_list_regions.

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?

Tells the agent the downstream purpose ('Returns resort ids to pass to the other tools') and the empty-query behavior ('Leave query empty to list everything'), which is genuinely actionable context. It stops short of naming alternatives or exclusions, e.g. when to prefer ski_find_nearby_resorts for geographic search.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the NOAA buoy is the preferred source, and outside the US the 'now' values fall back to model output and are labelled as such. It also pins down units (metres with feet in brackets). No auth or rate-limit notes, but for a read-only status call this is strong 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?

Three sentences, front-loaded with what the agent gets back, followed by the fallback caveat and the input/units note. Dense but every clause carries information; only the parenthetical enumeration of buoy fields is slightly list-heavy.

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?

There is no output schema, so the description must carry the return-value burden, and it does: it names the data sources, the fields returned, the units, and the degradation case where model values substitute for buoy readings. Nothing an agent needs to call or interpret this tool 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 description coverage is 100%, so both parameters (spot, include_forecast) are already documented in the schema. The description restates that a spot id or name is accepted and alludes to the forecast, but adds no format, matching, or defaulting nuance beyond the schema. 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 resource (what the water is doing at one surf spot) and enumerates the returned content: buoy readings, tides, and a 7-day swell forecast. This clearly separates it from surf_search_spots (discovery) and the status tools of other domains, so an agent can route 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?

Usage is only implied: the description frames the tool as reporting on 'one surf spot', which suggests it is for a spot you have already identified. It never names surf_search_spots as the alternative for finding spots, nor states any when-not condition. Adequate but leaves routing 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, destructiveHint=false and a closed-world scope, so safety is covered. The description adds the empty-query behavior and the return type (spot ids), but omits pagination/limit behavior for a tool that caps results at 200 with a default of 25.

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 short sentences, zero filler, with the purpose and the search facets front-loaded ahead of the empty-query fallback and the downstream tool reference.

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 what comes back ('spot ids for surf_get_spot_status'). It is nearly complete, but the undocumented limit/pagination behavior is an unaddressed gap for an agent that may need to page through all spots.

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% (query documented, limit not). The description enriches the query parameter with concrete area examples ('Oahu', 'California', 'Bali') and the empty-string behavior, which the schema does not state. However it says nothing about the undocumented limit parameter or result capping, so it only partially compensates.

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 ('Find the surf spots this server covers') and enumerates the searchable facets (name, id, area, country). It also distinguishes itself from the sibling surf_get_spot_status by positioning that tool as the consumer of the returned ids.

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 clear context: use a query for name/id/area/country, or 'Leave query empty to list everything', which is an explicit when-to-use condition. It routes the agent to surf_get_spot_status for follow-up but states no exclusions or cases where another search tool is preferable.

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 cover the safety profile, but the description adds substantial context beyond them: the upstream source (Queue-Times), a 5-minute refresh cadence, an as-of timestamp, and crucially the meaning of the state values, including that source_error means unknown rather than closed. That last distinction prevents a serious misreading of the response.

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-loaded with what the tool returns, then usage, then provenance and state semantics. It is dense but every clause carries information; only minor tightening is possible.

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?

There is no output schema, so the description must describe return values, and it does: per-ride open/closed status with wait times grouped by area, park local time, a weather forecast, an as-of time, and the tri-state status field. Nothing an agent needs to interpret the result 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 description coverage is 100%, so the baseline is 3. The description's mentions of `ride` (specific-ride queries) and include_rides (counts only) largely restate what the schema already documents, adding little syntax or format detail beyond it.

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 ('Live ride status for one theme park') and enumerates the payload (rides grouped by area with wait times, park local time, weather forecast). It clearly separates this tool from themeparks_search_parks and from the other domains' status tools.

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 clear operational context: pass `ride` to answer about specific rides with an example, and set include_rides=false for counts only. It does not, however, route to the sibling themeparks_search_parks for discovering a park id/name, which is the natural prerequisite given the park param accepts either.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the result is a set of park ids and that an empty query returns the full catalog, which is useful. However, 'list everything' sits awkwardly against the schema's limit default of 25, so the actual result-size behavior is left ambiguous.

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 short sentences with zero padding; the searchable facets come first, the return/chaining fact second, and the empty-query rule last. Nothing is redundant with the title.

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 that it returns park ids and links them to themeparks_get_park_status, and it explains the query parameter. The only real gap is the limit parameter and how it interacts with the 'list everything' claim.

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 50%: query is documented in the schema, limit is not. The description enriches query semantics with concrete country/operator examples and the empty-string behavior, but says nothing about limit, so half the parameter surface remains undocumented. That is adequate but not 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?

States a specific verb+resource (find theme parks) plus the exact searchable facets (name, id, country, operator) and scopes it to 'the theme parks this server covers', which cleanly separates it from nationalparks_search_parks, ski_search_resorts and surf_search_spots.

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 an explicit usage rule ('Leave query empty to list everything') and names the downstream tool that consumes the returned ids (themeparks_get_park_status), so the agent knows both when to call it bare and what to do with the result. It stops short of naming an alternative tool or stating exclusions, so it is strong but not a 5.

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