Google Hotels search: rates, ratings, amenities and what each booking site charges, as JSON.
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion or overlap between tools. The purpose is clearly defined.
With a single tool, there is no naming pattern to evaluate for consistency. The name is descriptive and follows a verb_noun style, but no cross-tool comparison is possible.
One tool feels thin for a server that aims to cover hotel search and travel research, but the tool is highly comprehensive in its filters and return fields, making it borderline for the stated purpose.
The tool covers the full search-and-retrieve workflow for hotel results, including rich filtering and detailed property data. Missing operations like booking or adding reviews are outside the apparent search-focused scope.
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 (domain, 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?
No annotations were provided (no read-only or destructive hints), so the description carries the full burden. The description thoroughly explains what the tool does and returns, and as a search tool it is implicitly non-destructive. It doesn't mention rate limits or auth, but nothing contradicts the (absent) annotations, so no contradiction flag.
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?
The description is a single dense paragraph followed by use cases — reasonably structured and free of filler. It's long, but the density of useful information (explicit use cases, return scope) justifies the length without becoming wordy.
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?
There is no output schema, so the description doesn't need to detail return values. It compensates by explaining the data model through parameter docs (brands, pagination, property tokens) and by stating the range of returned per-property fields. Adequate for an agent to invoke the tool correctly.
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 coverage is 100%, and the descriptions add substantial value beyond the raw types: enum options (rating, sortBy) are human-readable, amenities and propertyType explain the disjoint hotel vs rental catalogs, childrenAges explains the count-matching requirement, and nextPageToken/propertyToken explain where the tokens originate. This far exceeds baseline expectation.
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 clearly states the tool's purpose — searching Google Hotels for hotels and vacation rentals with dates, guest mix, localization, and filters. It distinguishes itself from sibling tools (e.g., Google Flights, Airbnb, Booking) by being specifically for Google Hotels data, and explicitly names its use cases.
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?
The description explicitly lists when to use this tool — travel research agents, hotel rate monitoring, OTA dashboards, and competitive analysis. Combined with the sibling-tool list (Google Flights, Airbnb, Booking, etc.), it clearly routes the agent to the right tool without ambiguity.
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, ratings, reviews, and photos via an Apify Actor, hosted MCP.
Booking.com stays by destination and dates, and full property details, as structured JSON.
Google Flights itineraries with fares, legs, carbon emissions and price history, as JSON.
Search hotel prices, get best overall and best direct price in structured response. Get your developer token at https://Infoseek.ai/mcp
Add one secure layer between your agents and this server.
