Kingston Hotels

Given 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". The location should be provided as a bounding box with the proper params. The location is passed as a bounding box via the parameters, not as text in the query field (for example, for 'a hotel named XXX in Madrid', pass Madrid as a bounding box and keep the location out of 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) The location is expressed as a bounding box with lat and long for the given point and a lat_height and lng_width, using the allowed params. The location goes in these params, not as text 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 with 4 or 4 and a half stars) - language: user preferred language in 2-letters format. If no one is explicitly provided use the current conversation language (example: en, es, it, pt) - currency: uppercase 3-letters ISO 4217 currency code. Only provide this if the user has explicitly requested a specific currency. If the user has not mentioned any currency preference, omit this field. - date_begin: initial day of the stay if the user has specified a date range for a hotel stay. Must be in YYYY-MM-DD format (example: 2026-03-21). A date_begin requires a date_end value - date_end: end day of the stay if the user has specified a date range for a hotel stay. Must be in YYYY-MM-DD format (example: 2026-03-21). A date_end requires a date_begin value - adults: number of adults on the hotel stay the user is talking about. If there's no explicit mention on the number of adults on the stay use the value 2 - children: number of kids or children on the hotel stay the user is talking about. If there's no explicit mention on the number of children or kids on the stay use the value 0 - children_ages: comma-separated age values for all the children or kids on the hotel stay the user is talking about (example: 2,2,3 for 3 children with ages 2, 2, and 3). This value is mandatory if the children value is not 0. The number of different ages must match the children value 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). Choosing the bounding box SIZE: pick lat_height and lng_width by the TYPE of place, rather than covering the whole administrative area. A box that is too large crosses borders and returns hotels from neighbouring regions or countries, so keeping it compact works best: - City: a small box, e.g. lat_height around 0.7 and lng_width around 0.9 for a large city such as Dubai; use even smaller values for smaller cities. - Neighbourhood or district: an even smaller box than a city. - Country: rather than a full-country bounding box, use a compact representative box centered on the country: around 1.5 / 2.0 for small countries, 3.0 / 4.0 for medium countries such as Germany, France, Spain, Italy or the United Kingdom, and 6.0 / 8.0 ONLY for very large countries such as the United States, China, Canada, Brazil, India, Australia or Russia. The mcp_thn_context_user_description parameter for this tool must be a concise profile of the user's permanent travel persona and recurring traits (e.g., 'solo traveler who prioritizes safety and quiet environments for remote work' or 'family of four that usually seeks kid-friendly resorts'). This context can change on future interactions with the user, and can be ignored if there's not enough info. Base it only on what can be deduced from previous interactions. This is an optional parameter. The mcp_thn_context_user parameter must be a concise and specific list of the user's requirements, constraints, and the goals they aim to achieve with this search (e.g., 'a family-friendly hotel with a swimming pool near Shibuya Station for a summer holiday' or 'looking for a pet-friendly boutique hotel with a spa for a relaxing weekend getaway'). This context can change on future interactions with the user, and can be ignored if there's not enough info. Base it only on what can be deduced from previous interactions. This is an optional parameter. 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. The input query must be translated to English before processing. If the query refers to multiple distinct aspects of a hotel (e.g., location, cleanliness, amenities), it must be splitted into multiple sub-queries, each separated by a dot (.). Each sub-query must be a complete question, not just a keyword or phrase. For each query or sub-query, three paraphrased variations will be generated, preserving the same intention and meaning but with different words. These should also be separated by dots (.): Example: 1. Original query: "Tell me about the hotel's location and the quality of service." 2. Original query splitted into the different asked topics: "What is the location of the hotel like?.How is the quality of the service at the hotel?" 3. Each sub-query will then generate three variations, like: "What is the location of the hotel like?.How convenient is the hotel's location?.Can you tell me about the hotel's surroundings?" "How do guests rate the hotel's service?.What is the level of service like at the hotel?.Are people satisfied with the service provided?"

Given 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" The location should be provided as a bounding box with the proper params. The location is passed as a bounding box via the parameters, not as text in the query field (for example, for 'a hotel named XXX in Madrid', pass Madrid as a bounding box and keep the location out of 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) The location is expressed as a bounding box with lat and long for the given point and a lat_height and lng_width, using the allowed params. The location goes in these params, not as text 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 with 4 or 4 and a half stars) - language: user preferred language in 2-letters format. If no one is explicitly provided use the current conversation language (example: en, es, it, pt) - currency: uppercase 3-letters ISO 4217 currency code. Only provide this if the user has explicitly requested a specific currency. If the user has not mentioned any currency preference, omit this field. - date_begin: initial day of the stay if the user has specified a date range for a hotel stay. Must be in YYYY-MM-DD format (example: 2026-03-21). A date_begin requires a date_end value - date_end: end day of the stay if the user has specified a date range for a hotel stay. Must be in YYYY-MM-DD format (example: 2026-03-21). A date_end requires a date_begin value - adults: number of adults on the hotel stay the user is talking about. If there's no explicit mention on the number of adults on the stay use the value 2 - children: number of kids or children on the hotel stay the user is talking about. If there's no explicit mention on the number of children or kids on the stay use the value 0 - children_ages: comma-separated age values for all the children or kids on the hotel stay the user is talking about (example: 2,2,3 for 3 children with ages 2, 2, and 3). This value is mandatory if the children value is not 0. The number of different ages must match the children value 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). Choosing the bounding box SIZE: pick lat_height and lng_width by the TYPE of place, rather than covering the whole administrative area. A box that is too large crosses borders and returns hotels from neighbouring regions or countries, so keeping it compact works best: - City: a small box, e.g. lat_height around 0.7 and lng_width around 0.9 for a large city such as Dubai; use even smaller values for smaller cities. - Neighbourhood or district: an even smaller box than a city. - Country: rather than a full-country bounding box, use a compact representative box centered on the country: around 1.5 / 2.0 for small countries, 3.0 / 4.0 for medium countries such as Germany, France, Spain, Italy or the United Kingdom, and 6.0 / 8.0 ONLY for very large countries such as the United States, China, Canada, Brazil, India, Australia or Russia. The mcp_thn_context_user_description parameter for this tool must be a concise profile of the user's permanent travel persona and recurring traits (e.g., 'solo traveler who prioritizes safety and quiet environments for remote work' or 'family of four that usually seeks kid-friendly resorts'). This context can change on future interactions with the user, and can be ignored if there's not enough info. Base it only on what can be deduced from previous interactions. This is an optional parameter. The mcp_thn_context_user parameter must be a concise and specific list of the user's requirements, constraints, and the goals they aim to achieve with this search (e.g., 'a family-friendly hotel with a swimming pool near Shibuya Station for a summer holiday' or 'looking for a pet-friendly boutique hotel with a spa for a relaxing weekend getaway'). This context can change on future interactions with the user, and can be ignored if there's not enough info. Base it only on what can be deduced from previous interactions. This is an optional parameter. 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. The input query must be translated to English before processing. If the query refers to multiple distinct aspects of a hotel (e.g., location, cleanliness, amenities), it must be splitted into multiple sub-queries, each separated by a dot (.). Each sub-query must be a complete question, not just a keyword or phrase. For each query or sub-query, three paraphrased variations will be generated, preserving the same intention and meaning but with different words. These should also be separated by dots (.): Example: 1. Original query: "Tell me about the hotel's location and the quality of service." 2. Original query splitted into the different asked topics: "What are the visitors saying about the location?.How good is the quality of service at the hotel?" 3. Each sub-query will then generate three variations, like: "What is the location of the hotel like?.How convenient is the hotel's location?.What are the opinions about the hotel's surroundings?" "How do guests rate the hotel's service?.What is the level of service like at the hotel?.Are people satisfied with the service provided?"

Given 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; a "source" type link is not a direct booking link and should not be presented as one. Both links and prices are returned 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) rather than the full 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.

Given 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) prefer it over the hotel name; the property_id takes precedence, otherwise use the name. If there's no previously fetched property_id for the hotel, use the name. This tool searches and locates hotels by name and, optionally, some location. Any location is passed as a bounding box rather than 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) The location is expressed as a bounding box with lat and long for the given point and a lat_height and lng_width, using the allowed params. The location goes in these params, not as text 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 with 4 or 4 and a half stars) - language: user preferred language in 2-letters format. If no one is explicitly provided use the current conversation language (example: en, es, it, pt) - currency: uppercase 3-letters ISO 4217 currency code. Only provide this if the user has explicitly requested a specific currency. If the user has not mentioned any currency preference, omit this field. - date_begin: initial day of the stay if the user has specified a date range for a hotel stay. Must be in YYYY-MM-DD format (example: 2026-03-21). A date_begin requires a date_end value - date_end: end day of the stay if the user has specified a date range for a hotel stay. Must be in YYYY-MM-DD format (example: 2026-03-21). A date_end requires a date_begin value - adults: number of adults on the hotel stay the user is talking about. If there's no explicit mention on the number of adults on the stay use the value 2 - children: number of kids or children on the hotel stay the user is talking about. If there's no explicit mention on the number of children or kids on the stay use the value 0 - children_ages: comma-separated age values for all the children or kids on the hotel stay the user is talking about (example: 2,2,3 for 3 children with ages 2, 2, and 3). This value is mandatory if the children value is not 0. The number of different ages must match the children value 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). Choosing the bounding box SIZE: pick lat_height and lng_width by the TYPE of place, rather than covering the whole administrative area. A box that is too large crosses borders and returns hotels from neighbouring regions or countries, so keeping it compact works best: - City: a small box, e.g. lat_height around 0.7 and lng_width around 0.9 for a large city such as Dubai; use even smaller values for smaller cities. - Neighbourhood or district: an even smaller box than a city. - Country: rather than a full-country bounding box, use a compact representative box centered on the country: around 1.5 / 2.0 for small countries, 3.0 / 4.0 for medium countries such as Germany, France, Spain, Italy or the United Kingdom, and 6.0 / 8.0 ONLY for very large countries such as the United States, China, Canada, Brazil, India, Australia or Russia. The mcp_thn_context_user_description parameter for this tool must be a concise profile of the user's permanent travel persona and recurring traits (e.g., 'solo traveler who prioritizes safety and quiet environments for remote work' or 'family of four that usually seeks kid-friendly resorts'). This context can change on future interactions with the user, and can be ignored if there's not enough info. Base it only on what can be deduced from previous interactions. This is an optional parameter. The mcp_thn_context_user parameter must be a concise and specific list of the user's requirements, constraints, and the goals they aim to achieve with this search (e.g., 'a family-friendly hotel with a swimming pool near Shibuya Station for a summer holiday' or 'looking for a pet-friendly boutique hotel with a spa for a relaxing weekend getaway'). This context can change on future interactions with the user, and can be ignored if there's not enough info. Base it only on what can be deduced from previous interactions. This is an optional parameter. 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.