Search dynamic holiday package options. Supports flight + hotel + transfer + activities in one request. The server runs multiple upstream searches by default (AirlineAPI-style) unless you pass `variants: 1` or provide an explicit `requests` array. Use this tool when user asks for trip packages, vacations, honeymoon/family trips, multi-day stays (e.g. '7 days beach vacation'), or location + activities together (e.g. 'Dubai beaches and activities', 'Goa water sports package', 'Mumbai sightseeing package'). If intent includes vacation/package words or both location + activities, prefer this tool instead of `search_hotel`. Every call should include origin context: `from_origin_latitude`, `from_origin_longitude`, and `from_origin_city` (use client userLocation when available). `from_airport` is optional when origin coordinates are present; server resolves nearest departure IATA automatically. There is no hardcoded default origin airport. Make exactly ONE tool call per user message with every detail you already know. Do NOT call twice (e.g. a probe call then a second call with dates) — ChatGPT shows duplicate package skeleton cards.
**TravelPackageReqObj Details**
* TravelPackageReqObj JSON Schema (all 5 origin fields REQUIRED on every call):
```json
[
{
"location": "DestinationCity",
"from_origin_city": "UserOrExplicitCity",
"from_airport": "ABC",
"from_origin_latitude": 51.8573,
"from_origin_longitude": 3.9439,
"from_country": "XY",
"departure_date": "DD MMM YYYY",
"nights": 4,
"activities": ["beach", "sightseeing"],
"rooms": [
{ "adult_count": 1, "child_count": 0, "child_age": [] }
],
"destinations": [
{ "city_name": "DestinationCity", "checkin_date": "DD MMM YYYY", "checkout_date": "DD MMM YYYY" }
],
"star_rating": "3,4,5",
"is_transfer": false,
"is_activity": true,
"package_title": "Generated Title"
}
]
```
**🚨 ORIGIN POLICY — You resolve airports, not the server.**
On EVERY call you MUST supply all 5 origin fields. The server does NOT resolve city names into airport IATA codes — you must do this before calling the tool, exactly like the flight search tool.
**Step 1 — Decide the source.** Read the USER's prompt:
- If the user explicitly names a departure city or airport ("from Mumbai", "flying out of LHR", "depart from Tokyo", "out of BOM") → **SOURCE A**: derive all 5 origin fields from that city/airport. Ignore `_meta.openai/userLocation`.
- Otherwise (user said nothing about departure) → **SOURCE B**: read `_meta.openai/userLocation` and derive all 5 origin fields from that.
**Step 2 — Fill in all 5 fields (YOU must resolve city → IATA):**
For **SOURCE A** (user-explicit origin, e.g. user said "from Mumbai"):
- `from_origin_city` = the user's named city ("Mumbai")
- `from_airport` = the 3-letter IATA airport code ("BOM") — YOU must resolve this using your own knowledge
- `from_origin_latitude` = the city's decimal degrees latitude (19.0760) if known, otherwise omit
- `from_origin_longitude` = the city's decimal degrees longitude (72.8777) if known, otherwise omit
- `from_country` = the 2-letter ISO country code ("IN") if known, otherwise omit
For **SOURCE B** (no explicit origin → use userLocation):
- `from_origin_city` = `_meta.openai/userLocation.city` verbatim
- `from_origin_latitude` = `_meta.openai/userLocation.latitude` verbatim
- `from_origin_longitude` = `_meta.openai/userLocation.longitude` verbatim
- `from_country` = `_meta.openai/userLocation.country` verbatim
- `from_airport` = the 3-letter IATA code for the nearest major airport to that city — YOU must resolve this using your own knowledge
**Step 3 — NEVER ask the user.** Don't say "Where are you flying from?" or "What's your departure airport?". Always pick a source above and supply the fields.
**Destination resolution:**
- Pass the destination city name in `location` / `destinations[0].city_name`.
- The server resolves the destination city code via the hotel search-form API.
- If the user gives a vacation type without a place (e.g. "beach vacation", "honeymoon package"), infer a suitable destination.
**WORKED EXAMPLE A (explicit origin)** — user prompt: "packages in Tel Aviv from Mumbai":
```json
{
"location": "Tel Aviv",
"from_origin_city": "Mumbai",
"from_airport": "BOM",
"from_origin_latitude": 19.0760,
"from_origin_longitude": 72.8777,
"from_country": "IN",
"departure_date": "20 Jun 2026",
"nights": 4,
"destinations": [{ "city_name": "Tel Aviv", "checkin_date": "20 Jun 2026", "checkout_date": "24 Jun 2026" }],
"rooms": [{ "adult_count": 2, "child_count": 0, "child_age": [] }],
"star_rating": "3,4,5"
}
```
**WORKED EXAMPLE B (implicit origin via userLocation)** — user prompt: "show me packages in Bucharest" with `_meta.openai/userLocation = {city:"Rotterdam", country:"NL", latitude:51.8573, longitude:3.9439}`:
```json
{
"location": "Bucharest",
"from_origin_city": "Rotterdam",
"from_airport": "AMS",
"from_origin_latitude": 51.8573,
"from_origin_longitude": 3.9439,
"from_country": "NL",
"departure_date": "20 Jun 2026",
"nights": 4,
"destinations": [{ "city_name": "Bucharest", "checkin_date": "20 Jun 2026", "checkout_date": "24 Jun 2026" }],
"rooms": [{ "adult_count": 2, "child_count": 0, "child_age": [] }],
"star_rating": "3,4,5"
}
```
**WRONG examples — DO NOT do these:**
- User says "packages in Tel Aviv" (no explicit origin), userLocation = Rotterdam/NL, you send `from_origin_city: "New York", from_airport: "JFK", from_country: "US"` — that ignores userLocation. Wrong.
- User says "packages from Mumbai to Tel Aviv", you send `from_origin_city: "Rotterdam", from_airport: "AMS"` (using userLocation) — that ignores the explicit origin. Wrong.
- You send `from_airport: "Mumbai"` (a city name) instead of `from_airport: "BOM"` (the IATA code) — the server does not resolve city names. Wrong.
- You ask the user "Where are you flying from?" — never. Always pick SOURCE A or SOURCE B above and proceed.
- You omit any of the 5 origin fields — server validation rejects, user sees an error.
**TravelPackageReqObj Generation Guidelines:**
- Generate 3–5 diverse options. Stagger dates per variant.
- Tailor `activities`, `star_rating`, `rooms` to the user's intent.
- Ensure destinations make geographic sense given the origin.
**When calling MCP tool `search_dynamic_package`:**
- Make ONE call per user message (never a probe call plus a second call — duplicate skeleton widgets).
- Set `location` to the destination city name.
- Set `nights` to 4 for typical 5-day trips (server default).
- Set all 5 origin fields (from SOURCE A or SOURCE B above).
- Do NOT set `flight_search_type` unless the user explicitly asks for a trip type.
**Multi-option:** send `variants: 3` (with optional `variant_step_days`) OR send `requests: [...]` array of 3–5 full objects.