Parks Open
Server Details
Live BC Parks campsite and day-pass status with freshness and official booking links.
- Status
- Healthy
- Uptime
- 99.2% over 42 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 8 tools
Each tool targets a clearly separate task, and descriptions include explicit boundary notes (e.g., find_open_parks vs search_campsites vs park_availability_calendar, and park_info vs check_alerts). No two tools overlap enough to cause misselection.
All names use the same parksopen_ prefix and snake_case, with most following verb_noun (check_alerts, find_open_parks, get_booking_link, search_campsites). Two tools use noun phrases (park_info, park_availability_calendar), a minor deviation but still predictable and readable.
Eight tools is well within the ideal range for a park information and availability server. Each tool earns its place by covering a distinct need: alerts, day passes, weather, discovery, booking link, calendar, policy info, and campsite search.
The surface covers discovery, availability, policies, alerts, weather, day passes, and booking handoff, which is nearly complete for decision support. Minor gaps include no dedicated tool for side-by-side park comparison or for listing all parks without date/equipment filters, though workarounds exist.
Available Tools
8 toolsparksopen_check_alertsClosures, fire bans, advisories, nearby wildfiresARead-onlyIdempotentInspect
Use this when checking current closures, fire bans, advisories, or nearby wildfires for one park or system-wide. Run it before recommending a park in summer; these are 'verify before you travel' notices, never a booking or safety claim.
| Name | Required | Description | Default |
|---|---|---|---|
| park | No | park name; omit for a system-wide summary | |
| system | No | reservation system id, e.g. bc_parks. Omit for the default system. | |
| province | No | province code or URL prefix (bc, on, …) — an alternative to system. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, open-world, and idempotent behavior, so the description's extra value comes from clarifying that these are 'verify before you travel' notices and 'never a booking or safety claim.' That caveat prevents the agent from overstating what the data means, which is meaningful behavioral context beyond the 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 front-loaded sentences carry the purpose, the recommended timing, and an important interpretive caveat with zero wasted words. Every clause earns its place in the description.
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 full schema coverage, rich annotations, and an output schema, the description is complete enough for correct invocation. It states what the tool checks, when to run it, the scope options, and how to interpret the results, so nothing essential 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 parameter semantics baseline is 3. The description does add that results can be for 'one park or system-wide,' which aligns with the optional park parameter, but it does not add substantial meaning beyond what the schema already documents.
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 pairs a specific verb, 'checking,' with a concrete resource: current closures, fire bans, advisories, and nearby wildfires, scoped to either one park or system-wide. This clearly differentiates the tool from weather, booking, availability, and park-info siblings without needing to open 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 explicit usage context: 'Use this when checking current closures...' and 'Run it before recommending a park in summer.' It does not explicitly name alternative tools or state when not to use it, but the timing and scope guidance is clear enough for an agent to select it confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parksopen_check_day_passesCheck BC Parks day-pass availabilityARead-onlyIdempotentInspect
Use this when the user asks whether a BC Parks day-use pass is required, available, sold out, not released yet, or closed for a date, park, access area, or AM/PM slot. It returns the access areas currently covered by live checks across a three-day booking window, with explicit No pass needed versus Sold out states, freshness, coverage limits, the Parks Open comparison page, and the official BC Parks booking handoff. If live inventory is stale, incomplete, or conflicts with published rules, it fails closed and will not claim Available or Sold out.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | visit date, YYYY-MM-DD. Omit for today in British Columbia. | |
| days | No | number of consecutive dates to compare, 1 to 3; default is the full 3-day booking window | |
| parks | No | optional park names, e.g. ['Golden Ears', 'Garibaldi']; omit to return every tracked day-pass park |
Output Schema
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| live | Yes | |
| note | Yes | |
| page | Yes | |
| parks | Yes | |
| freshness | Yes | |
| booking_url | Yes | |
| observed_at | Yes | |
| suggestions | Yes | |
| coverage_through | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld), the description discloses fail-closed behavior under stale/conflicting data, freshness, coverage limits, the comparison page, and the booking handoff. This is rich behavioral context an agent could not infer from 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?
Front-loads the usage trigger, then packs return states, coverage limits, and the fail-closed guarantee into dense sentences with little waste. Slightly long, but every clause carries signal.
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?
An output schema exists, so return values need not be explained, yet the description still conveys the key states, freshness, coverage limits, and the fail-closed guarantee. Nothing needed 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 description coverage is 100%, so the schema already documents date, days, and parks, including defaults and bounds. The description adds only the three-day booking-window framing, and mentions 'access area' and 'AM/PM slot' which are not parameters, 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+resource (check BC Parks day-pass availability) and enumerates the exact question states it answers (required, available, sold out, not released, closed). It is clearly distinguishable from siblings like parksopen_search_campsites or parksopen_check_alerts.
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 opening 'Use this when the user asks whether...' gives explicit trigger conditions covering date, park, access area, and AM/PM slot. It does not, however, name a sibling alternative or state when-not to use it, 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.
parksopen_check_weatherForecast and air quality at a parkARead-onlyIdempotentInspect
Use this when the user asks about forecast conditions or air quality at a named park. It returns the Environment Canada forecast (daily high/low/conditions, about 6 days) and AQHI for the nearest station; if the park is beyond range it says so and never invents temperatures.
| Name | Required | Description | Default |
|---|---|---|---|
| park | Yes | park name | |
| system | No | reservation system id, e.g. bc_parks. Omit for the default system. | |
| province | No | province code or URL prefix (bc, on, …) — an alternative to system. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description discloses the data source (Environment Canada), the format (daily high/low/conditions, about 6 days), the AQHI from nearest station, and the honest behavior of saying when out of range and never inventing temperatures. This adds substantial behavioral context beyond the 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?
The description is a single, front-loaded sentence that packs the trigger condition, the output content, and an edge-case guarantee without waste. Every clause adds value, making it concise and well-structured.
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 covers the core purpose, data source, output scope, and a key edge case (out-of-range handling). An output schema exists to define the return structure, so the description doesn't need to repeat that. It is complete for a low-complexity tool, though it doesn't mention error handling for invalid park names, which is a minor 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%, so the input schema already documents all three parameters (park, system, province) with descriptions. The tool description adds no extra parameter-level detail beyond what the schema provides, so it meets the baseline of 3 but does not exceed 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?
The description states a specific action (check forecast and air quality) on a specific resource (named park), and clearly distinguishes from siblings like check_alerts or park_info. The trigger condition is explicit: 'Use this when the user asks about forecast conditions or air quality at a named 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 description gives a clear when-to-use trigger ('when the user asks about forecast conditions or air quality at a named park'), but does not explicitly mention when not to use it or name alternative tools. It implies the scope well but lacks an explicit exclusion or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parksopen_find_open_parksFind parks with openings (ranked)ARead-onlyIdempotentInspect
Use this when the user has not named a park and wants PARKS ranked by soonest opening or estimated drive time, such as 'where can I camp this weekend' or 'anything near Vancouver with space'. It uses the default tent-compatible inventory and can filter confirmed amenities. Do not use it when van, trailer, RV, or other equipment fit matters; use parksopen_search_campsites with equipment_class. For a named park use parksopen_search_campsites or parksopen_park_availability_calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| nights | No | default 2 (weekend) or 1 | |
| region | No | restrict to a region name as the site shows it, e.g. 'Vancouver Island' | |
| system | No | reservation system id, e.g. bc_parks. Omit for the default system. | |
| weekend | No | this coming weekend (Fri→Sun, 2 nights) | |
| province | No | province code or URL prefix (bc, on, …) — an alternative to system. | |
| amenities | No | ANDed site attributes (confirmed-only; the count is a floor) | |
| near_city | No | rank by drive time from this city (Vancouver, Victoria, Nanaimo, Whistler, Kelowna, Kamloops, Cranbrook, Prince George, Fort St. John, Toronto, Ottawa) | |
| start_date | No | a specific arrival date; omit to find the soonest opening | |
| horizon_days | No | how far ahead to look when no date is fixed; default 14 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is its disclosure that the tool silently uses a 'default tent-compatible inventory' and that amenity filters are confirmed-only with the count acting as a floor. These are real behavioral caveats an agent could not infer from the schema. It does not cover pagination or result-size behavior, so it falls short of 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?
Front-loaded with the positively-selecting use case, then the exclusion, then the named-park fallback. Every sentence routes the agent to a decision; the example utterances earn their space by disambiguating intent.
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 an output schema present, return values need no explanation, and the description covers scope, default inventory, and routing for all 10 optional parameters. It stops short of explaining how weekend/nights/horizon_days interact when several are supplied, which is the main remaining ambiguity for a tool where every parameter is optional.
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 already 90% (baseline 3), and the description adds semantics the schema does not carry: the implicit tent-compatible inventory constraint on results and the 'confirmed-only, count is a floor' meaning of the amenities filter. It does not clarify the interaction between weekend and start_date or the region vs province vs system choice.
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 ('PARKS ranked by soonest opening or estimated drive time') and gives concrete user phrasings that map to the tool. It explicitly distinguishes itself from the three sibling tools an agent might otherwise reach for.
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?
Provides explicit when-to-use ('user has not named a park'), when-not-to-use (equipment fit matters), and names the alternative for each branch (parksopen_search_campsites with equipment_class, parksopen_search_campsites / parksopen_park_availability_calendar for a named park). Nothing 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.
parksopen_get_booking_linkBooking link for a park and datesARead-onlyIdempotentInspect
Use this when a search is complete, or when the user already knows the park and dates, to create a deterministic official reservation link with park, dates, and equipment pre-filled. The user completes the booking there; Parks Open never books, holds sites, takes payment, or treats the link itself as proof of availability.
| Name | Required | Description | Default |
|---|---|---|---|
| park | Yes | park name — approximate is fine | |
| system | No | reservation system id, e.g. bc_parks | |
| category | No | ||
| end_date | Yes | ||
| province | No | province code or prefix, e.g. bc | |
| start_date | Yes | ||
| equipment_class | No | canonical class or free text; default tent |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond those: 'The user completes the booking there; Parks Open never books, holds sites, takes payment, or treats the link itself as proof of availability.' This clarifies the tool's non-side-effects and scope, which is not fully covered by annotations. No contradiction.
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 and front-loads the primary usage condition ('Use this when a search is complete...'). The second sentence provides useful cautionary behavior without being overly long. It is appropriately sized, though the behavioral caveat could be slightly more compact.
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 tool's complexity (7 params, 3 required, one enum) and the presence of an output schema, the description covers the key contextual aspects: what it creates, when to use it, and what it does not do. It lacks specific details about parameter constraints, but the schema and output schema cover return values. The description is sufficient for an agent to decide when and how to invoke it.
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 57%, meaning 3 parameters (end_date, start_date, category) lack descriptive text. The description only mentions 'park, dates, and equipment pre-filled,' adding minimal meaning. It does not clarify the expected date format, the purpose of 'system' or 'province', or how 'category' affects the link. With moderate coverage, the description should compensate more than it does.
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 states the tool's function: 'create a deterministic official reservation link with park, dates, and equipment pre-filled.' It also distinguishes itself from sibling tools (search, availability, info) by explicitly noting this is for when a search is complete or park/dates are already known. This makes the tool's role unambiguous.
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 explicitly states when to use the tool: 'when a search is complete, or when the user already knows the park and dates.' It also implies when not to use it by excluding booking behavior ('Parks Open never books...'), but it does not name alternative sibling tools or provide a direct contrast. This is clear context with only minor missing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parksopen_park_availability_calendarPark availability calendar (8 weeks)ARead-onlyIdempotentInspect
Use this when the user asks 'when is X free', 'how busy is X', or 'which weekend should I try' for ONE named park. It returns nightly open counts for the next 8 weeks, whole-stay counts for four weekends, fill rate, and booking rules. For exact equipment fit or specific dates across many parks use parksopen_search_campsites.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| park | Yes | park name — approximate is fine | |
| system | No | reservation system id, e.g. bc_parks | |
| province | No | province code or prefix, e.g. bc |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses result contents: nightly open counts, whole-stay counts for four weekends, fill rate, and booking rules. It is slightly loose about the 8-week window, which the configurable days parameter can extend up to 92 days, but that is a minor semantic wrinkle.
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, each earning its place: one for when to use, one for what it returns, and one for the alternative. The trigger phrases are front-loaded and 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?
Given the output schema, the description does not need to enumerate return fields, and it covers scope, trigger, output highlights, and the main alternative. The only substantive gap is the days parameter, whose effect is neither described in the schema nor clearly connected to the '8 weeks' language in 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?
The schema already documents park, system, and province. The description adds usage context for park ('ONE named park') and implies a default time window ('next 8 weeks', 'four weekends'), but it never explains the days parameter or how it affects the calendar range, leaving that parameter largely 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 states a specific action for a bounded resource: 'returns nightly open counts for the next 8 weeks' for 'ONE named park'. It also anchors the trigger phrases ('when is X free', 'how busy is X', 'which weekend should I try'), distinguishing it clearly from sibling tools, especially parksopen_search_campsites.
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 opens with 'Use this when...' and gives concrete user-query examples. It then names the alternative and the condition for choosing it: 'For exact equipment fit or specific dates across many parks use parksopen_search_campsites.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parksopen_park_infoPark facts, rules and fees (knowledge base)ARead-onlyIdempotentInspect
Use this when the user asks about reservation policy, fees, pets, fires, facilities, or park descriptions, such as 'does X allow dogs' or 'when do reservations open'. Verified policy knowledge currently covers BC Parks only; other systems return an explicit unsupported answer with the official source. Specify system or province for general policy questions; without a park or system the scope is BC Parks. Do not use it for availability (parksopen_search_campsites) or current closures (parksopen_check_alerts).
| Name | Required | Description | Default |
|---|---|---|---|
| park | No | park name, when the question is about one park | |
| system | No | reservation system id, e.g. bc_parks | |
| province | No | province code or prefix, e.g. bc | |
| question | Yes | what you want to know (fees, pets, fires, showers, reservations policy…) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: verified policy coverage is limited to BC Parks, other systems return an explicit unsupported answer with an official source, and the default scope falls back to BC Parks. It does not discuss answer length or formatting, but the coverage limit and fallback are the important disclosures.
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 dense sentences, front-loaded with the use case, then coverage caveat, then routing exclusions. Every clause carries decision-relevant information with 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?
An output schema exists, so return-value explanation is unnecessary. Given four optional params at full schema coverage and rich annotations, the description supplies the remaining gaps — coverage limits, default scope, and sibling routing — making it complete 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 description coverage is 100%, so the baseline is 3, but the description adds selection semantics the schema lacks: specify system or province for general policy questions, and omitting park/system defaults the scope to BC Parks. That is a real rule about how the optional parameters interact, not a restatement.
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 knowledge-base retrieval purpose with concrete topic coverage (reservation policy, fees, pets, fires, facilities) and example questions. The title and description together make it unmistakable versus the availability and alerts 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 both when-to-use ('user asks about reservation policy, fees, pets...') and explicit exclusions routing to parksopen_search_campsites for availability and parksopen_check_alerts for closures. It even names the sibling tools for those cases, 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.
parksopen_search_campsitesSearch campsites by live availabilityARead-onlyIdempotentInspect
Use this when exact dates or equipment fit matter, for questions like 'is X available', 'find a site for the long weekend', or 'which parks have space for a 32 ft RV'. It reads observed campsite availability for BC Parks and limited Ontario Parks coverage (15 reservation locations, frontcountry camping only). Ontario camping alerts are not enabled. Filters the official sites cannot: exact equipment fit, electrical, waterfront, shade, pets, privacy — across every park at once. Returns only sites observed open for EVERY requested night, with an absolute Parks Open page URL to cite, a booking link into the official reservation flow (we never book for the user), and observed_at for freshness; verify availability on the official site. Not for: fees, rules, facilities (use parksopen_park_info), weather (parksopen_check_weather), closures (parksopen_check_alerts), or dates beyond the provider's booking window.
| Name | Required | Description | Default |
|---|---|---|---|
| park | No | park name — approximate is fine (partial, missing 'Provincial', misspelled). Omit to search every park. If it cannot be resolved you get a did-you-mean list. | |
| limit | No | page size, default 20 | |
| cursor | No | opaque cursor from a previous page | |
| system | No | reservation system id, e.g. bc_parks. Omit for every tracked system. | |
| category | No | booking category; default frontcountry (drive-in campsites) | |
| end_date | Yes | departure, YYYY-MM-DD (exclusive; nights = end − start) | |
| province | No | province code or URL prefix (bc, on, …) — an alternative to system. | |
| amenities | No | ANDed site attributes: electrical, waterfront, pets, some_shade, full_shade, double, near_restroom, walk_in, accessible, pull_through, private, big_rig | |
| start_date | Yes | arrival, YYYY-MM-DD | |
| min_privacy | No | 'Good' or 'Excellent' | |
| equipment_class | No | canonical class (tent, tent2, tent3, van, trailer_18, rv_32, rv_32_plus) or free text like '30ft trailer'. Default tent. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| total | Yes | |
| nights | Yes | |
| closure | Yes | |
| results | Yes | |
| next_cursor | Yes | |
| observed_at | Yes | |
| suggestions | Yes | |
| resolved_park | Yes | |
| equipment_class | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, yet the description adds substantial operational context: coverage limits (BC Parks + 15 Ontario locations, frontcountry only), disabled Ontario alerts, 'we never book for the user', observed_at freshness, and the verify-on-official-site caveat. It doesn't cover pagination behavior or rate limits, keeping it just short of 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?
Front-loaded with trigger and scope before pivoting to capability, return shape, then exclusions — a logical order. It is dense and long for a single paragraph, but nearly every clause carries information; the 'Not for' list is compact and high-value 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?
An output schema exists so return-value detail isn't required, yet the description still summarizes the return (only sites open every night, citable URL, booking link, observed_at). Combined with coverage limitations, provider-window caveat, and sibling routing, an agent has everything needed 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 description coverage is 100%, so the schema already documents park resolution, dates, limit/cursor, system/province, category, amenities and equipment_class. The description reinforces the filter concepts (equipment fit, electrical, waterfront, shade, pets, privacy) but adds no syntax or format detail beyond the schema, 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?
Starts with a specific verb+resource ('Search campsites by live availability') and immediately scopes it ('exact dates or equipment fit'). The examples ('is X available', '32 ft RV') make the intent unmistakable and differentiate it from the sibling availability/park 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 explicit when-to-use triggers, concrete question patterns, and a full 'Not for:' list routing fees/rules to parksopen_park_info, weather to parksopen_check_weather, and closures to parksopen_check_alerts. Alternatives and exclusions are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
parksopen_find_open_parks1 field changed- changed
Input schema / properties / near_city / descriptionPrevious value: -"rank by drive time from this city (Vancouver, Victoria, Nanaimo, Whistler, Kelowna, Kamloops, Cranbrook, Prince George, Fort St. John)"New value: +"rank by drive time from this city (Vancouver, Victoria, Nanaimo, Whistler, Kelowna, Kamloops, Cranbrook, Prince George, Fort St. John, Toronto, Ottawa)"
- Changed
parksopen_park_info6 fields changed- added
Input schema / properties / provinceAdded value: +{ + "description": "province code or prefix, e.g. bc", + "type": "string" +} - added
Input schema / properties / systemAdded value: +{ + "description": "reservation system id, e.g. bc_parks", + "type": "string" +} - removed
Output schema / additionalPropertiesRemoved value: -false - added
Output schema / anyOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "context": { + "type": "string" + }, + "note": { + "type": "string" + }, + "park": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "park", + "context", + "sources", + "note" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "type": "string" + }, + "suggestions": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "error" + ], + "type": "object" + } +] - removed
Output schema / propertiesRemoved value: -{ - "context": { - "type": "string" - }, - "note": { - "type": "string" - }, - "park": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "name": { - "type": "string" - }, - "slug": { - "type": "string" - } - }, - "required": [ - "slug", - "name" - ], - "type": "object" - }, - { - "type": "null" - } - ] - }, - "sources": { - "items": { - "type": "string" - }, - "type": "array" - } -} - removed
Output schema / requiredRemoved value: -[ - "park", - "context", - "sources", - "note" -]
1 tool update
- Changed
parksopen_check_day_passes1 field changed- changed
Output schema / properties / freshness / enumPrevious value: -[ - "ok", - "no-database", - "no-data", - "incomplete", - "conflict", - "stale", - "error" -]New value: +[ + "ok", + "no-database", + "no-data", + "incomplete", + "conflict", + "stale", + "unknown", + "error" +]
8 tool updates
- Changed
parksopen_check_alerts1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "alert": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "access_status": { + "type": "string" + }, + "closed_to_visitors": { + "type": "boolean" + }, + "detail": { + "type": "string" + }, + "from": { + "type": [ + "string", + "null" + ] + }, + "severity": { + "type": "string" + }, + "title": { + "type": "string" + }, + "type": { + "type": "string" + }, + "until": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": "string" + } + }, + "required": [ + "type", + "severity", + "title" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "park": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": "string" + }, + "summary": { + "additionalProperties": false, + "properties": { + "examples": { + "items": { + "type": "string" + }, + "type": "array" + }, + "fireBansOrClosures": { + "type": "number" + }, + "parksNearWildfire": { + "type": "number" + }, + "total": { + "type": "number" + } + }, + "required": [ + "total", + "fireBansOrClosures", + "parksNearWildfire", + "examples" + ], + "type": "object" + } + }, + "required": [ + "park", + "alert", + "source" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "type": "string" + }, + "suggestions": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Added
parksopen_check_day_passes - Changed
parksopen_check_weather1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "park": { + "type": [ + "string", + "null" + ] + }, + "weather": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "aqhi": { + "type": [ + "number", + "null" + ] + }, + "city": { + "type": "string" + }, + "currentTemp": { + "type": [ + "number", + "null" + ] + }, + "days": { + "items": { + "additionalProperties": false, + "properties": { + "condition": { + "type": "string" + }, + "date": { + "type": "string" + }, + "high": { + "type": [ + "number", + "null" + ] + }, + "icon": { + "type": "string" + }, + "label": { + "type": "string" + }, + "low": { + "type": [ + "number", + "null" + ] + }, + "pop": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "date", + "label", + "high", + "low", + "icon", + "condition", + "pop" + ], + "type": "object" + }, + "type": "array" + }, + "updated": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "city", + "updated", + "currentTemp", + "days", + "aqhi" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "park", + "weather" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "type": "string" + }, + "suggestions": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
parksopen_find_open_parks1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amenities_applied": { + "items": { + "type": "string" + }, + "type": "array" + }, + "horizon_days": { + "type": "number" + }, + "nights": { + "type": "number" + }, + "note": { + "type": "string" + }, + "observed_at": { + "type": [ + "string", + "null" + ] + }, + "parks": { + "items": { + "additionalProperties": false, + "properties": { + "drive_min": { + "type": [ + "number", + "null" + ] + }, + "earliest_date": { + "type": "string" + }, + "earliest_offset_days": { + "type": "number" + }, + "ferry": { + "type": "boolean" + }, + "page": { + "type": "string" + }, + "park": { + "type": "string" + }, + "region": { + "type": [ + "string", + "null" + ] + }, + "sites_open": { + "type": "number" + } + }, + "required": [ + "park", + "page", + "region", + "earliest_date", + "earliest_offset_days", + "sites_open", + "drive_min", + "ferry" + ], + "type": "object" + }, + "type": "array" + }, + "total_with_openings": { + "type": "number" + }, + "window": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "nights", + "horizon_days", + "window", + "amenities_applied", + "parks", + "total_with_openings", + "observed_at", + "note" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "type": "string" + }, + "suggestions": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
parksopen_get_booking_link1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "booking_url": { + "type": "string" + }, + "equipment_class": { + "type": "string" + }, + "page": { + "type": "string" + }, + "park": { + "type": "string" + }, + "park_key": { + "type": "string" + }, + "system": { + "type": "string" + } + }, + "required": [ + "system", + "park", + "park_key", + "equipment_class", + "booking_url", + "page" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "type": "string" + }, + "suggestions": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
parksopen_park_availability_calendar1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "fill_rate_pct": { + "type": [ + "number", + "null" + ] + }, + "nights": { + "items": { + "additionalProperties": false, + "properties": { + "date": { + "type": [ + "string", + "null" + ] + }, + "open_sites": { + "type": "number" + } + }, + "required": [ + "date", + "open_sites" + ], + "type": "object" + }, + "type": "array" + }, + "note": { + "type": "string" + }, + "observed_at": { + "type": [ + "string", + "null" + ] + }, + "page": { + "type": "string" + }, + "park": { + "type": "string" + }, + "park_key": { + "type": "string" + }, + "reservable_sites": { + "type": "number" + }, + "rules": { + "additionalProperties": false, + "properties": { + "max_nights": { + "type": [ + "number", + "null" + ] + }, + "min_lead_days": { + "type": "number" + }, + "window": { + "type": "string" + } + }, + "required": [ + "window", + "min_lead_days", + "max_nights" + ], + "type": "object" + }, + "system": { + "type": "string" + }, + "weekends": { + "items": { + "additionalProperties": false, + "properties": { + "end": { + "type": "string" + }, + "label": { + "type": "string" + }, + "open_for_whole_stay": { + "type": "number" + }, + "start": { + "type": "string" + } + }, + "required": [ + "start", + "end", + "label", + "open_for_whole_stay" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "system", + "park", + "park_key", + "page", + "reservable_sites", + "fill_rate_pct", + "nights", + "weekends", + "rules", + "observed_at", + "note" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "error": { + "type": "string" + }, + "suggestions": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "error" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
parksopen_park_info1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "context": { + "type": "string" + }, + "note": { + "type": "string" + }, + "park": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "park", + "context", + "sources", + "note" + ], + "type": "object" +}
- Changed
parksopen_search_campsites1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "closure": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "park": { + "type": "string" + }, + "source": { + "type": "string" + }, + "title": { + "type": "string" + }, + "until": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "park", + "title", + "until", + "source" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "equipment_class": { + "type": "string" + }, + "next_cursor": { + "type": [ + "string", + "null" + ] + }, + "nights": { + "type": "number" + }, + "note": { + "type": "string" + }, + "observed_at": { + "type": [ + "string", + "null" + ] + }, + "resolved_park": { + "type": [ + "string", + "null" + ] + }, + "results": { + "items": { + "additionalProperties": false, + "properties": { + "attributes": { + "additionalProperties": false, + "properties": { + "adjacent": { + "type": [ + "string", + "null" + ] + }, + "electrical": { + "type": [ + "string", + "null" + ] + }, + "privacy": { + "type": [ + "string", + "null" + ] + }, + "shade": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "privacy", + "shade", + "electrical", + "adjacent" + ], + "type": "object" + }, + "booking_url": { + "type": "string" + }, + "fit": { + "type": "string" + }, + "loop": { + "type": "number" + }, + "nights": { + "type": "number" + }, + "page": { + "type": [ + "string", + "null" + ] + }, + "park": { + "type": "string" + }, + "park_key": { + "type": "string" + }, + "site_id": { + "type": "number" + }, + "slug": { + "type": [ + "string", + "null" + ] + }, + "system": { + "type": "string" + } + }, + "required": [ + "system", + "park", + "park_key", + "slug", + "page", + "site_id", + "loop", + "nights", + "fit", + "attributes", + "booking_url" + ], + "type": "object" + }, + "type": "array" + }, + "suggestions": { + "items": { + "type": "string" + }, + "type": "array" + }, + "total": { + "type": "number" + } + }, + "required": [ + "results", + "total", + "next_cursor", + "nights", + "equipment_class", + "resolved_park", + "suggestions", + "observed_at", + "closure", + "note" + ], + "type": "object" +}
7 tool updates
- First observed
parksopen_check_alerts - First observed
parksopen_check_weather - First observed
parksopen_find_open_parks - First observed
parksopen_get_booking_link - First observed
parksopen_park_availability_calendar - First observed
parksopen_park_info - First observed
parksopen_search_campsites
Related MCP Connectors
Catch campsite, cabin, permit and day-use cancellations at 1,600+ parks in Canada and the US.
Live US campground availability, wildfire and river conditions, and trails on public land.
Live status of the physical world: ski lifts, theme park rides, national parks, campgrounds, surf.
US backcountry permit and campground rules, dates and recorded openings. Read-only, no sign-in.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables AI clients to search and browse camping availability across Alberta Parks, BC Parks, and Parks Canada, including front-country and backcountry campgrounds, through a unified set of tools.-
- AlicenseBqualityDmaintenanceProvides real-time access to BC highway conditions, road closures, weather alerts, and traffic incidents through the Open511-DriveBC API with smart caching.4MIT
- AlicenseNot gradedqualityAmaintenancePlan US National Park Service trips — find parks, check alerts and closures, find campgrounds, browse things to do and events via the NPS Data API. Supports STDIO and Streamable HTTP.294 npm2Apache 2.0
- AlicenseBqualityDmaintenanceProvides real-time information about U.S. National Parks through the NPS API, enabling users to search parks, check details, alerts, visitor centers, campgrounds, and upcoming events.673 npm41MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.