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.