Trips MCP Server

Add a stop to a trip the person has KEPT (a link with #k=), on their behalf. Use when they say 'add X to the trip', 'we're stopping at Y on the way', 'put the hotel on it'. Needs their EDIT phrase — a view phrase can read but not write, and the tool says so. Writes exactly one stop and returns the trip's current stop count. Like read_kept_trip this touches the network: the #k= phrase is the password and it goes to thistripbtw.us over TLS, nothing is stored about you, and a wrong phrase counts as a guess. Treat the link as a credential.

Use when someone gives you a KEPT this trip, btw link — one that looks like https://thistripbtw.us/abc1234#k=four-word-phrase — and you need what is actually in it: to summarise where they are going, answer a question about it, or check what changed since you last saw it. Returns the trip's stops in order with dates, modes, which vehicle or person each belongs to (the 'track'), lodging, notes and any hand-drawn path. THIS ONE TOUCHES THE NETWORK, unlike the other two: a kept trip's contents live on the server and the #k= part of the link is the PASSWORD to them, so reading it means sending that phrase to thistripbtw.us over TLS. Nothing is stored and no account is involved. Treat the link as a credential — do not repeat it back in text a third party will see, and do not guess at a phrase, because a wrong one counts against the trip's hourly guess limit. For a DRAFT link (#d=) use read_trip_link instead: the trip is inside that link, so it needs no network and no password.

Update a trip link you already built — add legs, change one leg's fields, replace them all, rename, or drop one — and get the new link back. Use this instead of building a fresh link every time the plan changes, so the person holds one link that grows. To change ONE leg (its lodging, date, note, who is on it) use `update` rather than resending every leg through `legs`. Takes a draft link (#d=) plus the changes; no network, no password, the trip is inside the link. For a KEPT trip (#k=) use add_to_kept_trip.

Start here for any trip, road trip or itinerary. As soon as there is an origin and one destination, build the link and give it to the person; then rebuild it with amend_trip_link every time the plan changes, so one link grows through the conversation. It opens as a private, editable, shareable map at its own address — no account, no card, no app, so you can use it on their behalf where signup-walled travel tools are unreachable. The link is the RECORD: read_trip_link turns it back into structured data in any later conversation. Nothing is sent anywhere — the trip rides in the URL fragment, which browsers never transmit. Coordinates are required for every place and this will not guess them; use find_place to resolve a name first. Keep personal details (passport numbers, home addresses, phone numbers) out of names and notes — URLs get pasted into chats and logs.

Turn a place name into coordinates for build_trip_link — towns, cities, airports (IATA or name), parks, trailheads. Returns up to six candidates with lat/lng and where each one is, so you can pick the right Reno. This is the ONLY step that needs coordinates and you should not guess them from memory. It asks thistripbtw.us, which answers from its own cache and a paced OpenStreetMap lookup; the query is a place name and nothing about the person.

Use when someone gives you a this trip, btw link and you need to know what is actually in it — to summarise the plan, answer a question about it, add a stop, or convert it to something else. Decodes the itinerary the link carries: origin, every leg in order, modes, dates, who is on which leg, flights and lodging. Returns the trip in the same shape build_trip_link accepts, so you can change something and build a new link from it. Nothing is fetched — the trip travels inside the link, so this reads it locally and works offline. Only draft links (the ones with a #d= fragment) carry a trip; a kept trip's link is a slug plus a #k= password whose contents live on the server, and this cannot read those.