Skip to main content
Glama

Booking.com Hotel Search (Live Prices)

by com.flightpowers

Find one hotel by name

find_hotel_by_name
Read-only

Get availability and pricing for one named property. Input: the hotel name a person would type (adding the city helps when a chain has many properties) plus check-in and check-out dates -- no internal property ID needed, the resolution is done for you. Returns the property's price, review score, room type and a booking link. Use it to check one specific hotel, or to track a single property's price over time.

price_as_seen_from prices the stay as a shopper in that country would see it, which is what makes rate-parity checks possible.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
adultsNoNumber of adult guests.
childrenNoNumber of children sharing the room.
currencyNoISO currency code for the prices returned, e.g. "usd".
hotel_nameYesThe property name a person would type, e.g. "Hotel Artemide". Adding the city ("Hotel Artemide Rome") disambiguates a chain with many properties. No internal property ID is needed.
checkin_dateYesFirst night of the stay, "YYYY-MM-DD".
checkout_dateYesDeparture morning, "YYYY-MM-DD". Must be after checkin_date.
price_as_seen_fromNoTwo-letter country code, e.g. "de". Prices the stay as a shopper resident in that country would see it, which is what makes a rate-parity check on one property possible.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageNo
resultsYesThe itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
api_usageNoWhat 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_urlNoWhere the caller subscribes or changes plan.
result_countNo
needs_api_keyNoTrue 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_filtersNoWhich of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through.
quota_exhaustedNoTrue when the caller's RapidAPI plan has no requests left for the current period.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark the tool as read-only and open-world, and the description adds crucial behavior beyond them: 'Rates go stale within minutes: never reuse an earlier result.' It also explains how price_as_seen_from affects rate-parity checking.

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 and front-loaded with the core purpose, then adds only high-value context: return summary, use cases, price perspective, and staleness. Every sentence earns its place without filler.

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?

For a read-only single-property lookup with a full input schema and an output schema, the description covers the essential operational context: input format, resolution, price perspective, freshness, and use cases. Nothing material is missing.

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 baseline is 3. The description lightly reinforces hotel_name and price_as_seen_from semantics but mostly restates what the schema already says.

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 'Get availability and pricing for one named property,' naming a specific action and resource. It distinguishes itself from the search sibling by emphasizing one known property, a human-typed name, and no internal ID requirement.

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 states clear use cases: 'check one specific hotel, or to track a single property's price over time.' It does not explicitly name search_hotels as the alternative for discovery, but the known-property framing strongly implies the boundary.

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) toolsInspect
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.

Resources