Check which MyNextAdventure account the current API key belongs to. Use this when you are unsure whether the connection is authenticated, or to confirm whose trips you are about to change before making edits.

List the trips the user owns or collaborates on. Start here whenever the user refers to a trip by name ("my Japan trip") so you can resolve it to a trip id. Statuses: 'planning' is actively being worked on, 'ready' is planned but not taken yet, 'finished' is in the past, 'cancelled' was dropped. Call with no filters to see everything.

Fetch one trip in full: its variants, destinations, accommodation / transport / getting-around options and events. Call this before changing anything — every other tool needs the variant ids, destination keys and option keys this returns.

Create a new, empty trip — the container everything else hangs off. This is step 1 of planning: create the trip, then create_variant for the dates, then add_destination, then the accommodation / transport / event options. Ask the user for a name if they have not given one.

Change top-level trip fields: rename it, set a cover photo, or move it through its lifecycle (planning -> ready once the plan is settled, finished or cancelled afterwards). Does not touch variants, destinations or options.

Create (or refresh) a public read-only link to the trip so the user can send the plan to people without an account. Returns the shareable URL. Use when the user asks to share, send or publish a trip.

Add an alternative version of the trip — "Beach option" vs "Mountain option", or the same route on different dates. A trip needs at least one variant before it can hold destinations or options, so create one right after create_trip. Dates live on the variant: either exact start/end dates or a flexible window with min/max nights.

Copy a variant, with all of its destinations and options, into a new variant on the same trip. Use when the user wants to explore a tweak ("same trip but a week later", "same route, cheaper hotels") without losing the original.

Rename a variant, change its dates (exact dates or a flexible window), edit its notes, or set who is travelling. Returns the variant as it now stands — read the response to confirm your change landed rather than assuming it did.

Mark one variant as the trip's chosen plan. Use when the user decides between alternatives; the choice is reversible, so selecting a different variant later is fine.

Add a place the traveller will stay at within a variant, in itinerary order (e.g. "Lisbon, Portugal"). Destinations are what accommodation, transport and getting-around options attach to, so add these before adding options. Set isReturnToHome for the final leg home.

Change a destination's place name, its arrival/departure dates, or its notes. Use this to pin down when the traveller is in each place once the dates firm up, rather than deleting and re-adding the stop.

Rearrange the itinerary order of a variant's destinations. Use after adding stops out of order, instead of deleting and re-adding them.

Propose somewhere to stay at a destination — hotel, hostel, apartment, house or camping. Add several options to the same destination so the user can compare them, then use select_destination_option once they pick one. Always include the total cost and currency, otherwise the trip budget will be wrong. Keep name a clean display name — price, town, dates and commentary belong in their own fields, not in name.

Propose a way of travelling TO a destination — flight, train, bus, ferry, car. One option per candidate itinerary; add several so the user can compare price against travel time. Set roundTrip when the price covers the return leg too. For moving around once there, use add_getting_around_option instead.

Propose how the traveller moves around locally once at a destination — walking, public transport, rental car, bike, ride share. Use this for local mobility budgets; the journey between destinations belongs in add_transport_option.

Edit an existing accommodation, transport or getting-around option — correct a price, add a booking link, adjust check-in dates. Say which kind of option it is and pass the option key from get_trip. Only the fields you send are changed.

Mark one accommodation / transport / getting-around option as the one the traveller will actually use, or clear the current choice. Always say which kind of option it is; pass optionId to select that option, or omit optionId to deselect whatever is currently selected of that kind. Returns the destination as it now stands, so you can see which option ended up selected. Prefer this over deleting the alternatives — they stay available for comparison.

Add something to do during the trip — a museum, concert, restaurant, tour or activity. Events belong to the variant rather than to a single destination, and can be scheduled with start/end times or left unscheduled as ideas.

Edit an existing event: fix its time, price, location, booking link or notes. Use when the user has new information about an activity that is already on the plan ("the tour starts at 10, not 9").

Flip an event between "we are doing this" and "just an idea" on the variant. Use when the user commits to, or backs out of, an activity — this keeps the event around, unlike delete_trip_item.

Permanently delete part of a trip: a variant, a destination, a destination option, or an event. Use only when the user rejects something outright — if they might still want it later, deselect the option or toggle the event instead. Deleting a variant or a destination also deletes everything inside it, so confirm with the user first.

List the user's travel goals — the places and experiences on their bucket list ("See the Northern Lights"). Use this for inspiration when starting a new trip, or when the user asks what is on their list. Statuses: 'dreaming' is not planned yet, 'planning' is already linked to a trip, 'visited' is done.

Add a travel goal to the user's bucket list from a plain name or a URL — the server works out which and enriches it. Use when the user mentions something they would love to do some day but is not planning right now.

Report which build of this connector you are talking to, and whether its tool schemas match the live API. Call this when a tool rejects a field you expect to exist, or accepts one that turns out to have no effect — clients cache tool schemas at connect time, so a connector can advertise an older contract than the API actually has. Takes no arguments and changes nothing.