Travel Tools MCP

What does Travel Tools MCP do?

Travel Tools MCP is a Model Context Protocol server that exposes this account's four travel Actors — Klook All-in-One API, Booking.com All-in-One API, TripAdvisor All-in-One API, and GetYourGuide All-in-One API — as 12 callable tools for AI agents (Claude Desktop, Cursor, or any MCP client). One connection gives an agent hotel search, flight search, car rentals, tours & activities, and restaurant/attraction data across all four platforms.

It's a thin router, not a new data source: every tool call forwards to the matching Actor's own Standby REST API and returns its response, with a couple of tools also cleaning up an otherwise deeply nested raw payload into something a model can use directly (see Data notes).

Why use Travel Tools MCP?

• One MCP connection, four platforms — no existing Apify Store MCP server combines Klook, Booking.com, TripAdvisor, and GetYourGuide into a single toolset
• Always-on — Standby mode means no cold start, tool calls respond in milliseconds
• One flat, tiered fee per tool call, no separate per-Actor billing to track — this server calls the four wrapped Actors internally and absorbs their own compute/proxy cost; you're charged one tool-call/tool-call-proxy event per call (see Pricing)
• Real destination-id resolution, not raw IDs to guess — booking_search_destinations extracts clean {destId, name, subtitle} results from Booking.com's deeply nested raw response, so an agent doesn't need to parse UI-component trees to find a bookable dest_id
• Use cases: travel-planning agents, itinerary builders, price-comparison bots, any AI assistant that needs live multi-platform travel data as a tool

Tools

Tool	Platform	Description
klook_search	Klook	Search tours, activities, tickets, transport, and more
klook_activity_detail	Klook	Full detail for one activity by id
booking_search_destinations	Booking.com	Resolve a free-text place name to a dest_id
booking_search_hotels	Booking.com	Search hotels for a destination and date range
booking_hotel_detail	Booking.com	Full detail for one hotel by id
booking_search_flights	Booking.com	Search round-trip or one-way flights
booking_search_car_rentals	Booking.com	Search car rentals for a place name and date range
tripadvisor_search	TripAdvisor	Resolve a free-text place name to a geo_id
tripadvisor_search_restaurants	TripAdvisor	Search restaurants for a destination
tripadvisor_search_attractions	TripAdvisor	Search things-to-do/attractions for a destination
getyourguide_search	GetYourGuide	Search bookable tours and activities
getyourguide_check_availability	GetYourGuide	Real bookable time slots + live pricing for one date

How to use Travel Tools MCP

1. Get your Apify API token — needed only to authenticate to this Actor's Standby endpoint and attribute your PPE charges, same as any other Apify Standby Actor.
2. Add this server to your MCP client (e.g. Claude Desktop, Cursor) at:

   https://romy--travel-tools-mcp.apify.actor/mcp
   

   with your token passed as a Bearer header:

   Authorization: Bearer <YOUR_APIFY_API_TOKEN>
   

3. Ask the agent something that needs travel data — it picks the right tool(s) itself, e.g. "Find me a 3-star hotel in Bangkok for Sept 24-26 and a rafting activity in Bali for two adults on Sept 15."

You can also call it directly as a raw JSON-RPC request, for testing:

curl -N https://romy--travel-tools-mcp.apify.actor/mcp \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer <YOUR_APIFY_API_TOKEN>" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"getyourguide_search","arguments":{"query":"Bali"}}}'

Parameters

Every tool's input schema is self-describing to an MCP client (name, type, and description per field) — the notes below cover the ones worth knowing up front.

• booking_search_destinations/tripadvisor_search are the required first step before booking_search_hotels/tripadvisor_search_restaurants/tripadvisor_search_attractions — those need a resolved dest_id/geo_id, not a place name.
• booking_search_car_rentals takes a plain place name (location) — it resolves coordinates internally via Booking.com's own location search before calling the car-rental endpoint, so no lat/lng is needed from the caller.
• tripadvisor_search's response is intentionally raw, not extracted — see Data notes.
• Every tool with a currency parameter accepts any ISO 4217 code; each platform's own default (GBP for Klook, USD elsewhere) applies when omitted.

Output

Every tool returns its underlying Actor's JSON response as a single text content block. Real result (trimmed), booking_search_destinations with query: "Bangkok":

{
    "destinations": [
        { "destId": -3414440, "name": "Bangkok", "subtitle": "Thailand" },
        { "destId": 2310, "name": "Downtown Bangkok", "subtitle": "Bangkok, Thailand" },
        { "destId": 21, "name": "Suvarnabhumi Airport", "subtitle": "Bangkok, Thailand" }
    ]
}

getyourguide_check_availability with activity_id: "489945", date: "2026-09-15", adults: 2 (trimmed):

{
    "success": true,
    "options": [
        {
            "optionId": 902997,
            "title": "Rafting Only Adventure with Meeting Point (No ATV)",
            "slots": [{ "startTime": "2026-09-15T09:00:00+0800", "totalPrice": { "price": 41.24, "currency": "USD" } }]
        }
    ]
}

A failed call returns isError: true with the underlying Actor's own error message in the text block — the raw error, not a generic wrapper message, so an agent can see exactly what failed (e.g. a bad id, a missing required field).

Data notes

• Booking.com's destination-search response has no flat dest_id field at all — the raw payload is a deeply nested UI-component tree (Booking's own internal "Saba" framework), with the actual location id buried at <entry>.props.actions[0].props.location.locationId inside core.OnTap nodes. booking_search_destinations walks that tree and returns a clean {destId, name, subtitle} list instead of requiring the agent to parse it — confirmed live against the underlying Actor's own documented example (-3414440 for Bangkok).
• TripAdvisor's search response is left as raw pass-through, deliberately. Its geo_id (found at route.params.geoId) is not co-located with the destination's display name the way Booking.com's is — TripAdvisor uses a normalized, GraphQL-style structure where the name lives in a separately keyed object elsewhere in the same document, connected only by an opaque reference string. Full graph-resolution extraction was judged disproportionate effort for the value gained; the tool's description instead tells the calling model exactly where to find geoId in the raw JSON, which a capable agent can parse directly.
• Booking.com's car-rental search needs resolved coordinates, not a place name — booking_search_car_rentals does the location-resolution step internally (first match wins) so the caller only supplies a plain name.
• A Standby Actor's own server code cannot see or forward the calling client's Apify token — confirmed live: Apify's Standby gateway strips the Authorization header (and any ?token= query param) before a request reaches the container, using it only to gate access to this Actor's own Standby endpoint. Because of this, tool calls go out to the four wrapped Actors using a token this Actor's own owner holds, not the caller's — see Pricing for what that means for cost.

Pricing

Pay-per-event, billed only on a successful call, two tiers depending on which platform a tool talks to:

Event	Tools	Why
tool-call	booking_*, tripadvisor_*	The wrapped Actor calls its upstream directly, no residential proxy
tool-call-proxy	klook_*, getyourguide_*	The wrapped Actor routes through Apify's residential proxy pool to reach its upstream — that cost is absorbed here rather than passed through as a separate charge

Rates are tiered by your Apify plan (Free/Bronze/Silver/Gold/Platinum/Diamond get progressively cheaper rates) — see the Actor's Pricing tab for the exact current rate per tier. This is the only charge for a tool call — the four wrapped Actors' own compute/proxy cost is absorbed on this Actor's own account (see Data notes), not billed separately to you.

Known limitations

• No booking/checkout tools. Every tool wraps a guest-accessible, read-only search/browse/pricing endpoint from its underlying Actor — no login flow, cart, or payment/booking submission.
• Requires an Apify account and token even for a single tool call — there's no anonymous or shared-credential mode; Apify's own Standby gateway enforces this before a request ever reaches this server.
• A tool call fails if the underlying Actor is temporarily unreachable or rate-limited (e.g. residential-proxy IP churn on the wrapped Actor's side) — the raw error surfaces in the tool result rather than being retried automatically.
• This is an unofficial, reverse-engineered integration on top of four independently reverse-engineered Actors, not affiliated with or endorsed by Klook, Booking.com, Tripadvisor, or GetYourGuide. Behavior may change if any of the four platforms change their APIs.

Found a bug or have a feature request? Use the Issues tab on this Actor's page.