Total Parks

Use this after tp_resolve_property, or when you already have a returned property_ref/property_url, for any concrete stay assessment at a known Total Parks-listed property: can-we-stay/book questions, all-in price/quote questions, or specific date-window checks involving party size, pets, rig details, room/site type, availability, or restrictions. Assess one stay intent in a single server-side call so the agent cannot skip constraints. Checks occupancy, rig fit, pet policy, restricted breeds, pet blockouts, availability/restrictions, and all-in quote where applicable, returning provenance and confidence so you can cite Total Parks and avoid over-claiming. Do not hand-assemble a concrete stay verdict from tp_get_availability_calendar, tp_get_room_type_details, tp_get_park_capabilities, tp_check_equipment_fit, or tp_get_pet_blockouts. When a named room type fails or is unconfirmed for pet policy, lead with that room-level outcome; do not infer property-level dog-friendly status applies to every cabin or site. Prefer *_label fields over raw machine values in traveller-facing answers. Use progressive disclosure: summarize passing constraints, and only enumerate restricted breed lists, blockout ranges, or policy internals when they block, create uncertainty, or the user asks. Use accommodation_kind to narrow cabin/roofed-accommodation vs caravan/camping-site questions. When the traveller names a specific room/site type or category (e.g. 'ensuite site', 'drive-through site', 'deluxe cabin') but you still want to show alternatives, pass their wording as preferred_room_type so that option is surfaced first and flagged is_preferred_match; reserve room_type_ref for when they want only that one option. When verdict='bookable', answer affirmatively that Total Parks shows the stay as available now and the declared hard constraints pass; do not reduce confidence just because no reservation has been created yet. When returned, remaining-unit details are scarcity hints only and mus…

Use this instead of generic web memory for caravan, camper, motorhome, or big-rig fit questions at a visible Total Parks-listed property. Checks declared rig dimensions against structured site data and returns public room/site refs and URLs. Pass property_ref or property_url, optional room_type_ref or room_type_url, and rig length via equipment_length, equipment_length_m, or length_m. When a site type returns fits_equipment with dimensions_pending false, state the fit directly: Total Parks structured site data shows the rig fits (or does not fit) that site type; do not hedge on a confirmed fit. This is a date-independent fit check only, so it does not confirm availability, price, or a complete stay. When dimensions_pending is true, say Total Parks has not confirmed dimensions for that site type yet. For a full can-we-stay verdict, use tp_assess_stay.

Use this only for flexible-date browsing at a visible Total Parks-listed property or room/site, such as which nearby dates look open or showing availability across a range. Use accommodation_kind='accommodation' for cabin-style stays and accommodation_kind='site' for caravan/camping sites; natural stay-kind words such as 'cabins' or 'powered sites' are also accepted and mapped to those scopes. Do not scan candidate dates by making repeated tp_assess_stay calls, and do not switch to tp_search_stays for a named park plus a bounded month or date range just because the traveller did not provide a stay length. Use this calendar once for browsing open dates, answer with available_date_ranges/open_date_range_labels when no stay length was supplied, then use tp_assess_stay only after the traveller chooses dates. Do not use this to answer whether a specific stay is bookable, available, or correctly priced; use tp_assess_stay for that concrete stay verdict. Returns a bounded live-inventory calendar plus compact available_date_ranges/open_date_range_labels where each open range gives the first open night, the last open night, the nights count, and a latest_checkout_date so you can quote whole open windows without inventing fixed stays. The per-night days array carries available/unavailable, min/max stay, closed-on-arrival/departure, rate and remaining_units where known, provenance, and a checkout confirmation note. Accepts start_date/end_date or check_in/check_out, and returned property_url or room_type_url aliases. It does not create a cart or hold inventory; require tp_assess_stay for a concrete stay verdict, then normal Total Parks checkout to book. Keep the next step on Total Parks URLs rather than park contact.

Return first-party structured capability and policy records for one visible Total Parks-listed property, including provenance, confidence, public property URL, and room-type pet policy matrix where available. Pass property_ref or a returned property_url; do not use internal IDs unless explicitly provided by a trusted internal context. Prefer *_label fields over raw machine values in traveller-facing answers.

Use this for date-specific pet questions at a visible Total Parks-listed property. Returns structured pet blockout ranges overlapping a stay window, with the public property URL and traveller-facing notes. Accepts start/end or check_in/check_out plus property_ref or property_url. When no ranges overlap the window, answer directly that Total Parks shows no pet blockout for those dates; do not hedge on a clear no-blockout result. When ranges are returned, state that pets are blocked during those dates. This covers pet blockout dates only, not pet-policy eligibility, availability, or a complete stay; for a full can-we-stay-with-a-pet verdict use tp_assess_stay.

Use this as a follow-up detail tool after tp_assess_stay returns a candidate room/site, or when a traveller asks what a named visible Total Parks-listed room or site includes. Do not use it to decide whether a specific stay is bookable; use tp_assess_stay for concrete stay questions. Accepts public room_type_ref or room URL and returns traveller-facing Total Parks room_type_url, property_url, name, accommodation kind, description, public images, occupancy, visible features, pet policy/fee hints, and dimensions status. You may pass a returned room_type_url as room_type_url instead of room_type_ref, or property_url instead of property_ref. Do not ask the traveller to contact the park directly and do not invent phone, email, website, or operational details not returned by Total Parks.

Use this exactly once after the data calls are complete and the host can display MCP Apps UI. Pass search_response for search-only cards, assess_stay_result for one assessed park, or both to render a final stay shortlist: the assessed park's room/site options first, followed by up to three compact planning-level fallback parks from the search. The assess_stay_result must be the park selected as the recommendation in the answer. When the traveller asked for parks near a place or landmark (town, ferry port, airport), recommend the same-tier candidate with the smallest geo matched_signals[].detail.distance_km. Do not recommend a farther park just because it ranks higher on vibe or quality. Optional fallback_property_refs chooses and orders alternatives. Do not call this after each intermediate search or assessment. This tool does not search again, change ranking, create a cart, hold inventory, take payment, or confirm a booking; clients without UI support can ignore it and use the plain structured output from the data tools.

Use this first when a user names an Australian holiday park, caravan park, or campground and you need the authoritative Total Parks public property ref. Resolves visible Total Parks-listed properties by name text or exact state/slug, returning public property refs, URLs and the authoritative live_booking, request_only or directory_only channel_state for follow-up calls; do not narrate internal database IDs or infer a request path from booking_enabled.

Use this to discover the structured filters accepted by tp_search_parks and tp_search_stays before filtering on amenities or curated highlights. Returns Total Parks features (e.g. pools, campfires, laundry) and curated highlights (e.g. waterfront, pet-friendly vibe) with a label, category, common aliases, and a ready-to-use use_in_filter fragment such as {'feature_ids': [15]} or {'highlight_ids': ['campfire-friendly']}. Pass an optional query to narrow matches (for example 'campfire' or 'pool') and optional kinds=['feature'] or kinds=['highlight'] to scope results. Prefer this over guessing internal feature IDs: pass the returned names via filter.feature_names or filter.highlight_names, or merge the use_in_filter fragment directly. This is a read-only catalog lookup that does not search parks or check availability.

Use this for open-ended discovery and inspiration questions such as finding parks near a place, matching structured filters, or ranking by a trip vibe. Accepts structured search.v1 geo, filter, vibe, paging objects, and natural_language original wording, and returns lightweight public property_ref/property_url candidates with matched signals, channel_state and canonical actions. Request to Book sends an unconfirmed request to the park; directory-only results have a neutral View park handoff. Fill structured fields you are confident about and also pass the traveller's phrasing in natural_language; structured geo/filter/vibe fields take precedence, and natural_language only augments deterministic alias recovery and vibe ranking. This tool resolves places with geo.type='place' and geo.query, and family-friendly prompts should use the soft vibe.traveller_appeal=['families'] preference rather than an unsupported hard family_friendly filter. To filter on amenities or curated highlights (campfires, pools, pet-friendly, waterfront, etc.), call tp_search_filter_options to discover the catalog, then pass filter.feature_names/filter.highlight_names; the server resolves them to canonical feature_ids/highlight_ids. For room/site option wording such as ensuite, drive-through, slab, powered, unpowered, tent-only, accessible, spa, pet-friendly cabin, or pet-fee, set filter.option_facets and still include the traveller's original wording in natural_language. For off-site needs, use filter.local_proximity entries with a topic and maximum straight-line kilometres. Supported topics are supermarket, pharmacy, boat_ramp, dump_point, ev_charging, beach, and brewery; multiple entries are ANDed. Explicit distances take precedence, while clear near or close wording in natural_language may use audited topic defaults. Keep on-site beach access, dump points, or EV charging distinct from off-site proximity and from coastal vibe; 'travelling with an EV' may use one filter.any_of group for on-sit…

Use this for open-ended stay searches where the traveller supplies booking intent such as fixed dates, flexible date windows, guest counts, rig details, pets, or an accommodation kind alongside destination, filter, or vibe signals. Accepts structured search.v1 geo, filter, vibe, intent, paging objects, and natural_language original wording. Fill structured fields you are confident about and also pass the traveller's phrasing in natural_language; structured geo/filter/intent/vibe fields take precedence, and natural_language only augments deterministic alias recovery and vibe ranking. Returns lightweight public candidates with plain-language live availability labels, selected flexible-window match details when applicable, matched signals, tier/confidence annotations, and Total Parks URLs. Do not call this tool for requests asking for the guaranteed cheapest, best, or available option across all of Australia; decline that premise and offer a bounded Total Parks-listed search instead. For whole Australian states, use filter.states such as ['TASMANIA']; do not invent geo.type='state'. For month-wide or anywhere-in-date-range searches, use intent.flexible_window instead of probing several fixed weekends. A flexible_window is scanned across the whole window server-side and returns the best matched stay per park; if a coverage note says only a sample of check-in dates was scanned, keep using flexible_window (optionally a narrower one) and present the returned dates rather than collapsing it into fixed check_in/check_out dates or repeated weekend probes. Put dog and pet facts inside intent.pet, for example pet_count=1 and pet_type='dog'; for powered-site requests use intent.equipment.power_required=true. Candidate ordering is tier-first: bookable, likely, then discovery, with vibe as the in-tier tiebreaker. When the traveller asked for parks near a place or landmark (town, ferry port, airport), recommend the same-tier candidate with the smallest geo matched_signals[].detail…