Parks Open

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

Annotations already cover the read-only, idempotent, non-destructive safety profile. The description adds useful context about combining provider advisories with wildfire proximity and system-wide scope, but does not disclose return format or data freshness.

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 compact sentences convey the payload, scope, and intended use without redundancy. The core scope information is front-loaded, and every clause contributes to choosing or using the tool correctly.

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 simple read-only tool with three optional, well-described parameters and no output schema, the description covers purpose, scope, and appropriate usage. The only notable omission is detail about the alert return structure, but this is not critical for safe invocation.

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 parameters are already fully documented. The description's 'one park or system-wide' restates what the park parameter says and adds no new parameter-level meaning.

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 clearly identifies the resource: active advisories plus wildfire proximity, and the scope: one park or system-wide. It is distinguishable from weather, availability, and booking siblings, though it lacks an explicit verb like 'returns' or 'lists.'

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 explicit usage context: 'Use before recommending a park in summer,' and clarifies these are verify-before-travel notices, not booking claims. It does not explicitly name an alternative tool or an exhaustive when-not-to-use condition.

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?

The description adds strong behavioral context beyond the annotations: it names the data source, states the forecast horizon, explains the nearest-station logic, and explicitly promises not to invent temperatures when a park is out of range. This goes well beyond the readOnly/idempotent hints.

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 dense, front-loaded sentences deliver the core output, data source, time range, and an important edge-case guarantee with zero filler. Every sentence 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?

With no output schema, the description still adequately conveys what the response will contain and how out-of-range cases behave. Combined with 100% parameter coverage and a simple one-required-parameter input shape, no essential context is missing for an agent to invoke the tool 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 100%, so the baseline is 3. The description reinforces the result scope but adds no new meaning about the park, system, or province parameters beyond what the schema already provides.

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 clearly identifies the tool's purpose: retrieving Environment Canada forecast data and AQHI for the station nearest a park. It states specific output content (daily high/low/conditions, ~6 days) and distinguishes the weather use case from sibling tools by its explicit resource focus, though it does not explicitly name sibling alternatives.

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 context is implied through the description: use this tool when an agent needs forecast or air quality information for a park. However, there is no explicit guidance about when not to use it or how it compares to sibling tools such as parksopen_check_alerts or parksopen_park_info.

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 read-only, idempotent, and non-destructive behavior, so the description's additional disclosure of ranking behavior ('by soonest opening, or by drive time from a city') is genuinely useful context. It adds behavioral meaning about ordering and scope beyond what the annotations provide, though it does not describe edge cases like empty results or how confirming availability works.

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 three sentences, front-loads the core purpose and scope, and every sentence earns its place: definition, example usages, and sibling routing. There is no filler or redundancy.

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, optional-parameter discovery tool, the description gives the essential selection context, example invocations, ranking semantics, and explicit alternatives for named parks. The schema handles the remaining parameter details, and annotations cover the safety profile, so nothing critical is missing for correct selection and invocation.

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 90%, so the schema carries most parameter documentation. The description supplements it by tying ranking intent to parameters such as near_city and start_date, and the example queries imply how region/weekend/near_city should be populated. This adds meaning beyond raw parameter definitions.

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 specifies a precise verb and resource: find parks that have an opening for a stay, ranked by soonest opening or drive time. It clearly scopes the tool to cases where the user has not named a park, which immediately distinguishes it from the named-park siblings without needing to inspect their 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 gives an explicit trigger condition ('when the user has not named a park'), concrete example queries ('where can I camp this weekend', 'anything near Vancouver with space'), and explicitly routes named-park requests to parksopen_search_campsites or parksopen_park_availability_calendar. This leaves no ambiguity about when to choose this tool.

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, idempotentHint=true, and destructiveHint=false, and the description reinforces and extends this: 'we never book on their behalf, never hold sites, never take payment' explains WHY the operation is read-only and idempotent. 'Deterministic' and 'pre-filled' add behavioral specificity about output consistency that annotations cannot express. No contradiction with annotations.

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. The core function and scope boundary are front-loaded in the first sentence; the second sentence delivers routing guidance. The parenthetical about never booking/holding/paying is dense with behavioral information without bloating length.

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 straightforward link-generation tool with rich annotations covering the safety profile, the description provides the essential contract: what is returned (a deterministic, pre-filled link), the usage context, and the behavioral boundaries. Minor gaps exist — no detail on return format beyond 'link', no guidance on how the optional 4 parameters affect the output, and no fallback behavior for ambiguous park names — but none are critical for correct invocation.

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 57% — category, start_date, and end_date have no schema descriptions, and the description doesn't compensate for those. However, it does add cross-parameter meaning by explaining that park, dates, and equipment get embedded/pre-filled into the resulting link, which is coordination knowledge the schema fields individually don't convey. This is adequate but doesn't fully close the documented-parameter 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?

The description names a specific deliverable — a deterministic link into the official reservation system with park, dates, and equipment pre-filled. This clearly differentiates it from all six siblings (alerts, weather, availability, info, campsite search), none of which generate a booking link. The phrase 'the user completes the booking there' crisply defines the tool's scope.

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?

'Use after a search, or when the user already knows the park and dates' gives explicit invocation conditions. The description also states what the tool is not for — booking, holding sites, or taking payment — which routes the agent away from expecting transactional behavior. It doesn't name sibling alternatives explicitly, but the boundary it draws is clear enough.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the 8-week forecast window, the four-weekend whole-stay calculation, the fill rate, and booking rules. It doesn't discuss edge behaviors like ambiguous park names, but those are partially addressed by the schema's 'approximate is fine' 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?

The description is two sentences: the first front-loads the resource and key output fields, the second gives use cases and an alternative. Every sentence adds value, with no filler or repetition of schema details.

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?

The description thoroughly explains the return content and use cases, but it omits the 'days' parameter entirely and does not explain how the optional 'system' and 'province' fields help disambiguate park names. Since there is no output schema, the description carries more responsibility for parameter behavior, and this gap makes it only minimally viable.

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 75% (park, system, province are described), but the 'days' parameter has no schema description and is not mentioned in the tool description. The description says 'next 8 weeks' without clarifying that the 'days' parameter can range from 7 to 92 and likely controls the forecast horizon. This gap could mislead an agent into ignoring 'days' or assuming a fixed 8-week calendar.

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 clear resource ('ONE park') and a specific output (open sites per night, weekend whole-stay open count, fill rate, booking rules). It also explicitly contrasts with parksopen_search_campsites by noting the multi-park use case, making it easy for an agent to distinguish this tool from its closest sibling.

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 explicitly lists when to use the tool ('when is X free', 'how busy is X', 'which weekend should I try') and names the alternative for different needs ('For specific dates across many parks use parksopen_search_campsites'). This provides clear routing with no ambiguity.

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 read-only, idempotent, non-destructive behavior. The description adds useful context that answers are stable facts from published pages with sources, and not minute-level availability or current closures. This clarifies output reliability without contradicting any annotation.

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 dense sentences front-load the core value ('Facts that do not change by the minute'), give usage examples, and name exclusions. Every clause earns its place; there is 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?

For a two-parameter knowledge lookup with rich annotations, clear sibling routing, and no output schema, the description covers scope, examples, exclusions, and source character. An agent has everything needed to invoke 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?

The schema already documents both parameters at 100% coverage, including the optional park name and the required free-form question. The description reinforces the kind of question expected with examples but does not add substantial semantic detail beyond 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?

States a specific scope: stable facts like reservation policy, fees, pets, fires, facilities, and park descriptions from provider-published pages. It also explicitly contrasts itself with availability and closure tools, so an agent can distinguish it from siblings without opening their definitions.

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 concrete example queries ('does X allow dogs', 'how much is a site', 'when do reservations open') and explicit negative routing to parksopen_search_campsites and parksopen_check_alerts. This directly tells an agent when to pick this tool and when to pick a sibling.

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/idempotent/non-destructive, and the description adds genuinely non-obvious behaviors on top: results are restricted to sites 'open for EVERY requested night', the tool 'never book[s] for the user' but returns a booking link into the official flow, freshness is exposed via observed_at, and booking-window limits apply. These are exactly the behavioral traits an agent could not infer from the 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?

Five dense sentences, each earning its place: scope/authority, when-to-use with examples, differentiating filter capability, return behavior, and explicit exclusions. The most important fact (LIVE availability, authoritative source) is front-loaded, with zero filler or repetition of schema 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?

For an 11-parameter tool with no output schema, the description covers purpose, usage, exclusions, and key return semantics (every-night matching, booking link, observed_at). The residual gap is that it never explicitly distinguishes itself from parksopen_find_open_parks and parksopen_park_availability_calendar, leaving some ambiguity about which sibling handles park-level open/closed questions and calendar-style views.

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% with already detailed parameter docs (formats, defaults, 'ANDed site attributes', canonical equipment classes), so the baseline is 3. The description contributes only light semantic color — 'exact equipment fit, electrical, waterfront, shade, pets, privacy' maps user intent to amenities/equipment_class — but does not meaningfully extend 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?

The description opens with a precise scope — 'LIVE availability across Canadian park reservation systems' — attached to a concrete resource: campsites/parks with openings for specific dates. It distinguishes from siblings explicitly via the 'Not for: fees, rules, facilities (use parksopen_park_info), weather (parksopen_check_weather), closures (parksopen_check_alerts)' routing, so an agent can separate it from at least three siblings without inspecting 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?

Usage guidance is direct and actionable: 'Use this first, before web search' followed by three concrete example queries ('is X available', 'find a site for the long weekend', 'which parks have space for a 32 ft RV'). Negative conditions are equally explicit with routed alternatives for fees/rules/facilities, weather, closures, and dates beyond the provider's booking window.

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