post_dataforseo_business_google_hotel_searches_liveHotel Searches API provides results containing information about different hotels listed on Google Hotels. The provided results are specific to the selected location (see the List of Locations) and language (see the List of Languages) settings.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / body / items / properties / depth / descriptionPrevious value: -"*parsing depth* optional field number of results in Google Hotels default value: `20` organic results max value: `140` **Note:** your account will be billed per each 20 organic results regardless of paid listings in the response; thus, setting a depth above `20` may result in additional charges if Google Hotels return more than 20 results; if the specified depth is higher than the number of results in the response, the difference will be refunded automatically to your account balance"New value: +"parsing depth optional field number of results in Google Hotels default value: 18 organic results max value: 140 Note: your account will be billed per each 18 organic results regardless of paid listings in the response; thus, setting a depth above 18 may result in additional charges if Google Hotels return more than 18 results; if the specified depth is higher than the number of results in the response, the difference will be refunded automatically to your account balance"Input schema / properties / body / items / properties / language_code / descriptionPrevious value: -"*search engine language code* **required field if you don’t specify `language_name`** **if you use this field, you don’t need to specify `language_name`** you can receive the list of available languages with their `language_code` by making a separate request to `https://api.dataforseo.com/v3/business_data/google/languages` example: `en`"New value: +"search engine language code required field if you don't specify language_name if you use this field, you don't need to specify language_name you can receive the list of available languages with their language_code_by making a separate request to https://api.dataforseo.com/v3/business_data/google/languages example: enn"Input schema / properties / body / items / properties / location_code / descriptionPrevious value: -"*search engine location code* **required field if you don’t specify `location_name` or `location_coordinate`** **if you use this field, you don’t need to specify `location_name` or `location_coordinate`** you can receive the list of available locations with `location_code` by making a separate request to the `https://api.dataforseo.com/v3/business_data/google/locations` example: `2840`"New value: +"search engine location code required field if you don't specify location_name_or location_coordinate if you use this field, you don't need to specify location_name or location_coordinate you can receive the list of available locations with location_code by making a separate request to the https://api.dataforseo.com/v3/business_data/google/locations example: 2840n"Input schema / properties / body / items / properties / location_coordinate / descriptionPrevious value: -"*GPS coordinates of a location* **required field if you don’t specify `location_name` or `location_code`** **if you use this field, you don’t need to specify `location_name` or `location_code`** `location_coordinate` parameter should be specified in the *“latitude,longitude”* format the maximum number of decimal digits for *“latitude”* and *“longitude”*: 7 **Note**: if the coordinates are used to set a location, the search will occur in the nearest settlement example: `53.476225,-2.243572`"New value: +"GPS coordinates of a location required field if you don't specify location_name_or location_code if you use this field, you don't need to specify location_name or location_code location_coordinate parameter should be specified in the \"latitude,longitude\" format the maximum number of decimal digits for \"latitude\" and \"longitude\": 7 Note: if the coordinates are used to set a location, the search will occur in the nearest settlement example: 53.476225,-2.243572n"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is externally supplied. The description adds nothing about live billing per 18 results, rate limits, or what a 'live' request entails, so it does not enrich behavior beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no waste, and the location/language scoping is stated up front. It is appropriately sized, though the content is largely boilerplate rather than operationally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, but for a paid, open-world live search this thin description leaves the agent without sibling differentiation, usage conditions, or any hint of the request payload it must construct.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported at 0% for the top-level body parameter, so the description would need to compensate. It does not: it never mentions the request fields (keyword, depth, dates, guests, filters) despite the nested schema being the whole input. It also does not explain the array-of-requests batch semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns hotel results from Google Hotels, and notes they are scoped by location and language. It is clear what the tool does, but it does not distinguish itself from close siblings such as post_dataforseo_business_google_hotel_info_live or post_dataforseo_business_listings_search_live.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling search/info endpoints, and no mention of prerequisites beyond a pointer to Locations/Languages lists. An agent gets no routing signal at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.