status.live

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

Annotations already establish read-only, open-world, non-destructive behavior, so the bar is lowered, and the description still adds real value: data freshness (Forest Service statuses refreshed every 6 hours), the source of each agency's open/closed determination, and the meaning of the ambiguous 'not listed' value. It does not cover rate limits or result ordering beyond 'nearest'.

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 core capability and return fields are front-loaded in the first sentence, and the following sentences earn their place by disambiguating status semantics. Slightly dense, but no filler or repetition.

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 naming the returned fields (distance, open today, booking link) and explaining status provenance and freshness. Gaps remain around distance units, result limiting, and what happens when nothing falls within the radius, but the essential contract is conveyed.

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 parameters, so the description carries the full burden. It names latitude/longitude and implies open_today_only via 'whether each is open today', but says nothing about limit or max_km (radius in km, defaults, caps), leaving two filters completely 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?

The description gives a specific verb+resource (find campgrounds) plus a precise scope: nearest a latitude/longitude across NPS and Forest Service lands. It clearly reads as a proximity search, but it never distinguishes itself from the similarly named sibling nationalparks_find_campgrounds or campgrounds_search, so the agent must infer the split.

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 geographic framing ('nearest a latitude/longitude'), which tells the agent this is the proximity path rather than a name search. However, there is no explicit when-to-use statement, no exclusions, and no pointer to the sibling tools it overlaps with (campgrounds_search, nationalparks_find_campgrounds).

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 read-only, non-destructive, open-world profile, yet the description adds real behavioral context: the differing authority for NPS vs Forest Service status, a 6-hour refresh cadence, and the exact meaning of the 'not listed' value. That is meaningful disclosure beyond the structured fields.

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 what-is-returned clause is front-loaded and each subsequent sentence adds distinct information (input forms, data sources, status semantics). Dense but no sentence is redundant.

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 the response and does so by enumerating open status, season, booking path, fees, rules, page, and weather, plus caveats on status sourcing. Complete enough for an agent to call and interpret 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% and the single parameter is already documented as 'Campground id or name'. The description adds only an example id ('upper-pines'), which is marginal value over 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+resource ('One campground: whether it is open today, the season, how to book it...') and enumerates the return contents. The phrase 'One campground' clearly distinguishes it from the sibling search/find tools that operate over many.

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 scope implies this is the detail lookup to use after searching, and it explains what inputs it takes (id or name). It never explicitly names an alternative like campgrounds_search for discovery, so routing guidance is clear but not fully spelled out.

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 readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real domain behavior beyond that: NPS status derives from the park's published schedule, Forest Service status from each forest's list refreshed every 6 hours, and 'not listed' is explicitly defined as unknown rather than closed. That is meaningful interpretation guidance.

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-loads the core capability and the follow-up-tool pointer, then uses the remaining space for status semantics. The status paragraph is dense but each clause carries distinct information; 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 explain the interesting return content (open-today flag, booking link, ids). It is nearly complete, though it omits pagination/limit behavior for a search that defaults to 25 and caps at 100.

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 33%, and the description largely mirrors the query parameter semantics already in the schema. It adds concrete value examples for query but says nothing about limit or open_today_only, so the low-coverage params remain 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?

States a specific verb (Find) and resource (NPS/Forest Service campgrounds) and enumerates the accepted lookup keys, including concrete examples. It also names the downstream sibling campgrounds_get_status, so an agent can distinguish it from the other campground tools without opening schemas.

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 creates a clear chain to campgrounds_get_status for id-based follow-ups, which is useful routing. However, it never explains when to prefer this over campgrounds_find_near or nationalparks_find_campgrounds, so usage is implied rather than 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 and openWorldHint, so safety is covered. The description adds genuinely new context: 'open' is derived from published schedules rather than live conditions, and results include site counts and reservation links. It doesn't cover pagination or result ordering, so it isn't exhaustive.

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 waste. The result content is front-loaded and the sibling routing caveat is placed last where it belongs.

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 what comes back (open-today status, site counts, reservation links) and annotations cover the read-only profile. The missing radius/limit behavior is the only notable gap for a 5-parameter geo query.

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 the burden. It clarifies the point-based latitude/longitude query and the open_today_only flag, but says nothing about limit or max_km, leaving the default 100 km radius and result cap (a 5-param tool) unexplained.

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 ('NPS campgrounds nearest a point') with the scope of the query, and explicitly separates itself from nationalparks_get_park_status. An agent can distinguish it from both siblings 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?

The clause 'Schedules only: check nationalparks_get_park_status for current alerts' names an alternative and the condition that selects it, which is explicit when-not guidance. It stops short of the full 5 because it never addresses when to use this versus nationalparks_search_parks.

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 (readOnlyHint, openWorldHint), and the description adds meaningful context beyond them: data sources differ by country, live values carry an 'as-of' time, and some fields (road conditions) are only available where supported. It does not discuss rate limits or auth, but for a public read-only status tool this is solid 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?

The scoping sentence is front-loaded and the long enumerations are dense and informative rather than padding, though the US/Canada breakdown is a single sprawling sentence that could be tightened. Every clause carries selection-relevant content.

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 full burden of describing return contents, and it does so comprehensively across both countries, including the as-of freshness caveat. Nothing an agent needs to call this 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 100%, so the schema already documents both parameters and their defaults. The description restates the accepted park id/name formats and gives extra code examples ('banff'), but adds little semantic depth beyond the schema; the campgrounds enumeration describes returned data rather than the include_campgrounds flag. Baseline 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 precise scope statement ('Right now at one park') and then enumerates the exact resource contents for US and Canadian parks. It is clearly distinguishable from nationalparks_search_parks (searching) and nationalparks_find_campgrounds (campground lookup), since this tool returns live conditions for a single known 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?

Usage is implied by the 'Right now' framing and the single-park scope, so an agent can infer this is for current conditions rather than discovery. However, it never explicitly states when to use this versus the sibling search tools, nor any prerequisites or exclusions.

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 (readOnlyHint=true, openWorldHint=false), so the description only needs to add context. It does: it discloses the index boundary - which park systems and unit types are included (parks, monuments, seashores, recreation areas with campgrounds) - which materially affects whether a search will succeed. It omits pagination behavior despite a limit parameter defaulting to 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 tightly packed sentences: scope first, searchable fields second, return handoff third. No filler, no restatement of the title, and the most decision-relevant fact (covered park systems) is front-loaded.

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, but the description states what comes back (ids for nationalparks_get_park_status), which is the key return-value fact an agent needs. Combined with the scope and query guidance this is nearly complete; the only missing piece is how limit/pagination affects large result sets.

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 is documented but limit is not. The description compensates for query by giving real examples ('yose', 'banff', 'canada', state/province names) and confirming case-insensitivity context beyond the schema string. It says nothing about limit or result truncation, so the coverage gap is only partly closed.

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/search) and resource (national parks) and pins down the data set precisely: US NPS units plus Parks Canada. It even names the downstream sibling (nationalparks_get_park_status) whose ids it produces, so an agent can distinguish it from find_campgrounds and get_park_status without opening any 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?

The description enumerates the exact query dimensions (name, park code, US state, Canadian province, 'canada'), which tells the agent when this tool's input will match. It implies the workflow link to get_park_status but never states a when-not-to-use case or an explicit alternative, so it stops short of full routing guidance.

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 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.

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), but the description adds real behavioral context the annotations cannot: the NOAA buoy is the source, non-US spots fall back to model values and label them as such, and units are metres with feet in brackets. It stops short of error behavior or data-staleness handling.

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 payload contents, then provenance caveats, then the input format and units. Three dense sentences with no filler, though the mid-sentence parenthetical list is slightly 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 carries the return-value burden itself and does so fully — it names every data group (buoy metrics, tides, forecast) and flags the model-vs-buoy distinction. Nothing an agent needs to call or interpret this 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 description coverage is 100%, so both parameters are already documented, and the description largely restates them ('Accepts a spot id or name'). It adds only marginal meaning — the forecast length tied to include_forecast and the units convention — 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 resource (conditions at ONE surf spot) and enumerates exactly what is returned — buoy wave data, tides, and a 7-day swell forecast. The singular scope implicitly separates it from surf_search_spots, so an agent can route correctly without opening the 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 tells you it accepts an id or name and returns current conditions, but never states when to pick this over surf_search_spots or what happens with an unrecognized spot. No explicit when/when-not guidance is present.

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 'spots this server covers' is consistent with that closed-world read-only profile. The description adds the useful fact that it returns spot ids, but does not disclose pagination or that the default limit of 25 caps results, which slightly undercuts the 'list everything' phrasing.

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 tightly written sentences, front-loaded with the searchable keys and ending on the actionable default behavior. The parenthetical examples are short and directly reduce ambiguity 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 helpfully states the return type (spot ids), and the follow-up tool is named. The remaining gap is the unmentioned limit/pagination behavior on a 2-parameter tool with a capped default.

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 50%; the description thoroughly amplifies the documented 'query' parameter with examples ('Oahu', 'California', 'Bali') and the empty-string behavior. However the undocumented 'limit' parameter (default 25, max 200) is not addressed anywhere, so the description does not fully compensate for the coverage 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 ('Find the surf spots') plus the accepted lookup keys (name, id, area, country). It distinguishes itself from the sibling surf_get_spot_status by positioning itself as the id-producing search step that feeds that tool.

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 a concrete usage rule ('Leave query empty to list everything') and explains the workflow linkage to surf_get_spot_status. It stops short of an explicit exclusion such as when to use a status lookup instead of a search, so it is not a full when/when-not statement.

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 readOnlyHint/openWorldHint, it discloses the upstream source (Queue-Times), the 5-minute refresh cadence, an as-of timestamp, and — critically — the meaning of each state, including that source_error means unknown rather than closed. That interpretation guidance prevents a real misinterpretation and is not derivable from annotations or schema.

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 returned payload, then filtering, then provenance/state semantics — a sensible order with no filler. The first sentence is long and clause-heavy, which slightly taxes scanning.

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 return-shape burden and does so fully: rides, wait times, grouping, park time, weather, freshness, and the state enum. Nothing an agent needs to call it correctly or interpret results 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 schema already documents `park` (id or name) and `ride` (case-insensitive substring). The description largely restates these, adding only an example ride name; per the baseline rule this lands at 3.

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 (live ride status for one theme park) and enumerates the payload: per-ride open/closed with wait time, area grouping, park local time, weather forecast. This clearly separates it from sibling status tools for other domains (ski_get_resort_status, surf_get_spot_status, nationalparks_get_park_status) and from themeparks_search_parks.

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?

"Pass `ride` to answer about specific rides" gives concrete usage context, and the state semantics tell the agent how to interpret results. However, it never states exclusions or routing (e.g., use themeparks_search_parks first to resolve an unknown park), so it stops short of explicit alternatives.

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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral value beyond that: it says the result is park ids, that empty query returns everything, and where those ids are consumed next. It omits pagination/limit behavior, which keeps it from 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 that front-load the searchable dimensions, then the return value and the empty-query escape hatch. No filler, though the country/operator examples add a little length without being wasteful.

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 is returned (park ids) and how to use them. Annotations cover the safety profile. The only real gap is the undocumented limit parameter and result-size behavior, which an agent may need to reason about.

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' is documented in the schema, 'limit' is not. The description richly characterizes query (name, id, country, operator with concrete examples like 'Japan' and 'Six Flags') and the empty-query case, but says nothing about limit's default of 25 or its 200 cap.

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 (search/find) and resource (theme parks this server covers), and enumerates the searchable dimensions (name, id, country, operator). The 'this server covers' scoping plus the themeparks_ prefix clearly separates it from the nationalparks_search_parks and ski_search_resorts siblings.

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 usage context: search by several fields, empty query to list everything, and an explicit handoff to themeparks_get_park_status for the returned ids. It does not state when NOT to use it or name the alternative search tools, so it stops short of full routing guidance.

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