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 the caller has a key for. Input: a free-text destination the way a person would write 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.

Every row carries the caveats that decide whether 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 the caller has no key for is listed in providers_skipped and is not counted anywhere in the comparison.

Rates go stale within minutes: a current comparison comes from a new call, not from an earlier result.

Input 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 the caller has 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 write 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

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 on what makes the sources' totals differ -- rating scales, tax treatment, currencies, a source that did not answer.
`message`	No
`children`	No
`currency`	No	The currency every source was ASKED for.
`api_usage`	No	With the caller's own key: what this call cost their RapidAPI plan, and what remains on it. On a free signed-in search (`trial` present): the day's free-search counter instead, and no plan figures -- the search ran on FlightPowers' key and nothing is billed to the user. Present on every response that reached the upstream, including a degraded one.
`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 describe the fix.
`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.

AddedOct 26, 2026
RemovedOct 22, 2026

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?

The description goes well past the annotations (readOnlyHint, openWorldHint, idempotentHint=false), disclosing exactly what each returned row contains, that rating_scale is 10 on Booking versus 5 on Airbnb, that taxes_included is null on Airbnb and 'a null is not a no', and that sources without a key land in providers_skipped and are excluded from the comparison. The staleness warning is consistent with idempotentHint=false and adds real decision context.

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?

Front-loaded with purpose and inputs, then two paragraphs of caveats that each carry decision-relevant information. The enumerated input list slightly duplicates the schema, but the density is purposeful rather than padded.

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 an open-world, multi-provider aggregation with an output schema, the description supplies the interpretive layer the schema cannot: how to read rating_scale across sources, how to treat null taxes, and how skipped providers are handled. Nothing an agent needs to call or interpret the tool 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 schema already documents every parameter, including the free-text destination format the description restates. The description adds nothing on children or on provider selection beyond what the schema and its examples give, so this sits at the baseline.

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?

States a specific verb and resource — cross-source comparison of one stay's prices across every source the caller has a key for — and the row-per-source output makes it plainly distinct from the single-source siblings search_hotels, search_airbnb and find_hotel_by_name. An agent can pick it out without opening any 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 comparison framing plus the explicit note that 'a current comparison comes from a new call, not from an earlier result' tells the agent when this is the right tool and that results must not be cached. It stops short of naming the sibling tools or stating when a single-source search is preferable, so there is a small routing gap.

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.