Booking.com Hotel Search (Live Prices)

FlightPowers: compare hotel rates across sources

compare_hotel_rates

Read-only

FlightPowers cross-source comparison: prices one stay on every source you have a key for. Input: a free-text destination the way a person would say it ("Rome", "Tokyo Shibuya"), check-in and check-out dates, and how many adults. Returns one row per source: the cheapest and the median stay total, how many places were found, the currency and when it was read.

Read the caveats on every row before you say one source is cheaper. rating_scale is 10 on Booking and 5 on Airbnb. taxes_included is true on Booking, where excluded taxes are folded into the price, and null on Airbnb, where we have not established the tax treatment of the display total; a null is not a no. A source you have no key for is listed in providers_skipped with a subscribe link and is not counted anywhere in the comparison.

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

Requires the caller's own RapidAPI key for the Booking Live API. Get one (free tier available) at https://rapidapi.com/mtnrabi/api/booking-live-api, then pass it as an x-rapidapi-key header (preferred), a ?rapidapi_key= query parameter on the server URL, or your client's own API key field -- first non-empty wins. Usage counts against the caller's own RapidAPI plan, not ours; every response reports what it spent and what is left in api_usage. No key? Sign in with Google and the first 10 searches each day are free on this server -- ad-free, nothing to paste. Connect your own RapidAPI key at https://hotels.flightpowers.com/connect to remove the cap.

Input Schema

TableJSON Schema

Name	Required	Description
`adults`	No	Number of adult guests. Defaults to the upstream default when omitted.
`children`	No	Number of children sharing the room.
`currency`	No	ISO currency code for every row, e.g. "usd". Sources are asked for the same currency so the totals are comparable; a row that came back in a different one says so in its own currency field and is not converted.
`providers`	No	Which sources to price, e.g. ["booking", "airbnb"]. Defaults to both. A source you have no RapidAPI key for is not called and appears in providers_skipped.
`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.

Output Schema

TableJSON Schema

Name	Required	Description
`adults`	No
`nights`	No	Nights between the two dates, or null when the dates could not be read as dates.
`caveats`	No	Sentences that must be read before one source is called cheaper than another -- differing rating scales, differing tax treatment, differing currencies, a source that did not answer.
`message`	No
`children`	No
`currency`	No	The currency every source was ASKED for.
`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.
`providers`	Yes
`signup_url`	No	Where the caller subscribes or changes plan.
`destination`	No
`checkin_date`	No
`checkout_date`	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.
`quota_exhausted`	No	True when the caller's RapidAPI plan has no requests left for the current period.
`providers_skipped`	No	Sources that were NOT called, each named with why and where to subscribe. A source here contributed nothing to results and is counted nowhere. It is listed rather than dropped because a silently missing source is indistinguishable from a source that had nothing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 22, 2026

addedOutput schema / properties / api_usage / properties / hub_requests_billed

Added value: +{
+  "description": "How many HTTP requests RapidAPI actually billed. Larger than requests_used_by_this_call when a search failed with a server error and was retried, because the retry is billed too. This is the figure the invoice will show.",
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / api_usage / properties / requests_used_by_this_call / description
```
Added value: +"How many date/destination combinations were searched -- what the answer COVERS."
```

AddedSep 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes far beyond the annotations (readOnlyHint/openWorldHint/destructiveHint). It discloses that rates go stale within minutes, that rating_scale differs by source, that taxes_included is null-and-not-a-no on Airbnb, that keyless providers appear in providers_skipped and are excluded, and that usage counts against the caller's RapidAPI plan with api_usage reporting. These are exactly the behavioral traits an agent needs and that annotations cannot convey.

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?

Purpose is front-loaded, followed by correctness-critical caveats, then freshness, then auth — a logical order where each paragraph earns its place. The auth section is somewhat long (five sentences on key acquisition, header precedence, and free-tier fallback), but that detail is operationally necessary for an agent to invoke the tool with a key.

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 tool with this complexity — 7 params, external RapidAPI dependency, cross-source semantics, and freshness constraints — the description is remarkably complete. It covers inputs, output shape, per-source caveats, staleness, auth requirements and key precedence. An output schema exists, so return-value documentation is not the description's job, and nothing needed for correct invocation 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%, and the schema entries are already rich (e.g., destination free-text semantics, currency non-conversion, providers skipping). The description's input summary ('free-text destination the way a person would say it...') largely restates the schema. With full coverage, the baseline 3 applies; the description adds little parameter meaning beyond the schema.

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 opening line states a specific verb and resource: 'prices one stay on every source you have a key for' — a cross-source price comparison. This differentiates it from siblings find_hotel_by_name and search_hotels, which are lookup tools, so an agent can route correctly without opening the schema.

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 operational context: use it to price a single stay across all keyed sources, and 'never reuse an earlier result, compare again' because rates go stale. It does not explicitly name sibling tools or state when-not-to-use-this, so it falls short of a 5, but the usage context is unmistakable.

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

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.