Trip.com

Open the flight search usage guide for finding flights, comparing airfares, and choosing the right flight tool. Returns the complete usage guide for these Trip.com-backed flight MCP tools: tool list, mandatory call order, parameter rules, and worked examples for common scenarios. Call this tool first if you are unsure which tool to use or how to construct a request.

Render a Trip.com card list from one to five unmodified structuredContent results returned by search_activities or search_attractions. selectedItems is required and is the only source of the final card selection and order. Select exactly ten unique products when at least ten are available across searchResults; otherwise select every available unique product, including an empty array when none are available. When linking a returned product, copy its tripUrl exactly, including every query parameter. Do not shorten, reconstruct, remove, or change URL parameters. Use URLs from the final render_activities_list result for the final response.

Use this when the user wants Trip.com non-attraction experiences or broad things-to-do recommendations for a specific destination. Typical trigger words include things to do, what to do, tours, experiences, day trips, private guides, food tours, cooking classes, transport, transfers, cruises, wellness, water sports, passes, visa services, SIM cards, and eSIMs; supported examples include "things to do in Tokyo", "best food tours in Paris", "day trips from Bangkok", "Bali cooking class", "Singapore city pass", "Bangkok airport transfer", "Vietnam visa service", and "Japan eSIM for 7 days". PRODUCT BOUNDARY: This tool supports experiences, tours, transfers, and services involving or near a place, such as a Disney private guide tour, Louvre guided walking tour, Seine River dinner cruise, or Universal Studios transfer. It does not support attraction or POI recommendations, admission, entry, or tickets to a place; use search_attractions for those, such as Disney tickets, Louvre entry, Eiffel Tower admission, or Universal Studios entry. destination is required and accepts a city, region, or country. If it cannot be inferred, ask the user before calling. query is required: derive a concise localized activity-product keyword from the user's intent, and do not include the destination because the server adds it to the Trip.com list-page keyword. Optional dateRange supports startDate and endDate in YYYY-MM-DD format. category should be set only when the user clearly requests one schema-supported category and omitted for mixed-category results. Optional sortBy supports default, price_asc, price_desc, rating, or sales. Optional filters support minPrice, maxPrice, and today/tomorrow availability. Optional limit is 1 to 20 and defaults to 10. Unless the user explicitly requests fewer than ten results, request at least ten candidates. locale is also optional, and currency is derived from the resolved Trip.com site. Results may include the activity title, image, rating, review or booking counts, badges, price, and a Trip.com link. This is a data-only search tool and does not render UI. After all Activities and Attractions searches for the current user request are complete, call render_activities_list exactly once with the final unmodified structuredContent results. Before that render call, pass exactly ten unique selectedItems in the intended presentation order when at least ten unique candidates are available; otherwise select every available unique candidate, including an empty array when none are available. In the final user-facing response, provide exactly one numbered recommendation for every rendered card, using the same title and order as the cards; do not omit a rendered card, duplicate a recommendation, or mention any attraction or activity that is not rendered. Rating filters, free-cancellation filters, instant-confirmation filters, and booking actions are not supported. If results are empty, broaden the activity keyword or verify the destination; do not silently switch to search_attractions. When linking a returned product, copy its tripUrl exactly, including every query parameter. Do not shorten, reconstruct, remove, or change URL parameters. Use URLs from the final render_activities_list result for the final response.

Use this when the user wants Trip.com attractions, points of interest (POIs), or admission and ticket information for a specific destination. Typical trigger words include attractions, POIs, museums, landmarks, theme parks, observation decks, admission, entry, and tickets; supported examples include "top attractions in Tokyo", "best museums in Paris", "Disneyland tickets", "what to see in Rome", and "theme parks near Bangkok". PRODUCT BOUNDARY: This tool supports admission, entry, or tickets to a place, such as Disney tickets, Louvre entry, Eiffel Tower admission, or Universal Studios entry. It does not support broad "things to do" requests or experiences, tours, day trips, private guides, transfers, transport, cruises, food experiences, cooking classes, wellness, water activities, passes, SIM/eSIM products, or travel and visa services; use search_activities for those, such as a Disney private guide tour, Louvre guided walking tour, Seine River dinner cruise, or Universal Studios transfer. destination is required and accepts a city or region. If it cannot be inferred, ask the user before calling. query is required: derive a concise localized attraction or ticket keyword from the user's intent, and do not include the destination because the server adds it to the Trip.com list-page keyword. Optional sortBy supports popularity, rating, or bookings. Optional filters support today/tomorrow availability and the attractionTypes defined by the schema. Select this tool from the requested product intent before applying those filters; never route from an attractionTypes name alone. sightseeing_tours and boating_sailing are attraction-list classifications, not standalone tour or water-activity products. Optional limit is 1 to 20 and defaults to 10. Unless the user explicitly requests fewer than ten results, request at least ten candidates. locale is also optional. Results may include the attraction name, image, rating, review or booking counts, badges, price, open-status details, and a Trip.com link. This is a data-only search tool and does not render UI. After all Activities and Attractions searches for the current user request are complete, call render_activities_list exactly once with the final unmodified structuredContent results. Before that render call, pass exactly ten unique selectedItems in the intended presentation order when at least ten unique candidates are available; otherwise select every available unique candidate, including an empty array when none are available. In the final user-facing response, provide exactly one numbered recommendation for every rendered card, using the same title and order as the cards; do not omit a rendered card, duplicate a recommendation, or mention any attraction or activity that is not rendered. If results are empty, verify or broaden the attraction keyword and destination. Do not switch to search_activities unless the user actually wants a non-attraction product. When linking a returned product, copy its tripUrl exactly, including every query parameter. Do not shorten, reconstruct, remove, or change URL parameters. Use URLs from the final render_activities_list result for the final response.

Use this when the user wants real-time flight options for fixed-date travel, including "cheapest flight on this date" requests. This tool searches Trip.com inventory. Relative dates such as tomorrow or next Thursday count as fixed-date travel after resolving them to YYYYMMDD. Supports one-way and round-trip itineraries only. For multi-way requests, offer to search each leg as a separate one-way trip. Each segment is one real flight leg in itinerary order, not one origin-destination pair generated from alternatives. oneWay uses exactly 1 segment. roundTrip uses exactly 2 segments using the same locations in reverse directions. Connection cities explicitly requested by the user are filters within the requested origin-to-destination journey, never additional segments. For example, "Shanghai to London via Tokyo" uses one Shanghai-to-London segment with filters.transferCities=["Tokyo"]; never split it into Shanghai-to-Tokyo and Tokyo-to-London segments. For multiple possible departure or arrival places on the same leg/date, keep them in the same segment by passing multiple departLocations and/or arriveLocations. Do not create extra segments for location alternatives. For example, "Shanghai or Beijing to Tokyo on 2026-04-15" is one segment with two departLocations and one arriveLocation; "Shanghai to Tokyo or Osaka" is one segment with one departLocation and two arriveLocations. Preserve the exact location granularity the user requested: if the user says a country/region such as Japan or Australia, pass that country/region name directly. Do not replace or expand a country/region with representative or inferred cities such as Tokyo, Osaka, or Sydney unless the user explicitly chose those cities. Do not use this for flexible, approximate, or range-based date searches; use search_low_price_flights_v2 for flexible dates whether or not the user says "cheap". Each segment needs departLocations, arriveLocations, and departDate in YYYYMMDD. Departure and arrival locations may be human-readable city, country/region, or airport names; the server resolves flight location codes internally. Optional filters include airline codes, cabin class, baggage allowance, student fares, and explicitly requested connection cities.

Search hotels via the hulk searchHotels SOA endpoint. Call this tool only when the user wants to search hotels by `poiName` / landmark, `cityName`. REQUIRED: at least one of `poiName` or `cityName` MUST be provided. If the user has not given any of these, ASK A FOLLOW-UP QUESTION FIRST to obtain at least one — do NOT call this tool with all both empty. UNSUPPORTED CONSTRAINTS (hard block): star level, rating, price, guest/room counts, amenities, sorting, comparisons, cancellation policies, availability, booking, or any other non-date filter, suitability, or recommendation condition beyond POI or city. STRICT RULE: If the user request contains ANY unsupported constraint above, you MUST NOT call this tool — even if the user also provides a valid poiName / cityName. Respond ONLY that the current hotel tool supports searching by POI or city, and cannot apply the requested constraint. Do not provide workarounds, UI navigation, filter suggestions, search terms, or recommendations. DO NOT silently drop the unsupported constraint to call the tool anyway. Example refusals: user says "5-star hotels near Oriental Pearl Tower" → refuse (contains star filter); user says "hotels under $200 in Tokyo" → refuse (contains price filter); user says "Hilton Tokyo" or "Hilton hotels in Shanghai" → refuse (hotel-name / brand search is not supported, ask the user to provide a POI or city instead); REQUIRED: `locale` in IETF BCP-47 format (e.g. "en-US", "ja-JP", "zh-HK"). Infer it from the user site / preferred language. Returns hotels[] with metadata such as hid, name, city, cityName, distance, and optionally star/score. Returned star/score metadata MUST NOT be treated as supported filtering capability.

[DEPRECATED: this v1 low-price flight tool will be removed after the OpenAI app migration window. Prefer search_low_price_flights_v2 for all new calls.] Legacy low-price flight search for published v1 OpenAI metadata snapshots. Results come from Trip.com inventory. Use only when this is the only available low-price flight tool. Input uses origin.cityName and destination.cityName on each segment. Find cheap flights and compare airfares across flexible, approximate, or range-based travel dates.

Use this when the user wants low-price flight options for flexible-date itineraries. This tool searches Trip.com inventory and returns fare options users can compare and continue to book. The travel date should be flexible, approximate, or a date range such as "next month", "Golden Week", or "any cheap day in June". Do not use this for a specific departure day; use search_flights even when the user asks for the cheapest flight on an exact date. If the user gives no date or date range, ask for an exact departure date or a flexible date window before calling. If the user mixes exact-date and flexible-date alternatives, ask whether to run exact search, flexible-date search, or both separately. For ambiguous named holidays such as Golden Week, ask which market, year, or holiday window the user means before calling. Supports one-way and round-trip searches only. For multi-way requests, offer to search each leg as a separate one-way trip. Each segment needs one origin.name, one destination.name, and departureTimeRange in YYYY-MM-DD. Only accepts tripType, rawQuery, locale, and segments; filters such as cabin class, airline, direct/nonstop flights, baggage, student fares, or transfer cities are not supported. Still use this for flexible-date queries with unsupported filters, but omit those filters and explain the limitation. For one-way, the departureTimeRange span must be within one month; for round-trip, the overall span from the earliest outbound departure to the latest return departure must be within one month. For wider flexible windows, stay in the flexible-date path and ask the user to narrow the window or split it into multiple search_low_price_flights_v2 searches.

Search train routes between two stations or cities. Returns departure/arrival times, prices when available, journey duration, transfer information, and route options. Supports sorting by price or duration, and filtering by transfer count (direct only = 0, max 1 transfer = 1, or unlimited = -1) and earliest departure time of day (HH:mm:ss). Date defaults to tomorrow if omitted.