Skip to main content
Glama

HasData

by com.hasdata
OverviewDiscussionsAdmin

booking_search: GET /

hasdata_booking_search_getBookingSearchResults

Get Booking Search Results

Searches Booking.com for accommodations by destination keyword and stay dates (checkInDate / checkOutDate) with guest composition (rooms, adults, children with ages) and rich filtering: property type, star rating, review score, hotel and room facilities, distance from center, reservation policy, bed preference, travel group, online payment, accessibility, plus optional price range and bedroom/bathroom counts. Pagination is page-based with 25 results per page; locale is controlled by language and currency. Returns each hotel's hotelId, title and Booking URL, location info (city, address, coordinates, distance to center / nearest beach), policies (free cancellation, no prepayment, child/pet stays), price (per stay, before discount, discount, currency), rating, review summary and main photo. Use to power travel-planning agents, OTA price/inventory monitoring, hotel competitor analysis, lead-generation in the hospitality vertical, or to feed hotelId / URL into the Booking Place endpoint for full property details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number of the search results. Booking.com returns 25 results per page; pass `2` for results 26–50, `3` for 51–75, etc.
sortNoSort order applied by Booking.com to the results page.
roomsYesNumber of rooms to book.
adultsYesNumber of adult guests across all rooms.
keywordYesFree-text destination query. Usually a city, region or neighborhood (e.g. `Paris`, `Manhattan, New York`); a specific property name is also accepted.
meals__NoFilter by available meal plans. Multiple values are combined with OR.
bedroomsNoMinimum number of bedrooms in the property.
childrenYesNumber of child guests across all rooms (0–10). Pass `0` if there are no children.
currencyNoCurrency of the prices returned in the response. Use `hotelCurrency` to keep each property's native currency. Provide one exact documented value (52 allowed), e.g. `hotelCurrency`, `usd`.
languageNoLanguage of the Booking.com interface and localized fields in the response.
rating__NoFilter by official star rating. Multiple values are combined with OR.
bathroomsNoMinimum number of bathrooms in the property.
price_max_NoMaximum total price for the stay, in the requested `currency`. Must be `>= 20` and greater than `price[min]`. Required if `price[min]` is omitted.
price_min_NoMinimum total price for the stay, in the requested `currency`. Must be `>= 10`. Required if `price[max]` is omitted.
checkInDateYesCheck-in date in `YYYY-MM-DD` format. Must be in the future and earlier than `checkOutDate`.
checkOutDateYesCheck-out date in `YYYY-MM-DD` format. Must be later than `checkInDate`.
childrenAgesNoComma-separated list of child ages, one entry per child (each `0`–`17`). Required when `children > 0` and the number of ages must equal `children`. Example: `1,3,7`
facilities__NoFilter by property-level facilities. Multiple values are combined with OR.
reviewScore__NoFilter by minimum guest review score bucket. Multiple values are combined with OR.
travelGroup__NoFilter by travel-group oriented stay options. Multiple values are combined with OR.
propertyType__NoFilter by property type. Multiple values are combined with OR.
bedPreference__NoFilter by bed configuration. Multiple values are combined with OR.
onlinePayment__NoFilter by online payment options.
roomFacilities__NoFilter by in-room facilities. Multiple values are combined with OR.
reservationPolicy__NoFilter by reservation flexibility. Multiple values are combined with OR.
roomAccessibility__NoFilter by in-room accessibility features. Multiple values are combined with OR.
distanceFromCenter__NoFilter by distance from the destination center. Multiple values are combined with OR.
propertyAccessibility__NoFilter by property-level accessibility features. Multiple values are combined with OR.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description indicates a read-only search operation through 'Searches' and 'Returns', and summarizes the output fields. However, with no annotations provided, it does not explicitly state that the operation is side-effect-free, whether it modifies any data, or mention rate limits or authentication behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and use cases, and the long middle section is dense with essential detail about filters and returned fields rather than being padded. It is long but efficient given the number of parameters and output categories.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description clearly summarizes the returned hotel fields, pagination behavior, locale controls, and relationship to the Booking Place endpoint. It does not enumerate the exact response shape or error cases, but it provides enough context for a caller to understand what the tool does and how to chain it with the sibling tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Every parameter has a description that goes beyond the raw schema, including constraints such as page size, date ordering, price minimums/maximums, childrenAges required when children > 0, currency value guidance, and OR semantics for array filters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly identifies this as a Booking.com accommodation search endpoint, states the core search inputs (destination, dates, guests), and explicitly positions it as the entry point before the Booking Place details endpoint via the mention of feeding hotelId/URL there.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete use cases such as travel planning, price monitoring, and competitor analysis, and explicitly connects to the sibling Booking Place endpoint for full property details. It does not formally state when not to use the tool, but the practical guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HasData toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources