AlertCamp

Watch a park for cancellations and notify the user when a matching stay opens up. TWO QUOTAS can refuse this. The tier quota limits ACTIVE alerts and total watched sites. Separately, a user may hold at most 100 alerts in TOTAL — paused and expired ones included — and at that cap nothing new can be created until some are deleted (pausing does not help). list_my_alerts reports both, and a refusal here returns the same numbers in its structuredContent alongside the message. NOT FOR ROUTE BACKCOUNTRY. Where a park sells backcountry as a traverse — a different site each night — this tool refuses it, because the app offers no plain backcountry alert there and the owner could not inspect or edit one. get_park reports supports_routes: true for those parks; call create_itinerary instead, and note a ONE-NIGHT route is the normal way to watch a single backcountry night, not a workaround. THREE DATE MODES — pick the one the inventory uses, or the alert can never match: 1. Nights (most camping). date_start/date_end are a SEARCH WINDOW, not the stay: date_end is the last night that may be booked, and nights_min is the shortest stay worth notifying about. 2. Entry date (Quetico backcountry, Recreation.gov wilderness permits). These sell ONE ENTRY DATE against a daily quota, not a run of nights — asking for 1 night and 5 returns identical availability. Pass entry_dates with the exact dates wanted; date_start/date_end are then derived from them. A nights-based alert on this inventory NEVER matches. get_park reports backcountry_is_entry_date: true for these parks. 3. Day use (parking time slots, shuttles, Ontario Parks daily vehicle permits). These sell a SLOT or PERMIT on a given day. Pass day_use_cells as {site_id: [dates]}. A park offering this has DayUse in its camp_types. Ontario permits go on sale 5 days ahead; an alert for a later day is accepted and starts matching when the day is released. Use list_park_campgrounds first to get campground ids, then list_campground_zones — for GoingToCamp parks the ZONES are the campgrounds a person names, so a park-wide selection is both imprecise and the largest thing you can ask for. Within a campground, pass ["all"] for zone_ids/site_ids to watch everything, or specific ids to narrow. Every id must be an ID, never a name, and must belong to the park you name. If this is refused for SIZE, narrowing is the remedy: fewer zones, or specific site_ids. Falling back to the whole park makes the selection bigger and will fail again. tier_label is the plan's real name — "essai" is French for trial and is NOT one; it is the permanent free plan. Site caps are READABLE — max_sites_per_alert comes back from list_campground_zones for a campground and from get_alert for an existing alert, and it is per PROVIDER: the same free plan is 200 sites on Ontario Parks and 1 on Oregon State Parks, because a GoingToCamp scan reads a campground in one request while an Aspira scan costs one request per site. The number is readable, so it never has to be established by experiment: a throwaway alert spends a quota slot, and pausing a live one switches off the user's watch. RESOLVE EVERY NARROWING INTO site_ids BEFORE creating this. If the user asked for a shaded site, one near the water, one with a fire pit or 50-amp power, read the attributes from list_zone_sites and pass the ids that qualify — do not pass ["all"] and describe the narrowing in prose. The reason is the OTHER client: the account holder opens this alert in the AlertCamp app, which lists the sites it watches and has no way to show a filter. An alert on ["all"] looks like an alert on everything, cannot be checked, and cannot be edited back. An explicit list is visible, verifiable and editable by the person who owns it. Same for position: if the ask was about the beach, the water or a quiet corner, pick the ids from get_zone_map or the lat/lng in list_zone_sites. An alert on the whole zone will notify them about every site in it, including the ones they ruled out.

create_alert

Watch a MULTI-NIGHT TRAVERSE — a trip needing a different zone each night, which create_alert cannot express. Use this whenever the user describes moving camp: 'four nights across the Rockwall', 'the Skyline end to end'. TWO WAYS TO SPECIFY IT: 1. PLANNED (prefer this). Call list_routes, pass the chosen variant's id as route_id, and OMIT nights — they are filled in from the route. park_id comes with it too. 2. CUSTOM. Pass nights yourself: an ordered list, one entry per night, each naming a campground_id and the zone site_ids that would satisfy it. A night's site_ids are an OR-set — 'night 2 can be Numa Creek OR Tumbling Creek' is one alert, not two. 'all' is refused: a route needs explicit zones. THE WINDOW IS A SEARCH WINDOW, not the trip. Every start day between window_start and window_end is tried, so a wider window is more chances to fire. It must span at least as many days as the route has nights, or nothing could ever match. A route counts as ONE alert against quota however many nights it runs, and its legs never appear in list_my_alerts. REFUSALS ARE INFORMATIVE, not retryable. A custom route can be refused as not walkable (non-adjacent zones), as mixing accommodation types that are booked separately, or as mixing single-permit traverses — a permit is one booking for the whole trip. Re-sending the same nights will be refused again: offer a planned route, or nights the provider can actually sell together.

create_itinerary

Permanently remove a route and stop watching every night of it. PREFER pause_itinerary when the user may want it back — pausing keeps the nights and is reversible, and the nights cannot be rebuilt by editing. A deleted route has to be planned again from scratch, and its nights cannot be rebuilt by editing. Ask the account holder which routes they mean before deleting any you did not just create for them in this conversation.

delete_itinerary

Permanently remove an alert from the user's list. PREFER pause_alert when the user may want it back — pausing keeps the configuration and is reversible. Deleting is nonetheless necessary, not just tidy: a user may hold at most 100 alerts INCLUDING paused and expired ones, and once that cap is reached nothing new can be created until some are deleted. Deleting is PERMANENT and takes the alert's scan history and accumulated odds with it; a recreated alert starts from zero. Ask the account holder which alerts they mean before deleting any you did not just create for them in this conversation — they may hold alerts they never mentioned, and "delete my alerts" is not an instruction to empty the list.

delete_alert

Change a route's window, party size, tent pads or notification channels. THE NIGHTS CANNOT BE EDITED. Their order and adjacency are validated as a whole when the route is created, so changing one in isolation could leave a trip the provider will not sell. To walk a different line, delete this route and create a new one — and say that is what you did. Widening the window is the single most useful edit: more candidate start days is more chances to fire. Send window_start and window_end TOGETHER — one alone is merged with the stored value and may end up too short for the route's length.

update_itinerary

Change an existing alert instead of replacing it. Dates, nights, notifications, party size, activity and equipment can all be edited, and the campground_selections can be NARROWED. Prefer this over delete-and-recreate: an alert carries its scan history and accumulated odds, a recreate throws both away and leaves the user unwatched in between. Prefer it over a second alert too — every alert costs a slot against the tier limit and the 100-alert cap. SELECTIONS ONLY NARROW. You may remove sites, zones or campgrounds; you may not add any, and you may not change the park. Quota is priced on what an alert watches, so an edit that grew a selection would route around the check that priced it. To watch MORE, create a second alert, or delete this one and create it again with the full list — and say which you did. Omit a field to leave it alone; pass null to clear one.

update_alert

The dates a DAY-USE grid offers (start / end), the max_span_days one alert may cover, and closed_cells — the slot/date pairs whose booking window has already shut. Call this before setting day_use_cells. Day use is the one inventory whose season appears NOWHERE in the provider's API — only in the availability grid, and it moves when the next season is released — so dates chosen without it are a guess, and a guess outside the window is an alert that can never match. Where the permits go on sale at a published time, list_zone_sites returns next_release_at for the zone. AlertCamp force-checks the target the moment that instant passes, so a user does not need to be at their phone for the drop — AlertCamp polls on the drop itself. Day use also dies during its own arrival day: each slot has its own cutoff, so a date being in the future does not make it live. Skip anything in closed_cells.

get_day_use_window

The drawn site map as an IMAGE, plus the pixel position of every site on it — the same sheet the app shows a person, with the SITE NUMBERS drawn on at their stored pins. Use it for questions the rows cannot answer in words: which sites sit by the water, at the end of a loop, away from the road. Amenity icons on these sheets have no machine-readable labels, so read the picture as the user would, then convert what you see back into site ids with the coordinates returned alongside it. Say which sites you picked and why, so the user can disagree with your reading. The numbers are OURS, not the provider's — these sheets are published without them — so name sites by those numbers and call again with your shortlist as highlight_site_ids. Some clients display an image returned by a tool and some discard it, and this call cannot report which happened — so whether the user is looking at this sheet is unknown here. Every map also carries an image_url to the same labelled picture, which works in any client and can be passed on: offer it rather than assuming the image arrived. Findings stated in words stand on their own either way. Takes a zone_id, or a campground_id for every sheet in it. Where a campground ships one sheet for all its zones, that sheet is returned for any zone within it. NOT every inventory has one, and its absence is not a dead end: geographic inventories (Recreation.gov, the Aspira tenants, the UseDirect states) carry real lat/lng per site instead, which list_zone_sites returns and which you can reason about without a picture. This tool says so explicitly rather than failing. has_map on list_campground_zones tells you in advance.

get_zone_map

One alert with its scan metrics and, in site_limits, what this alert may watch on ITS provider — read that before offering to widen a selection. NOTE: scan_count and last_checked_at are a MINIMUM across the alert's polling targets, which are scanned independently and phase-staggered — so a fresh multi-zone alert can legitimately show scan_count 0 with a timestamp that predates its own creation. That is the laggard target, not a fault.

get_alert

Full detail for a single park: provider, activities, coordinates, booking URL, whether its backcountry is sold as zones rather than numbered sites, and backcountry_is_entry_date — which decides whether an alert here uses entry_dates or a nights range.

get_park