Travel Agent Skills

Give your agent live flight and hotel prices — every fare carrying Google's own low | typical | high verdict and a bookable link — so it can tell someone whether a price is worth taking, not just what the price is.

Free, no API key, no signup:

claude mcp add --transport http flightpowers https://google-flights-lulu.flightpowers.com/mcp

That puts four tools in your agent — one-way flights, round-trip flights, hotel search, and one named hotel — and you can ask it a real question straight away. The free server is ad-supported: each response carries one disclosed sponsored card. Ad-free servers below.

What comes back

Ask a flexible question and it is one call, not one per date:

Cheapest way from Berlin to Paris in the middle of September?

$49   Wed Sep 16   easyJet · non-stop · 1 hr 50 min · 6:05 AM → 7:55 AM    low
$49   Thu Sep 17   easyJet · non-stop · 1 hr 50 min · 6:00 AM → 7:50 AM    low
$53   Tue Sep 15   easyJet · non-stop · 1 hr 50 min · 6:15 AM → 8:05 AM    typical

Google's historical band for this route and period: $50–$125
Dates searched: Sep 14, 15, 16, 17, 18  ·  one call, five dates
Every row carries a buy_link into Google Flights for that exact itinerary.

That is an actual response from the free server, captured 2026-08-25 (BER → CDG, departure_date_from / departure_date_to spanning five days). It is one real search, not a benchmark — fares move constantly, and yours will differ.

The low / typical column is the part most flight APIs do not have. It comes from price_range_in_relation_to_other_periods, alongside price_insights_low and price_insights_high — Google's own price band for that route and period. It is the difference between an agent that says "$49" and one that says "$49 is low for this route — book it, don't wait".

The tools your agent gets

Written for the model that has to choose between them. The parameter names below are the real ones from the tool schemas.

search_oneway_flights

Reach for this for any single-direction fare question, including open-ended ones. The destination may be a list of IATA codes and the dates may be a range (departure_date_from / departure_date_to) — the server expands both internally. "Cheapest flight to Sri Lanka anywhere in October" is one call, not thirty. Do not loop this tool over dates.

Not this one when the traveller comes back — search_roundtrip_flights prices the pair together, which is not the same number as two one-ways added up.

You get back one row per itinerary: price / price_as_number, airline, duration / duration_seconds, stops and stops_info[] (each layover airport and its duration), departure_description / arrival_description, a buy_link deep-linking that exact itinerary, and the three price-insight fields. Alongside them, search_coverage names every date actually searched.

Read search_coverage before you conclude anything. On the free server a call searches at most 15 date × destination combinations; a wider request is not rejected, it is sampled evenly across the range and comes back with truncated: true. A date missing from departure_dates_searched was never searched — which is not the same as having no flights.

search_roundtrip_flights

Reach for this whenever the trip returns, and especially when the user knows the trip length but not the dates: pass nights (a number, or a list like [5,6,7]) instead of return_date, with departure_date_from / departure_date_to for the outbound window. "5 to 7 nights in Rome sometime in May" is one call.

You get back total_price / total_price_as_number for both legs together, total_duration_seconds, total_stops, the outbound and return legs already paired — departure_flight_airline, return_flight_airline, per-leg stops, durations and times — and a single buy_link covering the whole trip. Same free-tier cap and same search_coverage, counted over departure-date × nights combinations.

search_hotels

Reach for this when the user wants options in a place. destination is free text the way a person says it — "Rome", "Tokyo Shibuya" — not an ID and not a coordinate, plus checkin_date and checkout_date. budget_per_night filters before you get the list.

Not this one when they have already named the property; that is find_hotel_by_name.

You get back per property: name, price_string and price, review_score and review_count, room_type, location, and a booking link.

find_hotel_by_name

Reach for this when the user names one property — "is the Hilton Paris Opera free that week" — or when you are tracking a single hotel's price over time. hotel_name is the name a person would type; adding the city helps when a chain has many properties. No internal property ID is needed; the resolution is done for you.

You get back that property's price, review_score, room_type and booking link. A property with no availability for those dates comes back as unavailable — that is an answer, not an error, and re-calling will not change it.

All four: rates and fares go stale within minutes. Never reuse a result from earlier in the conversation; search again and stamp the answer with when it was fetched.

The eight skills

The tools give your agent the data. The skills are what make it use the data well — one call for a whole date range instead of thirty, the verdict instead of a bare number, and a fresh fetch every time.

One hub holds auth, hosts, every endpoint, every response field name and the billing rules. Seven workflow skills stay thin and delegate to it.

travel-data-api                 hub — auth, hosts, endpoints, response fields, cost per call
  |- cheapest-dates             WHEN to fly: scan a date range, judge the winner
  |- destination-compare        WHERE to go: price many cities from one origin
  |- trip-planner               flights + hotel totalled into one all-in budget
  |- fare-watch                 one pinned route, re-checked over time, book-now-or-wait
  |- hotel-search               find and price places to stay
  |- rate-parity-monitor        same hotel priced as a resident of each country
  `- travel-brief               presentation layer — recommendation, table, links

Skills are named by the job, not by the endpoint. Two flight endpoints and two hotel endpoints produce seven workflows, because "which day is cheapest" and "where should I go" are different questions to a user and identical questions to an API.

Other prompts these are built for:

Where can I go from JFK for under $400 in late October? Somewhere warm.
Watch BER→LHR for the 14th and ping me if it drops below $90.
Plan a week in Rome in May for two, £1800 all in, hotel needs free cancellation.
Is the Hilton Paris Opera cheaper booked from Germany than from the US, same dates?
Write up the Lisbon options for my client with a table and booking links.

Install the skills

Claude Code (plugin)

claude plugin marketplace add mtnrabi/travel-agent-skills
claude plugin install travel-agent-skills@travel-agent-skills

Restart Claude Code and all eight load together — the agent picks the right one from the question, and you can also invoke one directly by name (cheapest-dates, trip-planner, rate-parity-monitor).

Any agent with a plain skills directory

git clone https://github.com/mtnrabi/travel-agent-skills.git

# personal, every project:
cp -r travel-agent-skills/skills/* ~/.claude/skills/

# or scoped to one project:
mkdir -p .claude/skills && cp -r travel-agent-skills/skills/* .claude/skills/

Read the full README on GitHub →