TheHotelsNetwork

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 (e.g., country or latitude) 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 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. Location is a priority when sending parameters: if there's a country to search for, use the country param. If not, but some location is specified (like a city, neighborhood or area), always create the bounding box with lat, lng, lat_height and lng_width coordinates. Try to avoid empty location queries if there's any location reference, even if it's inside the query itself. 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 country. Go with a neighborhood bound box if available instead of searching on the city itself) 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). This param won't be used if the country value is explicitly set. 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). This param won't be used if the country value is explicitly set. Setting a lat will also require a lat, 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. This param won't be used if the country value is explicitly set. 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. This param won't be used if the country value is explicitly set. Setting a lng_width will also require a lat, lng, and lat_height - country: lowercase string with the name of the country to filter for (example: italy, portugal). Multiple countries are allowed, separated by commas (example: germany,finland,argentina). Pass each country in multiple languages and common variants (Example: use 'lisboa,lisbon' instead of just 'lisbon'; use 'new york,nueva york' instead of just 'new york'). The country param will be used ONLY if there's no lat / lng search. Otherwise it wont be used. Having a specific country to search for with no additional and more specific places takes priority over setting latitude and longitude params. - 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: user preferred currency in 3-letters format. If no one is explicitly provided use the closest one to the user location (example: EUR, GBP, USD) - 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 will ALWAYS require 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 will ALWAYS require 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 1 - 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 Location is a priority when sending parameters: if there's a country to search for, use the country param. If not, but some location is specified (like a city, neighborhood or area), always create the bounding box with lat, lng, lat_height and lng_width coordinates. Try to avoid empty location queries if there's any location reference, even if it's inside the query itself. 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 country. Go with a neighborhood bound box if available instead of searching on the city itself) If there's a previously returned mcp_thn_session_id value from a previous tool call, use that value. If there's no parameter saved from a previous call do not send anything. In that case this tool will return a new mcp_thn_session_id value that MUST be used in future tool calls during the current conversation. Once a thn_mcp_session_id is returned from a tool call that value will be used in all the future calls and no empty value should be used anymore. The mcp_thn_context_str parameter for this tool must be the current context for the conversation. This context can change on future interactions with the user, and can be ignored if there's not enough info. NEVER made up any information and DO NOT assume anything that cannot be deduced from previously interactions. The mcp_thn_context_str parameter MUST follow the param description. 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 - 'mcp_thn_session_id' will contain the current mcp_thn_session_id value. If the tool was called with a non-null mcp_thn_session_id value this one will be exactly the same. If the tool was called WITHOUT an mcp_thn_session_id value a NEW ONE will be generated and returned here. This new value will be the one to be re-used in future calls on EVERY tool - '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 (e.g., country or latitude) 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 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. Location is a priority when sending parameters: if there's a country to search for, use the country param. If not, but some location is specified (like a city, neighborhood or area), always create the bounding box with lat, lng, lat_height and lng_width coordinates. Try to avoid empty location queries if there's any location reference, even if it's inside the query itself. 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 country. Go with a neighborhood bound box if available instead of searching on the city itself) 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). This param won't be used if the country value is explicitly set. 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). This param won't be used if the country value is explicitly set. Setting a lat will also require a lat, 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. This param won't be used if the country value is explicitly set. 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. This param won't be used if the country value is explicitly set. Setting a lng_width will also require a lat, lng, and lat_height - country: lowercase string with the name of the country to filter for (example: italy, portugal). Multiple countries are allowed, separated by commas (example: germany,finland,argentina). Pass each country in multiple languages and common variants (Example: use 'lisboa,lisbon' instead of just 'lisbon'; use 'new york,nueva york' instead of just 'new york'). The country param will be used ONLY if there's no lat / lng search. Otherwise it wont be used. Having a specific country to search for with no additional and more specific places takes priority over setting latitude and longitude params. - 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: user preferred currency in 3-letters format. If no one is explicitly provided use the closest one to the user location (example: EUR, GBP, USD) - 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 will ALWAYS require 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 will ALWAYS require 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 1 - 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 Location is a priority when sending parameters: if there's a country to search for, use the country param. If not, but some location is specified (like a city, neighborhood or area), always create the bounding box with lat, lng, lat_height and lng_width coordinates. Try to avoid empty location queries if there's any location reference, even if it's inside the query itself. 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 country. Go with a neighborhood bound box if available instead of searching on the city itself) If there's a previously returned mcp_thn_session_id value from a previous tool call, use that value. If there's no parameter saved from a previous call do not send anything. In that case this tool will return a new mcp_thn_session_id value that MUST be used in future tool calls during the current conversation. Once a thn_mcp_session_id is returned from a tool call that value will be used in all the future calls and no empty value should be used anymore. The mcp_thn_context_str parameter for this tool must be the current context for the conversation. This context can change on future interactions with the user, and can be ignored if there's not enough info. NEVER made up any information and DO NOT assume anything that cannot be deduced from previously interactions. The mcp_thn_context_str parameter MUST follow the param description. 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 - 'mcp_thn_session_id' will contain the current mcp_thn_session_id value. If the tool was called with a non-null mcp_thn_session_id value this one will be exactly the same. If the tool was called WITHOUT an mcp_thn_session_id value a NEW ONE will be generated and returned here. This new value will be the one to be re-used in future calls on EVERY tool - '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. 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") If there's a previously returned mcp_thn_session_id value from a previous tool call, use that value. If there's no parameter saved from a previous call do not send anything. In that case this tool will return a new mcp_thn_session_id value that MUST be used in future tool calls during the current conversation. Once a thn_mcp_session_id is returned from a tool call that value will be used in all the future calls and no empty value should be used anymore. 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 - 'mcp_thn_session_id' will contain the current mcp_thn_session_id value. If the tool was called with a non-null mcp_thn_session_id value this one will be exactly the same. If the tool was called WITHOUT an mcp_thn_session_id value a NEW ONE will be generated and returned here. This new value will be the one to be re-used in future calls on EVERY tool - '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 unique hotel identificator known as "property_id" returns some text descriptions with information about the hotel, its surroundings and different related information such as opening and closing dates. This information can be used to answer questions for the related hotel in case there's not enough context from the previously called tools. In that case this tool MUST be called and the returned information will be used to try to answer the question. If the returned values cannot answer the question because there's not enough information, do NOT made anything up, just say "Cannot answer this question with my available information" or something similar. The returned result will be an array of key-values. The key will be the type of information returned as following:

• property_description: A text containing a description for the property with different information such as name, location, environment, 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. If there's a previously returned mcp_thn_session_id value from a previous tool call, use that value. If there's no parameter saved from a previous call do not send anything. In that case this tool will return a new mcp_thn_session_id value that MUST be used in future tool calls during the current conversation. Once a thn_mcp_session_id is returned from a tool call that value will be used in all the future calls and no empty value should be used anymore. 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 - 'mcp_thn_session_id' will contain the current mcp_thn_session_id value. If the tool was called with a non-null mcp_thn_session_id value this one will be exactly the same. If the tool was called WITHOUT an mcp_thn_session_id value a NEW ONE will be generated and returned here. This new value will be the one to be re-used in future calls on EVERY tool - '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.