Google Hotels search: rates, ratings, amenities and what each booking site charges, as JSON.
Scored across 1 tool
With only a single tool, there is no possibility of misselection or overlap with other tools. Its purpose (searching Google Hotels) is unambiguous.
The single name `hasdata_google_travel_hotels_getGoogleHotels` mixes snake_case with a camelCase verb, which is internally inconsistent. With only one tool there is no cross-tool pattern to establish, but the name itself violates a consistent convention.
A single tool is thin for a hotel-search server, especially given the breadth of data returned. It would benefit from companion operations like location resolution or detail lookup, though a search-only surface is defensible.
The search tool is very comprehensive in filters and returned fields, but the surface lacks supporting operations such as hotel detail retrieval, location/autocomplete resolution, or review endpoints. Agents must work around these gaps for full lifecycle travel research.
Get Google Hotels Results
Searches Google Hotels for hotels and vacation rentals with check-in/check-out dates, guest mix (adults, children with ages), localization (country, language, currency), and advanced filters: price range, property types, amenities, minimum rating, brands, hotel class, free cancellation, special offers, eco-certified, vacation rentals only, bedrooms, bathrooms, and sort order (lowest price, highest rating, most reviewed). Returns per-property name, description, link, GPS coordinates, check-in/out times, rate per night and total rate, price comparisons across sources, hotel class, overall rating, reviews, location rating, images, amenities, nearby places, deals, eco-certification, and pagination tokens. Use for travel research agents, hotel rate monitoring, OTA dashboards, and competitive analysis of accommodations across markets.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The search query for Google Hotels (e.g., a city, neighborhood, or hotel name). | |
| gl | No | The two-letter country code for the country you want to limit the search to. Provide one exact documented value (245 allowed), e.g. `ac`, `af`. | |
| hl | No | The two-letter language code for the language you want to use for the search. Provide one exact documented value (159 allowed), e.g. `af`, `ak`. | |
| adults | No | Number of adult guests (1-6). | |
| brands | No | Comma-separated list of brand IDs to filter by. Brand IDs are returned in the response under `brands` for the same query. | |
| rating | No | Filter by minimum overall guest rating. Options: - `threePointFivePlus` — 3.5 stars or higher - `fourPlus` — 4.0 stars or higher - `fourPointFivePlus` — 4.5 stars or higher | |
| sortBy | No | Sort hotel results. Options: - `lowestPrice` — lowest price - `highestRating` — highest rating - `mostReviewed` — most reviewed | |
| bedrooms | No | Minimum number of bedrooms (vacation rentals only). | |
| children | No | Number of child guests (1-5). Total guests (adults + children) cannot exceed 6. | |
| currency | No | Parameter defines the currency of the returned prices Provide one exact documented value (71 allowed), e.g. `ALL`, `DZD`. | |
| maxPrice | No | Maximum price per night, in the selected currency. | |
| minPrice | No | Minimum price per night, in the selected currency. | |
| amenity__ | No | List of amenities to filter by (e.g., `hotelFreeWifi,hotelPool`). Values prefixed `hotel*` apply when searching hotels (the default mode). Values prefixed `rental*` apply when `vacationRentals=true`. The two sets are disjoint because Google Hotels exposes different amenity catalogs for each mode — pass values matching the mode you're querying. | |
| bathrooms | No | Minimum number of bathrooms (vacation rentals only). | |
| hotelClass | No | Comma-separated list of hotel star classes to include (e.g., `2,3,4,5`). | |
| checkInDate | Yes | The check-in date in 'yyyy-MM-dd' format. | |
| checkOutDate | Yes | The check-out date in 'yyyy-MM-dd' format. | |
| childrenAges | No | Comma-separated list of children ages (e.g., `5,8,12`). Must match the number of children. | |
| ecoCertified | No | Show only eco-certified properties. | |
| nextPageToken | No | Token to fetch the next page of hotel results. Returned in the `pagination` field of a previous response. | |
| propertyToken | No | Token used to retrieve details for a specific property. Returned in each property in the results. | |
| specialOffers | No | Show only properties with special offers. | |
| propertyType__ | No | List of property types to filter by (e.g., `hotelResort,hotelMotel`). Values prefixed `hotel*` apply when searching hotels (the default mode). Values prefixed `rental*` apply when `vacationRentals=true`. The two sets are disjoint because Google Hotels exposes different property-type catalogs for each mode — pass values matching the mode you're querying. | |
| vacationRentals | No | Search vacation rentals instead of hotels. | |
| freeCancellation | No | Show only properties offering free cancellation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value by enumerating what the call actually returns (rates, price comparisons, reviews, images, deals, pagination tokens), which matters because no output schema exists; it still omits auth/rate-limit behavior.
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?
Purpose is front-loaded in the first sentence, but the second sentence is a very long run-on enumeration of return fields. That inventory earns some of its length given the absence of an output schema, yet it is undifferentiated and would be more usable as a structured list.
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?
For a 25-parameter, no-output-schema tool, the description covers the filter surface, the hotel-vs-rental mode distinction, and the return payload inventory. Missing pieces are operational (auth, rate limits, pagination workflow) rather than selection-critical.
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 100%, so every parameter is already documented in the schema, including the hotel*/rental* prefix semantics and enum meanings. The description's category listing largely restates those fields without adding format or constraint detail, so the baseline 3 applies.
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 opens with a specific verb and resource ('Searches Google Hotels for hotels and vacation rentals') and scopes it with check-in/check-out, guest mix, localization, and filter categories. It is unambiguous about what the tool does, though there are no sibling tools against which it must differentiate itself.
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?
It lists target audiences ('travel research agents, hotel rate monitoring, OTA dashboards, and competitive analysis'), which implies usage context, but gives no explicit when-to-use/when-not guidance, no prerequisites, and no workflow hints (e.g., how to continue pagination or switch to vacation-rental mode).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
hasdata_google_travel_hotels_getGoogleHotelsGoogle Hotels prices for any dates and guests, ratings, amenities and every booking site's price.
Google Hotels for any city or area: nightly prices for your dates (with taxes), star class, rating, reviews, coordinates, nearby places and photos, with rating, class and price filters. Runs on Apify, $1 per 1,000 hotels.
Every booking site's price for chosen hotels and dates on Google Hotels.
Google Hotels prices, ratings, reviews, and photos via an Apify Actor, hosted MCP.
Add one secure layer between your agents and this server.
