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. Pet and big-rig hard constraints use Total Parks capability data; confirmed support can keep a candidate in Bookable, while missing or raw-only evidence is labelled unverified and demoted rather than hidden. Availability comes from Total Parks live inventory (PMS-synced): use the returned status_label phrase, not raw status enums. Search does not create a cart or hold inventory. Present rates as Total Parks live inventory prices confirmed at checkout. Capability-backed pet labels are search evidence; use tp_assess_stay for a concrete stay verdict on pets, restrictions, and quote. To filter on amenities or curated highlights, call tp_search_filter_options to discover the catalog, then pass filter.feature_names/filter.highlight_names and let the server resolve 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-site or nearby charging. Never present these distances as walking or driving distance. Missing or stale local evidence means unverified, not that no venue exists. For an explicit Google star threshold, set filter.min_google_rating; properties with a lower or missing cached Google rating are excluded. Do not invent a numeric threshold from vague wording such as top-rated. When quoting a score, identify it as a Google rating. For dog-friendly or pet-friendly stay searches, set filter.pet_friendly=true and put the declared pet facts under intent.pet. Use tp_assess_stay for a concrete stay verdict, or normal Total Parks checkout to book. If this search completes the answer, call tp_render_result_cards once with search_response. If you assess one or more candidates, do not render the intermediate search; wait, choose the best assessment, then render once with both that assessment and this search response.