HasData

booking_search: GET /

hasdata_booking_search_getBookingSearchResults

Read-only

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. Each page returns 25 results. To page through a destination, take pagination.nextPageToken from the response and pass it back as nextPageToken on the next call. The legacy page parameter still works but, on large destinations, returns duplicate properties across pages, so nextPageToken is preferred. 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "keyword": "<keyword>",
      "checkInDate": "<checkInDate>",
      "checkOutDate": "<checkOutDate>",
      "rooms": "<rooms>",
      "adults": "<adults>",
      "children": "<children>"
    },
    "name": "hasdata_booking_search_getBookingSearchResults"
  }
}

Input Schema

Name	Required	Description
`page`	No	Legacy pagination. Booking.com returns 25 results per page; pass `2` for results 26–50, `3` for 51–75, etc. On large destinations this returns duplicate properties across pages — use `nextPageToken` instead. Ignored when `nextPageToken` is provided.
`sort`	No	Sort order applied by Booking.com to the results page.
`rooms`	Yes	Number of rooms to book.
`adults`	Yes	Number of adult guests across all rooms.
`keyword`	Yes	Free-text destination query. Usually a city, region or neighborhood (e.g. `Paris`, `Manhattan, New York`); a specific property name is also accepted.
`meals__`	No	Filter by available meal plans. Multiple values are combined with OR.
`bedrooms`	No	Minimum number of bedrooms in the property.
`children`	Yes	Number of child guests across all rooms (0–10). Pass `0` if there are no children.
`currency`	No	Currency 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`.
`language`	No	Language of the Booking.com interface and localized fields in the response.
`rating__`	No	Filter by official star rating. Multiple values are combined with OR.
`bathrooms`	No	Minimum number of bathrooms in the property.
`price_max_`	No	Maximum 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_`	No	Minimum total price for the stay, in the requested `currency`. Must be `>= 10`. Required if `price[max]` is omitted.
`checkInDate`	Yes	Check-in date in `YYYY-MM-DD` format. Must be in the future and earlier than `checkOutDate`.
`checkOutDate`	Yes	Check-out date in `YYYY-MM-DD` format. Must be later than `checkInDate`.
`childrenAges`	No	Comma-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__`	No	Filter by property-level facilities. Multiple values are combined with OR.
`nextPageToken`	No	Recommended way to paginate. Omit it on the first request; the response returns `pagination.nextPageToken`, which you pass back here to fetch the next page. When a successful response omits the token, the last page has been reached. If a token has expired, the request fails with an error — start again without `nextPageToken`.
`reviewScore__`	No	Filter by minimum guest review score bucket. Multiple values are combined with OR.
`travelGroup__`	No	Filter by travel-group oriented stay options. Multiple values are combined with OR.
`propertyType__`	No	Filter by property type. Multiple values are combined with OR.
`bedPreference__`	No	Filter by bed configuration. Multiple values are combined with OR.
`onlinePayment__`	No	Filter by online payment options.
`roomFacilities__`	No	Filter by in-room facilities. Multiple values are combined with OR.
`reservationPolicy__`	No	Filter by reservation flexibility. Multiple values are combined with OR.
`roomAccessibility__`	No	Filter by in-room accessibility features. Multiple values are combined with OR.
`distanceFromCenter__`	No	Filter by distance from the destination center. Multiple values are combined with OR.
`propertyAccessibility__`	No	Filter by property-level accessibility features. Multiple values are combined with OR.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / nextPageToken

Added value: +{
+  "description": "Recommended way to paginate. Omit it on the first request; the response returns `pagination.nextPageToken`, which you pass back here to fetch the next page. When a successful response omits the token, the last page has been reached. If a token has expired, the request fails with an error — start again without `nextPageToken`.",
+  "type": "string"
+}

changedInput schema / properties / page / description

Previous value: -"Page number of the search results. Booking.com returns 25 results per page; pass `2` for results 26–50, `3` for 51–75, etc."New value: +"Legacy pagination. Booking.com returns 25 results per page; pass `2` for results 26–50, `3` for 51–75, etc. On large destinations this returns duplicate properties across pages — use `nextPageToken` instead. Ignored when `nextPageToken` is provided."

First observedSep 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description adds substantial behavior beyond them: a fixed page size of 25, the token round-trip protocol including last-page signaling and expiry errors, and the documented duplicate-result defect of the legacy `page` parameter. It also discloses that locale/language/currency shape the response.

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?

It is front-loaded — purpose, then inputs, then pagination, then locale, then return fields, then use cases — and every section is scannable. The long enumeration of filter categories and returned fields is somewhat repetitive with the schema, which keeps it from a 5.

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

Completeness5/5

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

With 29 parameters, no output schema and no nested objects, the description carries the return-value burden and does so by listing hotel identity, location, policies, price, rating and photo. Pagination, locale control and the downstream Booking Place handoff are all covered, leaving nothing an agent needs to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter including the pagination token, price bounds and filter semantics. The description's parameter content largely restates the schema at a category level (filter families, guest composition, dates) without adding syntax or constraints the schema lacks, so the baseline 3 applies.

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?

The description opens with a specific verb+resource ('Get Booking Search Results', 'Searches Booking.com for accommodations') and enumerates the inputs that define the search (destination keyword, check-in/check-out, guest composition, filters). It explicitly distinguishes itself from the nearest sibling by saying the results feed `hotelId`/URL into the Booking Place endpoint for full property details.

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?

It gives concrete usage context ('travel-planning agents, OTA price/inventory monitoring, hotel competitor analysis, lead-generation') and a clear follow-up path to the Booking Place endpoint, plus an explicit preference for `nextPageToken` over legacy `page` with the reason (duplicate properties on large destinations). It stops short of stating when NOT to use this tool versus near-alternatives such as Google Hotels or Tripadvisor search.

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

All HasData tools Inspect

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.