Booking.com Hotel Search (Live Prices)

FlightPowers: search Airbnb stays

search_airbnb

Read-only

FlightPowers Airbnb search: live Airbnb stays and prices for a destination and dates, read from Airbnb's public search page at request time. Returns each stay's name, stay total, per-night price, currency, rating out of 5, review count, room type, bedrooms, beds, baths and Airbnb link: 10 stays by default, the cheapest always among them.

The guest counts, price, bedroom, bed, bathroom and room-type filters are Airbnb's own; min_rating and sort are applied by FlightPowers to the one page of stays the search returned. Prices are Airbnb's displayed totals for the dates; whether they include taxes is not stated by the page, so taxes_included is null. Rates go stale within minutes: a current price comes from a new search. Data read from Airbnb's public pages; FlightPowers is not affiliated with Airbnb.

Input Schema

Name	Required	Description
`pets`	No	Pets travelling.
`sort`	No	price_asc or price_desc by per-night price, rating_desc by rating; unset keeps Airbnb's order.
`limit`	No	Stays returned (default 10), in search order (after `sort`), with the cheapest always included.
`adults`	No	Adult guests.
`infants`	No	Infants under 2.
`verbose`	No	Returns the source's full rows (image, coordinates and more), every stay unless limit is set.
`children`	No	Children aged 2 to 12.
`currency`	No	ISO currency code, e.g. "eur"; USD when omitted.
`min_beds`	No	Fewest beds.
`price_max`	No	Highest price per night, in `currency` (Airbnb's nightly rate, before fees; price_total includes fees and can exceed price_max x nights).
`price_min`	No	Lowest price per night, in `currency` (Airbnb's nightly rate, before fees).
`min_rating`	No	Lowest rating kept, out of 5; unrated stays are left out.
`room_types`	No	Room types to keep, e.g. ["Entire home/apt"].
`destination`	Yes	Free-text place, e.g. "Lisbon" or "Tokyo Shibuya".
`checkin_date`	Yes	First night, "YYYY-MM-DD".
`min_bedrooms`	No	Fewest bedrooms.
`checkout_date`	Yes	Departure day, "YYYY-MM-DD", after checkin_date.
`min_bathrooms`	No	Fewest bathrooms.

Output Schema

Name	Required	Description
`message`	No
`results`	Yes	The stays: at most `limit` (default 10), compact rows unless `verbose: true`. taxes_included is null: the page does not state whether its totals include taxes.
`api_usage`	No	What this call cost the caller's RapidAPI plan (one request), and what remains on it.
`signup_url`	No	Where the caller subscribes or changes plan.
`result_count`	No
`results_note`	No	Present when `limit` left stays out.
`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.
`results_total`	No	Stays the source returned, before `limit`.
`search_status`	No	'ok': stays listed. 'empty': the page listed none for these dates, a real answer.
`filters_applied`	No	Each filter applied, and whether Airbnb or FlightPowers (post_filter) applied it.
`quota_exhausted`	No	True when the caller's RapidAPI plan has no requests left for the current period.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses that results come from a single page of Airbnb's search output, that guest/price/bedroom/bed/bathroom/room-type filters are applied by Airbnb while min_rating and sort are applied by FlightPowers on just that one page, that taxes_included is null because the page doesn't state it, and that prices go stale within minutes. Also carries a non-affiliation disclaimer.

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?

Three short paragraphs, front-loaded with purpose and payoff, then filter behavior, then pricing caveats. A bit of the result-field enumeration duplicates what the output schema already carries, but every paragraph delivers usable information and there is no 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 an 18-parameter, open-world search tool with an output schema, it covers the things that matter to correct invocation: freshness/staleness, the one-page limiting behavior of post-filters, cheapest-always-included paging semantics, and the tax ambiguity. Nothing an agent needs to interpret results correctly is missing.

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, but the description adds meaning the schema does not: it separates which filters are Airbnb-side versus FlightPowers-side post-filters (a critical caveat since sort/min_rating operate on only one returned page) and clarifies the default of 10 stays with the cheapest always included.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — live Airbnb stays and prices for a destination and dates — plus how the data is obtained (read from Airbnb's public search page at request time) and what each result contains. Differentiation from the hotel siblings is achieved only implicitly through the Airbnb-specific resource, no sibling is named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (use for Airbnb stays given destination and dates) and there is a genuine operational guidance sentence — rates go stale within minutes, so a current price requires a new search. However, nothing tells the agent when to pick this over search_hotels or compare_hotel_rates, and no exclusions are stated.

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.