Booking.com Hotel Search (Live Prices)

Search hotels

search_hotels

Read-only

Search live hotel availability and nightly prices for a destination and date range. Input: a free-text destination the way a person would say it ("Rome", "Tokyo Shibuya"), plus check-in and check-out dates. Returns each property's price, review score, room type, location and a booking link.

Set price_as_seen_from to a two-letter country code to price the same stay the way a shopper resident in that country would see it -- that is how rate-parity and geo-pricing differences are found, and no other travel tool here can do it.

Rates go stale within minutes: never reuse an earlier result, search again.

Input Schema

TableJSON Schema

Name	Required	Description
`adults`	No	Number of adult guests. Defaults to the upstream default when omitted.
`filters`	No	Property filters to apply, e.g. ["free_cancellation", "breakfast_included"]. An unknown name is rejected with the list of valid ones rather than being ignored.
`children`	No	Number of children sharing the room.
`currency`	No	ISO currency code for the prices returned, e.g. "usd".
`destination`	Yes	Where to stay, in free text the way a person would say it, e.g. "Rome" or "Tokyo Shibuya". A city, district, landmark or region all work; no internal location ID is needed.
`checkin_date`	Yes	First night of the stay, "YYYY-MM-DD".
`checkout_date`	Yes	Departure morning, "YYYY-MM-DD". Must be after checkin_date.
`budget_per_night`	No	Only return properties at or below this nightly price, in `currency`.
`price_as_seen_from`	No	Two-letter country code, e.g. "de". Prices the stay through a residential connection in that country, so the result is what a shopper resident there would be quoted. This is what makes rate-parity and geo-pricing checks possible; omit it for a neutral price.

Output Schema

TableJSON Schema

Name	Required	Description
`message`	No
`results`	Yes	The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
`api_usage`	No	What this call cost the caller's own RapidAPI plan, and what remains on it. Present on every response that reached the upstream, including a degraded one -- a search that failed was still billed.
`signup_url`	No	Where the caller subscribes or changes plan.
`result_count`	No
`needs_api_key`	No	True when no usable RapidAPI key arrived with the call, or the upstream rejected the one that did. No search was run and nothing was billed; signup_url and message say how to fix it.
`applied_filters`	No	Which of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through.
`quota_exhausted`	No	True when the caller's RapidAPI plan has no requests left for the current period.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavioral traits: results are live and go stale within minutes, previous results should never be reused, and price_as_seen_from changes pricing through a residential connection in the given country. This meaningfully enriches the agent's understanding of volatility and geo-pricing behavior.

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

Conciseness5/5

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

The description is compact, well-structured, and front-loaded with the core purpose. Each paragraph earns its place: what it does, the unique geo-pricing parameter, and the critical staleness warning. No filler or redundant restatement of schema/annotations.

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?

Given the annotations, full schema coverage, an output schema, and the tool's moderate complexity, the description covers everything needed for correct invocation: input format, return contents, unique capability, and freshness expectations. The optional parameters are sufficiently documented in the schema, so the description does not need to re-explain them.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds real semantic value beyond the schema by giving natural examples of free-text destinations ('Rome', 'Tokyo Shibuya') and explaining the practical purpose of price_as_seen_from for rate-parity and geo-pricing checks. It does not need to repeat every parameter since the schema already documents them thoroughly.

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 states a specific verb and resource: search live hotel availability and nightly prices for a destination and date range. It also enumerates what is returned (price, review score, room type, location, booking link) and makes clear this is destination-based search as opposed to find_hotel_by_name.

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?

The description gives clear context for when to use the tool: any free-text destination search with check-in/check-out dates. It also explicitly highlights the unique price_as_seen_from capability that no other travel tool here provides. However, it never explicitly contrasts the sibling find_hotel_by_name or states when to prefer that alternative.

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

All Booking.com Hotel Search (Live Prices) tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

The two tools are clearly separated by scope: search_hotels handles destination-level discovery while find_hotel_by_name retrieves a specific named property. They could still be confused because both return similar availability, price, and booking-link data, but the descriptions make the intended use obvious.

Naming Consistency4/5

Both tool names are snake_case and verb-first, creating a readable pattern. The verbs differ (search vs find) and the object forms differ (hotels vs hotel_by_name), so the convention is not perfectly parallel, but it is still predictable and consistent enough.

Tool Count4/5

Two tools is on the low end, but the server's stated purpose is hotel search rather than full booking management, so search_hotels and find_hotel_by_name cover the core workflow. A destination-level search plus a single-property lookup is a reasonable minimal scope.

Completeness3/5

The core search and single-hotel lookup operations are present, and live price/rate-parity support is provided through price_as_seen_from. However, the surface has no way to specify guests or rooms, filter or sort results, or paginate, which are notable gaps for a hotel search tool.

Search hotels

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources