Skip to main content
Glama

Parks Open

by ca.parksopen

Park availability calendar (8 weeks)

parksopen_park_availability_calendar
Read-onlyIdempotent

For ONE park: how many sites are open on each night for the next 8 weeks, the whole-stay open count for the next four weekends, the fill rate, and the park's booking rules. Use it for 'when is X free', 'how busy is X', 'which weekend should I try'. For specific dates across many parks use parksopen_search_campsites.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo
parkYespark name — approximate is fine
systemNoreservation system id, e.g. bc_parks
provinceNoprovince code or prefix, e.g. bc

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Parks Open toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

The tools are mostly distinct: alerts, weather, park info, booking links, and availability each target clear concerns. The only real overlap risk is parksopen_find_open_parks vs parksopen_search_campsites, since both can answer 'which parks have openings', though their descriptions try to separate the no-specific-park vs specific-dates/equipment cases.

Naming Consistency4/5

All tools share the parksopen_ prefix and use snake_case, which helps. Most follow a verb_noun pattern (check_alerts, check_weather, find_open_parks, get_booking_link, search_campsites), but parksopen_park_availability_calendar and parksopen_park_info are noun-first deviations, making the set slightly less predictable.

Tool Count5/5

Seven tools is well-scoped for a camping/reservation assistant: search, find, calendar, alerts, weather, info, and booking link cover the main user journey without bloat. Each tool appears to earn its place.

Completeness5/5

The tool surface covers the full assisted workflow: discovering open parks, checking live availability for dates, viewing multi-week calendars, retrieving park rules and fees, checking alerts and weather, and generating booking links. The explicit decision not to book on the user's behalf is handled through parksopen_get_booking_link, so no critical lifecycle step is missing.

Resources