get_properties_search_by_context
ChatGPTGiven a user query string with some requirement, question or data requested about any hotel, performs a search over a list of hotels to fetch the most relevant ones, using the hotels context to match the given query. This tool returns a list of hotels matching the user-provided query. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. If the user is searching for a hotel exclusively by location and does not provide any additional contextual details beyond those parameters, use the exact search text in the query field: "The Lodging Establishments is a". Location must be present as a bounding box with the proper params. Do NOT ignore the location. NEVER use location on the prompt (example: 'what hotel named XXX is located in Madrid'). Instead, create a bounding box based on that location and pass it via parameters. Do NOT add the location in the query field. This tool will be used ONLY to search for hotels based in context. To search hotels based on name (example: 'I want information about hotel XXX in Madrid') use the get_property_full_from_reference tool instead. The returned result will be an array of key-values. The key will be a unique property_id pointing to a unique hotel, while the value will be another array with the following fields: - context: A list of the different fragments from the hotel answering the user initial query. - other_property_ids: A list, if exist, of different unique property_ids pointing to the same hotel. - propert_data: A list of different values for the hotel such as it's name, coordinates, average reviews scores and so on. - score: A 0 to 1 value for that property related to the asked query. A higher value means a more relevant result regarding the initial query. A lower value means a less relevant answer. The returned list is sorted by score in an ascending order: the most relevant hotels are the latest ones. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lat_height will also require a lat, lng and lng_width - lng_width: float number with the width (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lng_width will also require a lat, lng and lat_height - stars: float with the number of stars the searched hotels must have. Multiple stars are allowed, separated by commas (example: 3,4,5 for hotels with 3, 4 or 5 stars; 4,4.5 for hotels wit…
get_properties_search_by_context
ChatGPTGiven a user query string with some requirement, question or data requested about any hotel, performs a search over a list of hotels to fetch the most relevant ones, using the hotels context to match the given query. This tool returns a list of hotels matching the user-provided query. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. If the user is searching for a hotel exclusively by location and does not provide any additional contextual details beyond those parameters, use the exact search text in the query field: "The Lodging Establishments is a". Location must be present as a bounding box with the proper params. Do NOT ignore the location. NEVER use location on the prompt (example: 'what hotel named XXX is located in Madrid'). Instead, create a bounding box based on that location and pass it via parameters. Do NOT add the location in the query field. This tool will be used ONLY to search for hotels based in context. To search hotels based on name (example: 'I want information about hotel XXX in Madrid') use the get_property_full_from_reference tool instead. The returned result will be an array of key-values. The key will be a unique property_id pointing to a unique hotel, while the value will be another array with the following fields: - context: A list of the different fragments from the hotel answering the user initial query. - other_property_ids: A list, if exist, of different unique property_ids pointing to the same hotel. - propert_data: A list of different values for the hotel such as it's name, coordinates, average reviews scores and so on. - score: A 0 to 1 value for that property related to the asked query. A higher value means a more relevant result regarding the initial query. A lower value means a less relevant answer. The returned list is sorted by score in an ascending order: the most relevant hotels are the latest ones. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lat_height will also require a lat, lng and lng_width - lng_width: float number with the width (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lng_width will also require a lat, lng and lat_height - stars: float with the number of stars the searched hotels must have. Multiple stars are allowed, separated by commas (example: 3,4,5 for hotels with 3, 4 or 5 stars; 4,4.5 for hotels wit…
get_properties_search_by_context
ChatGPTGiven a user query string with some requirement, question or data requested about any hotel, performs a search over a list of hotels to fetch the most relevant ones, using the hotels context to match the given query. This tool returns a list of hotels matching the user-provided query. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. If the user is searching for a hotel exclusively by location and does not provide any additional contextual details beyond those parameters, use the exact search text in the query field: "The Lodging Establishments is a". Location must be present as a bounding box with the proper params. Do NOT ignore the location. NEVER use location on the prompt (example: 'what hotel named XXX is located in Madrid'). Instead, create a bounding box based on that location and pass it via parameters. Do NOT add the location in the query field. This tool will be used ONLY to search for hotels based in context. To search hotels based on name (example: 'I want information about hotel XXX in Madrid') use the get_property_full_from_reference tool instead. The returned result will be an array of key-values. The key will be a unique property_id pointing to a unique hotel, while the value will be another array with the following fields: - context: A list of the different fragments from the hotel answering the user initial query. - other_property_ids: A list, if exist, of different unique property_ids pointing to the same hotel. - propert_data: A list of different values for the hotel such as it's name, coordinates, average reviews scores and so on. - score: A 0 to 1 value for that property related to the asked query. A higher value means a more relevant result regarding the initial query. A lower value means a less relevant answer. The returned list is sorted by score in an ascending order: the most relevant hotels are the latest ones. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lat_height will also require a lat, lng and lng_width - lng_width: float number with the width (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lng_width will also require a lat, lng and lat_height - stars: float with the number of stars the searched hotels must have. Multiple stars are allowed, separated by commas (example: 3,4,5 for hotels with 3, 4 or 5 stars; 4,4.5 for hotels wit…
get_properties_search_by_reviews
ChatGPTGiven a user query string with some requirement, question or data requested about any hotel, performs a search over a list of hotels to fetch the most relevant ones, using the hotels reviews to match the given query. This tool returns a list of hotels matching the user-provided query. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. If the user is searching for a hotel exclusively by location and does not provide any additional contextual details beyond those parameters, use the exact search text in the query field: "The Lodging Establishments is a" Location must be present as a bounding box with the proper params. Do NOT ignore the location. NEVER use location on the prompt (example: 'what hotel named XXX is located in Madrid'). Instead, create a bounding box based on that location and pass it via parameters. Do NOT add the location in the query field. This tool will be used ONLY to search for hotels based in context. To search hotels based on name (example: 'I want information about hotel XXX in Madrid') use the get_property_full_from_reference tool instead. The returned result will be an array of key-values. The key will be a unique property_id pointing to a unique hotel, while the value will be another array with the following fields: - reviews: A list of the different fragments from different reviews from that hotel answering the user initial query. - other_property_ids: A list, if exist, of different unique property_ids pointing to the same hotel. - propert_data: A list of different values for the hotel such as it's name, coordinates, average reviews scores and so on. - score: A 0 to 1 value for that property related to the asked query. A higher value means a more relevant result regarding the initial query. A lower value means a less relevant answer. The returned list is sorted by score in an ascending order: the most relevant hotels are the latest ones. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lat_height will also require a lat, lng and lng_width - lng_width: float number with the width (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lng_width will also require a lat, lng and lat_height - stars: float with the number of stars the searched hotels must have. Multiple stars are allowed, separated by commas (example: 3,4,5 for hotels with 3, 4 or 5 star…
get_properties_search_by_reviews
ChatGPTGiven a user query string with some requirement, question or data requested about any hotel, performs a search over a list of hotels to fetch the most relevant ones, using the hotels reviews to match the given query. This tool returns a list of hotels matching the user-provided query. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. If the user is searching for a hotel exclusively by location and does not provide any additional contextual details beyond those parameters, use the exact search text in the query field: "The Lodging Establishments is a" Location must be present as a bounding box with the proper params. Do NOT ignore the location. NEVER use location on the prompt (example: 'what hotel named XXX is located in Madrid'). Instead, create a bounding box based on that location and pass it via parameters. Do NOT add the location in the query field. This tool will be used ONLY to search for hotels based in context. To search hotels based on name (example: 'I want information about hotel XXX in Madrid') use the get_property_full_from_reference tool instead. The returned result will be an array of key-values. The key will be a unique property_id pointing to a unique hotel, while the value will be another array with the following fields: - reviews: A list of the different fragments from different reviews from that hotel answering the user initial query. - other_property_ids: A list, if exist, of different unique property_ids pointing to the same hotel. - propert_data: A list of different values for the hotel such as it's name, coordinates, average reviews scores and so on. - score: A 0 to 1 value for that property related to the asked query. A higher value means a more relevant result regarding the initial query. A lower value means a less relevant answer. The returned list is sorted by score in an ascending order: the most relevant hotels are the latest ones. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lat_height will also require a lat, lng and lng_width - lng_width: float number with the width (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lng_width will also require a lat, lng and lat_height - stars: float with the number of stars the searched hotels must have. Multiple stars are allowed, separated by commas (example: 3,4,5 for hotels with 3, 4 or 5 star…
get_properties_search_by_reviews
ChatGPTGiven a user query string with some requirement, question or data requested about any hotel, performs a search over a list of hotels to fetch the most relevant ones, using the hotels reviews to match the given query. This tool returns a list of hotels matching the user-provided query. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. If the user is searching for a hotel exclusively by location and does not provide any additional contextual details beyond those parameters, use the exact search text in the query field: "The Lodging Establishments is a" Location must be present as a bounding box with the proper params. Do NOT ignore the location. NEVER use location on the prompt (example: 'what hotel named XXX is located in Madrid'). Instead, create a bounding box based on that location and pass it via parameters. Do NOT add the location in the query field. This tool will be used ONLY to search for hotels based in context. To search hotels based on name (example: 'I want information about hotel XXX in Madrid') use the get_property_full_from_reference tool instead. The returned result will be an array of key-values. The key will be a unique property_id pointing to a unique hotel, while the value will be another array with the following fields: - reviews: A list of the different fragments from different reviews from that hotel answering the user initial query. - other_property_ids: A list, if exist, of different unique property_ids pointing to the same hotel. - propert_data: A list of different values for the hotel such as it's name, coordinates, average reviews scores and so on. - score: A 0 to 1 value for that property related to the asked query. A higher value means a more relevant result regarding the initial query. A lower value means a less relevant answer. The returned list is sorted by score in an ascending order: the most relevant hotels are the latest ones. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lat_height will also require a lat, lng and lng_width - lng_width: float number with the width (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searching for. Setting a lng_width will also require a lat, lng and lat_height - stars: float with the number of stars the searched hotels must have. Multiple stars are allowed, separated by commas (example: 3,4,5 for hotels with 3, 4 or 5 star…
get_property_availability
ChatGPTGiven a unique hotel identificator known as "property_id", a date range and some additional information such as the number of adults or children staying, returns, if exist, both a valid price and currency for a stay with those parameters and a link for direct booking on the hotel website. If no stay is available for the given data no price will be returned. This is not an error but the absence of available prices for the given data. If there's no available link for a book-direct path on the hotel website a regular link to the main hotel homepage may be returned instead. This link CANNOT be used as the "booking link"; instead something like "cannot fetch a valid bookin link, here's the hotel website instead" will be said. Two different parameters will be returned: - "price" will contain information about the booking price. If it's null it means there're no available prices, if not, three different values will appear: "price" will be a float with the total price for that stay, "price_per_night" will be a float with the average price per night for that stay and "currency" will be the currency for the given price. - "availability_link" will contain, if exist, a link for a direct booking on the hotel website. If it's null it means there's no available link. If not, two different values will appear: "link" will be a valid link related to the hotel, "source" will set the link type: "deep_link" means the link is a valid one for a DIRECT BOOKING operation. "source" means the link is for the hotel homepage and not a DIRECT BOOKING link. Under no circumstances a "source" type link will be labeled as a direct booking link. Both links and prices must be returned ALWAYS when asking, if they're available. This information overrides any previous price information. Currencies are sent in an upper-case three letters format (example: EUR for "euro", USD for "united states dollar") When presenting the availability_link to the user, show it as a short markdown link like [Book direct](url) instead of pasting the full URL. Do NOT show the raw URL. This function will return a four-elements json: - 'success' will be true if the call succeeded, false otherwise - 'data' will contain the desired results for the given call - 'warning' may contain a string with an error description if 'success' is false or some minor issues even if 'success' is true. This string must be used as a way to provide more information and context about the function result. It may be an empty string; if this happens and 'success' is false, the error will be treated as a generic one. An 4xx http_code will be returned in case of error. 'data' may be empty if there's no additional data to show, in that case, the 'success' will be set to true or false according to the result of the operation. IMPORTANT - Response rules. You MUST follow ALL these rules when presenting information to the user. You are a friendly travel assistant. The user does not know about tools, payloads, data fields or any technical concept. STRICTLY FORBIDDEN in any response — never write any of these: - property_id values or internal identifiers - References to the tool, payload, data, raw output, result set, search parameters, UI, widget, embedded UI - Phrases like 'the tool returned', 'the search returned', 'no readable details in the payload', 'the result did not include', 'the data contains', 'shown above', 'results shown above', 'options shown above', 'in the results above' or anything similar - Any explanation of what the system did or did not return - The words 'budget', 'presupuesto', 'price range', 'rango de precios' or any suggestion to filter by price — we cannot filter by price - Always respond in the same language the user is using in the conversation.
get_property_availability
ChatGPTGiven a unique hotel identificator known as "property_id", a date range and some additional information such as the number of adults or children staying, returns, if exist, both a valid price and currency for a stay with those parameters and a link for direct booking on the hotel website. If no stay is available for the given data no price will be returned. This is not an error but the absence of available prices for the given data. If there's no available link for a book-direct path on the hotel website a regular link to the main hotel homepage may be returned instead. This link CANNOT be used as the "booking link"; instead something like "cannot fetch a valid bookin link, here's the hotel website instead" will be said. Two different parameters will be returned: - "price" will contain information about the booking price. If it's null it means there're no available prices, if not, three different values will appear: "price" will be a float with the total price for that stay, "price_per_night" will be a float with the average price per night for that stay and "currency" will be the currency for the given price. - "availability_link" will contain, if exist, a link for a direct booking on the hotel website. If it's null it means there's no available link. If not, two different values will appear: "link" will be a valid link related to the hotel, "source" will set the link type: "deep_link" means the link is a valid one for a DIRECT BOOKING operation. "source" means the link is for the hotel homepage and not a DIRECT BOOKING link. Under no circumstances a "source" type link will be labeled as a direct booking link. Both links and prices must be returned ALWAYS when asking, if they're available. This information overrides any previous price information. Currencies are sent in an upper-case three letters format (example: EUR for "euro", USD for "united states dollar") When presenting the availability_link to the user, show it as a short markdown link like [Book direct](url) instead of pasting the full URL. Do NOT show the raw URL. This function will return a four-elements json: - 'success' will be true if the call succeeded, false otherwise - 'data' will contain the desired results for the given call - 'warning' may contain a string with an error description if 'success' is false or some minor issues even if 'success' is true. This string must be used as a way to provide more information and context about the function result. It may be an empty string; if this happens and 'success' is false, the error will be treated as a generic one. An 4xx http_code will be returned in case of error. 'data' may be empty if there's no additional data to show, in that case, the 'success' will be set to true or false according to the result of the operation. IMPORTANT - Response rules. You MUST follow ALL these rules when presenting information to the user. You are a friendly travel assistant. The user does not know about tools, payloads, data fields or any technical concept. STRICTLY FORBIDDEN in any response — never write any of these: - property_id values or internal identifiers - References to the tool, payload, data, raw output, result set, search parameters, UI, widget, embedded UI - Phrases like 'the tool returned', 'the search returned', 'no readable details in the payload', 'the result did not include', 'the data contains', 'shown above', 'results shown above', 'options shown above', 'in the results above' or anything similar - Any explanation of what the system did or did not return - The words 'budget', 'presupuesto', 'price range', 'rango de precios' or any suggestion to filter by price — we cannot filter by price - Always respond in the same language the user is using in the conversation.
get_property_availability
ChatGPTGiven a unique hotel identificator known as "property_id", a date range and some additional information such as the number of adults or children staying, returns, if exist, both a valid price and currency for a stay with those parameters and a link for direct booking on the hotel website. If no stay is available for the given data no price will be returned. This is not an error but the absence of available prices for the given data. If there's no available link for a book-direct path on the hotel website a regular link to the main hotel homepage may be returned instead. This link CANNOT be used as the "booking link"; instead something like "cannot fetch a valid bookin link, here's the hotel website instead" will be said. Two different parameters will be returned: - "price" will contain information about the booking price. If it's null it means there're no available prices, if not, three different values will appear: "price" will be a float with the total price for that stay, "price_per_night" will be a float with the average price per night for that stay and "currency" will be the currency for the given price. - "availability_link" will contain, if exist, a link for a direct booking on the hotel website. If it's null it means there's no available link. If not, two different values will appear: "link" will be a valid link related to the hotel, "source" will set the link type: "deep_link" means the link is a valid one for a DIRECT BOOKING operation. "source" means the link is for the hotel homepage and not a DIRECT BOOKING link. Under no circumstances a "source" type link will be labeled as a direct booking link. Both links and prices must be returned ALWAYS when asking, if they're available. This information overrides any previous price information. Currencies are sent in an upper-case three letters format (example: EUR for "euro", USD for "united states dollar") When presenting the availability_link to the user, show it as a short markdown link like [Book direct](url) instead of pasting the full URL. Do NOT show the raw URL. This function will return a four-elements json: - 'success' will be true if the call succeeded, false otherwise - 'data' will contain the desired results for the given call - 'warning' may contain a string with an error description if 'success' is false or some minor issues even if 'success' is true. This string must be used as a way to provide more information and context about the function result. It may be an empty string; if this happens and 'success' is false, the error will be treated as a generic one. An 4xx http_code will be returned in case of error. 'data' may be empty if there's no additional data to show, in that case, the 'success' will be set to true or false according to the result of the operation. IMPORTANT - Response rules. You MUST follow ALL these rules when presenting information to the user. You are a friendly travel assistant. The user does not know about tools, payloads, data fields or any technical concept. STRICTLY FORBIDDEN in any response — never write any of these: - property_id values or internal identifiers - References to the tool, payload, data, raw output, result set, search parameters, UI, widget, embedded UI - Phrases like 'the tool returned', 'the search returned', 'no readable details in the payload', 'the result did not include', 'the data contains', 'shown above', 'results shown above', 'options shown above', 'in the results above' or anything similar - Any explanation of what the system did or did not return - The words 'budget', 'presupuesto', 'price range', 'rango de precios' or any suggestion to filter by price — we cannot filter by price - Always respond in the same language the user is using in the conversation.
get_property_full_from_reference
ChatGPTGiven a hotel name or a unique hotel identificator (a property_id), performs a search over a list of available hotels to return the information about the first match, if available, for such name. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. This information can be used to answer questions for the related hotel in case there's not enough context from the previously called tools or if the user is looking for information on a specific well-known hotel. In those cases the tool output will be used both to render the view and to get context to answer questions from the user by the LLM. If you have the unique property_id value from a previous search call (such as get_properties_search_by_context) use it ALWAYS instead of the hotel name. The property_id value will always go first. Then the name. If there's no previuosly fetch property_id for the hotel, use the name. This tool will be used to search and locate hotels by name and, optionally, some location. Location will ALWAYS be translated to a bounding box and NOT passed as part of the name. If this tool was previously called for the same hotel avoid calling it again, since the information will be the same. Instead, try to answer the question using the already fetch information from the previous call. At least one value 'name' or 'property_id' is required. If both are used, only 'property_id' will be accepted. The returned result will be an array of key-values. The key will be the type of information returned as following: - property_info: a list of key-values elements such as 'property_name', 'country', 'lat', 'lng', 'url', etc. with specific data for that hotel. - property_description: A text containing a long description for the hotel with all its details, such as the hotel type, information about the location, their category, etc. - property_context: A text containing contextual information and descriptions for the property, similar to the previous one. - property_info_var_closed_dates: A specific text regarding the closing dates for that property (example: "this hotel is closed during new years eve"). - property_info_var_guests_occupancy: A specific text regarding the occupancy and guest policy for the hotel (example: "Up to 1 adult in a single room. Up to 2 adults in a twin or double basic room"). Fields may be empty if there's no available information. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searchi…
get_property_full_from_reference
ChatGPTGiven a hotel name or a unique hotel identificator (a property_id), performs a search over a list of available hotels to return the information about the first match, if available, for such name. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. This information can be used to answer questions for the related hotel in case there's not enough context from the previously called tools or if the user is looking for information on a specific well-known hotel. In those cases the tool output will be used both to render the view and to get context to answer questions from the user by the LLM. If you have the unique property_id value from a previous search call (such as get_properties_search_by_context) use it ALWAYS instead of the hotel name. The property_id value will always go first. Then the name. If there's no previuosly fetch property_id for the hotel, use the name. This tool will be used to search and locate hotels by name and, optionally, some location. Location will ALWAYS be translated to a bounding box and NOT passed as part of the name. If this tool was previously called for the same hotel avoid calling it again, since the information will be the same. Instead, try to answer the question using the already fetch information from the previous call. At least one value 'name' or 'property_id' is required. If both are used, only 'property_id' will be accepted. The returned result will be an array of key-values. The key will be the type of information returned as following: - property_info: a list of key-values elements such as 'property_name', 'country', 'lat', 'lng', 'url', etc. with specific data for that hotel. - property_description: A text containing a long description for the hotel with all its details, such as the hotel type, information about the location, their category, etc. - property_context: A text containing contextual information and descriptions for the property, similar to the previous one. - property_info_var_closed_dates: A specific text regarding the closing dates for that property (example: "this hotel is closed during new years eve"). - property_info_var_guests_occupancy: A specific text regarding the occupancy and guest policy for the hotel (example: "Up to 1 adult in a single room. Up to 2 adults in a twin or double basic room"). Fields may be empty if there's no available information. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searchi…
get_property_full_from_reference
ChatGPTGiven a hotel name or a unique hotel identificator (a property_id), performs a search over a list of available hotels to return the information about the first match, if available, for such name. If the user has a specific date begin and a date end regarding a hotel search then the fields date_begin and date_end will include dates in YYYY-MM-DD format (example: 2025-02-15 for February 15th, 2025). If one or both dates aren't available nor specified by the user, empty strings will be used instead. This information can be used to answer questions for the related hotel in case there's not enough context from the previously called tools or if the user is looking for information on a specific well-known hotel. In those cases the tool output will be used both to render the view and to get context to answer questions from the user by the LLM. If you have the unique property_id value from a previous search call (such as get_properties_search_by_context) use it ALWAYS instead of the hotel name. The property_id value will always go first. Then the name. If there's no previuosly fetch property_id for the hotel, use the name. This tool will be used to search and locate hotels by name and, optionally, some location. Location will ALWAYS be translated to a bounding box and NOT passed as part of the name. If this tool was previously called for the same hotel avoid calling it again, since the information will be the same. Instead, try to answer the question using the already fetch information from the previous call. At least one value 'name' or 'property_id' is required. If both are used, only 'property_id' will be accepted. The returned result will be an array of key-values. The key will be the type of information returned as following: - property_info: a list of key-values elements such as 'property_name', 'country', 'lat', 'lng', 'url', etc. with specific data for that hotel. - property_description: A text containing a long description for the hotel with all its details, such as the hotel type, information about the location, their category, etc. - property_context: A text containing contextual information and descriptions for the property, similar to the previous one. - property_info_var_closed_dates: A specific text regarding the closing dates for that property (example: "this hotel is closed during new years eve"). - property_info_var_guests_occupancy: A specific text regarding the occupancy and guest policy for the hotel (example: "Up to 1 adult in a single room. Up to 2 adults in a twin or double basic room"). Fields may be empty if there's no available information. Additional params can be passed to act as filters and complementary information for different criteria. If a value is an empty string it'll be ignored. When passing those params, all the results will be only the ones matching all the conditions. Regarding the location, try to be as precise as possible, always going for the small location unit available (example: go with a city bounding box if provided instead of searching for the whole state bounding box. Go with a neighborhood bound box if available instead of searching on the city itself) Location must be ALWAYS converted as a bounding box with lat and long for the given point and a lat_height and lng_width according to the allowed params. NEVER set the location value in the query field. Allowed params are: - lat: float number with the latitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the latitude for the center of New York City). Setting a lat will also require a lng, lat_height and lng_width - lng: float number with the longitude coordinate for the place the user is searching for (example: if the user is searching for something in New York City, this value will be the longitude for the center of New York City). Setting a lng will also require a lng, lat_height and lng_width - lat_height: float number with the height (in degrees) for the bounding box centered on the lat / lng parameters for the place the user is searchi…
