The travel helper: flights, hotels, cars and trains from one agent

Travel booking APIs are gated behind B2B accreditation, so a private individual cannot get them. I built a travel helper that searches flights, hotels, cars and trains live, hands me a deep-link to book, and turns the confirmation email into calendar invites. Here is the reproducible pattern and the honest line about what auto-booking still cannot do.

I have a travel helper. I ask it to find flights, hotels, rental cars or trains for a trip, it searches live across several providers, ranks the best options with prices, and hands me a link to book. When I book, I forward the confirmation email and it puts the pick-up and drop-off on my calendar. It has been live since mid-August, and every tool in it is free.

This is the story of how it works, the one rule that makes it honest, and what I learned about why travel booking is the last thing an agent can fully automate.

The real problem

Every travel booking API is gated behind B2B accreditation. Duffel, Amadeus, Skyscanner, Sabre: they all lock paid inventory behind a travel-seller contract, KYC and ticketing authority. A private individual cannot get them. Amadeus shut its self-service developer portal on 17 July 2026, so even the old hobbyist path is gone. Skyscanner’s official API is approved-partner only, with no free tier and no self-serve key. Duffel’s live booking requires business verification and per-order fees.

So the naive version of this project, “wire up a booking API and let the agent buy the flights”, was dead before it started. There is no free, end-to-end flight, hotel or car booking API for a person. That is not a gap I could code around.

What was built

The helper is a search layer, not a booking layer. It sits on top of three free MCP servers, each live-verified before I trusted it:

• trvl is the all-in-one. A single Go binary that merges Google Flights, Kiwi and Skiplagged into one sorted list, plus hotels, cars, trains, ferries and price alerts. No API keys.
• trivago’s official remote MCP does hotel rate comparison across OTAs. It is read-only and free, and it probes clean (HTTP 200 on both the endpoint and its tools list).
• OctoTrip’s rental-cars MCP returns real multi-vendor car results. It returned actual Heathrow results on its first live test.

The pattern is the same for all three: the agent searches live, compares, and presents two or three best options with a booking deep-link. I tap the link, book on the site myself, and tell it the reference.

The architecture

The search tools are MCP servers, so they plug into the agent as ordinary tools. The interesting part is the handoff and the post-purchase flow.

The handoff is a deep-link. For flights, trvl returns a Kiwi or Skiplagged URL that carries the exact itinerary. I tap it, the site opens pre-filled, and I check out. Payment never leaves my hands, and no money is ever automated.

The post-purchase flow is an email bridge. After I book a car or a flight, I forward the confirmation email to a dedicated inbox. The agent reads it there, extracts the booking reference, vendor, times, fuel policy and security deposit, and emails me two calendar invites, one for pick-up and one for drop-off. Outlook ingests the .ics attachment and shows Accept or Decline. This matters because my calendar token is read-only by design. Building the invite as an email attachment means the agent never needs calendar write scope at all.

There is also a flight monitor. When I have a flight coming up, a self-terminating cron polls its status every fifteen minutes and only notifies me on change. The clever bit is the signal it watches: a flight is most often cancelled when the inbound aircraft and crew are stuck out of position, so the monitor checks the inbound aircraft as the real cancellation signal, not just the departure board. When nothing changes it stays silent, and it stops polling once the flight is airborne.

The reproducible pattern

The whole thing reduces to five steps, and every one is load-bearing:

1. Live search for the route and dates.
2. Compare the best options: price, times, provider.
3. Present two or three with a booking deep-link.
4. The user books manually and reports the reference.
5. The agent turns the confirmation into calendar invites.

The rule that anchors it: search is free and live now, booking is a thirty-second tap for the user. I stated that preference myself, and it holds regardless of any tool. The agent never automates payment.

What broke and how it was fixed

The landscape is full of traps, and I hit most of them.

Amadeus is dead, as noted. Skyscanner has no free tier, and the RapidAPI wrappers that claim to offer one are unofficial scrapers that get renamed and delisted. Two of the ones I tested returned “API not found” on the day I checked. The “Flight Finder” MCP that looked promising on paper turned out to be a one-star proof-of-concept that ships mock data, not real prices. Its own README says the real API integration is a future enhancement. I skipped it.

trvl has quirks of its own. It geocodes bare city names wrong: asking for hotels in “Levi” resolved to a village in Estonia, not the Finnish resort. The fix is to always pass “City, Country” and check the destination field in the output. Its flight prices come back in euros even when you ask for pounds, so I convert manually. And its car search is not actually free, it needs a partner-gated Skyscanner key, so I use OctoTrip for cars instead.

OctoTrip taught me the most annoying lesson. Its booking deep-links lose their query parameters. Clicking one redirects to the Discover Cars homepage, not a pre-filled search, so the “one-tap booking link” is aspirational, not literal. I now say so explicitly and hand over the search terms to re-enter.

The honest line

Here is the part I want to be clear about. Search is the value. Booking is a thirty-second tap for the user, and that is not a compromise, it is the correct design.

The agent does the tedious work: it runs the live searches, merges providers, ranks by value, flags the multi-stop trap itineraries that eat vacation days, and catches the split-ticket self-connect warnings that would leave me holding the bag. That is genuinely useful, and it is all free.

What it does not do is buy anything. There is no tool that can, for a private individual, and I would not want one. The human-confirm step at checkout is the safety feature. A basket or itinerary that silently contains the wrong flight, the wrong date, or the wrong vendor is a real cost, and the tap is what catches it before any money moves.

Cost

Everything is free. trvl, trivago and OctoTrip are all free MCP servers with no API keys and no credits. The email bridge uses the same free inbox and email tooling as the rest of my setup. The flight monitor is a cron job on infrastructure I already run. There is no per-search cost, no subscription, no API spend.

What’s next

The obvious next step is price-drop alerts. trvl already supports them, and the flight monitor proves the pattern: watch a route, notify only on change, stay silent otherwise. I want the helper to watch a few routes I care about and tell me when a fare drops below a threshold, without me having to ask.

The useful lesson is not that you can search travel with an agent. It is the boundary. When every booking API is gated behind accreditation you cannot get, the honest architecture is search plus handoff plus a human tap. The agent does the searching, the comparing and the calendar admin. I do the one thing that matters: I look at the price before the money moves.