Real-time Booking.com rates for agents. Three things people do with this server. Scan for rate gaps: price_as_seen_from prices the same room from another market, so an agent can sample a property across countries and compare. Put live search in your app: search a destination or look a property up by name, no internal IDs, room-level rates as flat JSON. Run a 24/7 AI travel agent: add the server, sign in with Google, and schedule it. No ads, no sponsored content. You bring your own RapidAPI key, so every search is billed to your plan and never to anyone else's. Add https://hotels.flightpowers.com/mcp , click Sign in, sign in with Google, and paste your RapidAPI key once on the page that opens. Scripts and clients without a sign-in button send the key as x-rapidapi-key on the same URL.
Scored across 3 tools
find_hotel_by_name is clearly distinct (single named property), but compare_hotel_rates and search_hotels overlap heavily: search_hotels already accepts a providers list to price the same stay across Booking and Airbnb, which is precisely what compare_hotel_rates does. An agent could reasonably pick either for a cross-source comparison.
All three names are snake_case verb_noun forms (compare_hotel_rates, find_hotel_by_name, search_hotels) with predictable verbs. compare_hotel_rates is a slightly longer verb_noun_noun construction, but the pattern is still readable and consistent.
Three tools is thin for a hotel search domain, and one of them (compare_hotel_rates) is largely subsumed by a mode of search_hotels, so the set feels under-scoped rather than tightly earned.
Search, single-property lookup, and cross-source price comparison are covered, but there is no way to fetch full property detail/reviews beyond what search rows return, no booking action, and no dedicated review or availability surface — workable but with noticeable gaps.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
FlightPowers single-property lookup: live Booking.com 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, latitude/longitude and a booking link. Use it to check one specific hotel, or to track a single property's price over time.
A date range and a nights value price several stays in one call, like the flights tools: pass checkin_date_from, checkin_date_to and nights (a number, or a list like [2, 3, 7]) instead of a fixed checkin_date/checkout_date, and this property is priced for every check-in date -- a rate calendar for one hotel. The answer is stays, one entry per date with that date's price and per-night rate, plus cheapest_overall. Each stay is one request billed to your plan; max_searches caps it, and a range that expands past the cap is sampled evenly across the calendar and says so in search_coverage.
price_as_seen_from prices the stay as a shopper resident in that country would see it. Gaps are real but usually modest and property-dependent, and rates move between calls, so call each country a few times on this same property before reporting a gap.
Rates go stale within minutes: never reuse an earlier result.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adult guests. | |
| nights | No | How many nights to stay, as a number (3) or a list ([2, 3, 7]) to price several lengths. Derives the check-out date from each check-in date, so it replaces checkout_date rather than joining it. | |
| children | No | Number of children sharing the room. | |
| currency | No | ISO currency code for the prices returned, e.g. "usd". | |
| hotel_name | Yes | The 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_date | No | First night of the stay, "YYYY-MM-DD". Give this with checkout_date for one stay, or use checkin_date_from plus checkin_date_to for a rate calendar. | |
| max_searches | No | The billed requests this call may make, up or down. One stay is one request; the cap rises by itself to cover a month-sized request, and anything past the cap in force is sampled evenly across the calendar rather than cut short at the front. | |
| checkout_date | No | Departure morning, "YYYY-MM-DD". Must be after checkin_date. Give either this or nights, not both. | |
| checkin_date_to | No | Last check-in date of the range, "YYYY-MM-DD". | |
| checkin_date_from | No | First check-in date of a range, "YYYY-MM-DD". Needs checkin_date_to and nights, and prices this property on every check-in date in the range -- one call, a rate calendar. | |
| price_as_seen_from | No | Two-letter country code, e.g. "de". Prices the stay as a shopper resident in that country would see it. Call each country a few times on this same property before reporting a gap, because rates move between calls and gaps are usually modest and property-dependent. |
| Name | Required | Description |
|---|---|---|
| stays | No | One entry per stay the REQUEST asked for, in request order, present whether or not that stay was priced. Only on a date-range search (checkin_date_from / checkin_date_to / nights); a single stay does not carry it. Read this rather than inferring coverage from `results`: `results` holds the full property list for the CHEAPEST stay only, so a stay missing from it looks identical to a stay that had nothing. `reason` says which kind of hole an unpriced stay is: 'no_availability' (searched, answered, nothing came back), 'no_price' (properties came back, none carried a price), 'search_failed' (the search errored, so nothing is known -- not 'no rooms') or 'not_searched' (the per-call fan-out cap sampled it away). Counts are null rather than zero on those last two, because zero reads as 'nothing there' and neither case knows that. |
| 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 | |
| partial | No | Present when some stays failed but others were priced. Plain text saying how much of the request the answer covers. |
| results | Yes | The properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'. Each row is the source's own object, passed through. latitude and longitude are the property's WGS84 coordinates in decimal degrees, from the source that answered (Booking.com on Booking rows, Airbnb on Airbnb rows), null when the source publishes none. |
| 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 | No | One entry per source that was called, in the order they were requested. Only present when `providers` named more than the default source. |
| 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. |
| search_status | No | Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help -- ask for fewer dates or nights, or move to a larger plan. |
| 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. |
| search_coverage | No | What was actually priced on a date-range search. Present whether or not the request was truncated, so a model can state honestly what its answer rests on. |
| cheapest_overall | No | The cheapest stay across everything priced, or null when nothing was. `results` holds this stay's full property list. |
| results_for_stay | No | Which stay `results` belongs to on a date-range search, or null when nothing was priced. Without it the rows read as 'the search's results' and get quoted against the wrong dates. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses per-stay billing (one request per stay, max_searches cap, even sampling with search_coverage), rate staleness ("never reuse an earlier result"), the required RapidAPI key with three accepted injection points and first-non-empty precedence, the 10-search free tier, and that api_usage reports spend. The idempotentHint=false annotation is reinforced by the explicit staleness warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause and the paragraphing follows the natural decision order (purpose, range mode, country pricing, freshness, auth). It is long and partly repetitive — the price_as_seen_from warning is duplicated verbatim from the schema, and the auth paragraph is dense — but the length is largely earned by the billing and authentication complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return fields, and it covers everything else an agent needs: auth, quota/billing, sampling behavior, freshness, and both calling modes. Nothing required to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 cross-parameter semantics the schema states only locally: that checkin_date_from/checkin_date_to/nights together produce one rate calendar, and that each expansion is billed. It also repeats the price_as_seen_from caveat already present in the schema, which slightly dilutes the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+scope: "single-property lookup: live Booking.com availability and pricing for one named property." The "one named property" / "check one specific hotel" framing cleanly separates it from the sibling search_hotels and compare_hotel_rates by scope, so an agent can route without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the two intended uses (check one specific hotel, track a single property's price over time) and explains the rate-calendar mode as an alternative calling pattern. It never names search_hotels or compare_hotel_rates as the alternative to pick when you need many properties, so the when-not guidance is implied by scope rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FlightPowers hotel search: live Booking.com 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, latitude/longitude 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, which no other travel tool here can do. Gaps are real but usually modest and property-dependent, and rates move between calls, so hold one named property fixed, call each country a few times, and never read one call per country as a gap.
A date range and a nights value price several stays in one call, like the flights tools: pass checkin_date_from, checkin_date_to and nights (a number, or a list like [2, 3, 7]) instead of a fixed checkin_date/checkout_date, and every check-in date is priced separately. The answer is stays -- one entry per stay with its cheapest property, per-night price and median -- plus cheapest_overall, and the full property list for the cheapest stay only. Each stay is one request billed to your plan; max_searches caps it, and a request that expands past the cap is sampled evenly across the range and says so in search_coverage.
Set providers to price the same stay on more than one source in one call: ["booking"] (the default), ["airbnb"], or both. Booking rows rate out of 10 and Airbnb rows out of 5, so read rating_scale on every row before comparing two of them. A source you have no RapidAPI key for is not called and is named in providers_skipped with a subscribe link, never quietly dropped.
Rates go stale within minutes: never reuse an earlier result, search 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.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adult guests. Defaults to the upstream default when omitted. | |
| nights | No | How many nights to stay, as a number (3) or a list ([2, 3, 7]) to price several lengths. Derives the check-out date from each check-in date, so it replaces checkout_date rather than joining it. | |
| 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". | |
| providers | No | Which sources to price this stay on, e.g. ["booking"], ["airbnb"] or ["booking", "airbnb"]. Defaults to ["booking"]. Each source is a separate RapidAPI subscription, so a source you have no key for is not called; it comes back named in providers_skipped with the reason and where to subscribe, rather than silently missing. filters and price_as_seen_from apply to booking only; airbnb takes price_min, price_max and room_types instead, and rows from it carry rating_scale 5 where booking's carry 10. | |
| 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 | No | First night of the stay, "YYYY-MM-DD". Give this with checkout_date for one stay, or use checkin_date_from plus checkin_date_to for a range of check-in dates. | |
| max_searches | No | The billed requests this call may make, up or down. One stay is one request, so a 30-day range at two lengths is 60 and a month at three is 93 -- the cap rises to cover a request that size by itself. Set it lower to spend less, or higher (hard maximum 200) for a wider grid; either way the range is sampled evenly across the calendar rather than cut short at the front. | |
| checkout_date | No | Departure morning, "YYYY-MM-DD". Must be after checkin_date. Give either this or nights, not both. | |
| checkin_date_to | No | Last check-in date of the range, "YYYY-MM-DD". | |
| budget_per_night | No | Only return properties at or below this nightly price, in `currency`. | |
| checkin_date_from | No | First check-in date of a range, "YYYY-MM-DD". Needs checkin_date_to and nights, and prices one stay per check-in date in the range -- the hotel equivalent of the flights date range. | |
| 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. For a rate-parity check hold one named property fixed and call each country a few times, because rates move between calls and one call per country can show a gap that is not there. Omit it for a neutral price. |
| Name | Required | Description |
|---|---|---|
| stays | No | One entry per stay the REQUEST asked for, in request order, present whether or not that stay was priced. Only on a date-range search (checkin_date_from / checkin_date_to / nights); a single stay does not carry it. Read this rather than inferring coverage from `results`: `results` holds the full property list for the CHEAPEST stay only, so a stay missing from it looks identical to a stay that had nothing. `reason` says which kind of hole an unpriced stay is: 'no_availability' (searched, answered, nothing came back), 'no_price' (properties came back, none carried a price), 'search_failed' (the search errored, so nothing is known -- not 'no rooms') or 'not_searched' (the per-call fan-out cap sampled it away). Counts are null rather than zero on those last two, because zero reads as 'nothing there' and neither case knows that. |
| 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 | |
| partial | No | Present when some stays failed but others were priced. Plain text saying how much of the request the answer covers. |
| results | Yes | The properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'. Each row is the source's own object, passed through. latitude and longitude are the property's WGS84 coordinates in decimal degrees, from the source that answered (Booking.com on Booking rows, Airbnb on Airbnb rows), null when the source publishes none. |
| 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 | No | One entry per source that was called, in the order they were requested. Only present when `providers` named more than the default source. |
| 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. |
| search_status | No | Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help -- ask for fewer dates or nights, or move to a larger plan. |
| 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. |
| search_coverage | No | What was actually priced on a date-range search. Present whether or not the request was truncated, so a model can state honestly what its answer rests on. |
| cheapest_overall | No | The cheapest stay across everything priced, or null when nothing was. `results` holds this stay's full property list. |
| results_for_stay | No | Which stay `results` belongs to on a date-range search, or null when nothing was priced. Without it the rows read as 'the search's results' and get quoted against the wrong dates. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, openWorldHint, idempotentHint=false, destructiveHint=false), and the description layers on substantial extra context: per-stay billing, that each stay is one billed request, max_searches caps and even sampling with search_coverage disclosure, providers_skipped with a subscribe link, rating_scale differences, and the caller's own RapidAPI key plus free-tier fallback. This is well beyond what the annotations already declare.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is long, but front-loaded with purpose and inputs/outputs, and each subsequent paragraph carries a distinct caveat (pricing origin, billing, providers, staleness, auth). A few passages repeat the schema verbatim, which is the only real waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained here, and the description still covers the parts an agent cannot get from structured fields: billing model, coverage sampling, provider skipping, rating-scale normalization, credential requirements, and staleness. Nothing material about invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 genuinely adds semantics the schema does not: why nights replaces rather than joins checkout_date, why price_as_seen_from can show phantom gaps, and that booking vs airbnb rows carry different rating scales and take different filters. Some paragraphs simply restate schema text, keeping it out of the top band.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (hotel search with live Booking.com availability and nightly prices), plus the exact inputs and outputs. It never names the sibling tools compare_hotel_rates or find_hotel_by_name, so an agent must infer the boundary from context rather than being told which tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong operational guidance: how to price a range versus a fixed stay, when to set providers, how to use price_as_seen_from for rate-parity checks (hold one property fixed, call a few times, never read one call per country as a gap), and to never reuse stale results. It stops short of explicit when-to-use-this-vs-siblings routing, which matters given two hotel siblings exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_hotel_by_name2 fields changedOutput schema / properties / results / descriptionPrevious value: -"The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'."New value: +"The properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'. Each row is the source's own object, passed through. latitude and longitude are the property's WGS84 coordinates in decimal degrees, from the source that answered (Booking.com on Booking rows, Airbnb on Airbnb rows), null when the source publishes none."Output schema / properties / results / items / propertiesAdded value: +{
+ "latitude": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "longitude": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+}search_hotels2 fields changedOutput schema / properties / results / descriptionPrevious value: -"The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'."New value: +"The properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'. Each row is the source's own object, passed through. latitude and longitude are the property's WGS84 coordinates in decimal degrees, from the source that answered (Booking.com on Booking rows, Airbnb on Airbnb rows), null when the source publishes none."Output schema / properties / results / items / propertiesAdded value: +{
+ "latitude": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "longitude": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+}compare_hotel_rates2 fields changedOutput schema / properties / api_usage / properties / hub_requests_billedAdded 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"
+}Output schema / properties / api_usage / properties / requests_used_by_this_call / descriptionAdded value: +"How many date/destination combinations were searched -- what the answer COVERS."find_hotel_by_name6 fields changedInput schema / properties / max_searches / descriptionPrevious value: -"Cap the billed requests this call may make. One stay is one request; lower it and the range is sampled evenly across the calendar rather than cut short at the front."New value: +"The billed requests this call may make, up or down. One stay is one request; the cap rises by itself to cover a month-sized request, and anything past the cap in force is sampled evenly across the calendar rather than cut short at the front."Output schema / properties / api_usage / properties / hub_requests_billedAdded 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"
+}Output schema / properties / api_usage / properties / requests_used_by_this_call / descriptionAdded value: +"How many date/destination combinations were searched -- what the answer COVERS."Output schema / properties / search_coverage / properties / stopped_earlyAdded value: +{
+ "description": "Present when something other than the cap ended the fan-out. 'deadline': the call reached its time limit and the remaining combinations were never sent or billed, so the results are real but do not cover the whole range.",
+ "type": "string"
+}Output schema / properties / search_status / descriptionPrevious value: -"Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help."New value: +"Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help -- ask for fewer dates or nights, or move to a larger plan."Output schema / properties / search_status / enumPrevious value: -[
- "ok",
- "empty",
- "partial",
- "degraded",
- "trial_exhausted"
-]New value: +[
+ "ok",
+ "empty",
+ "partial",
+ "degraded",
+ "trial_exhausted",
+ "quota_exceeded"
+]search_hotels6 fields changedInput schema / properties / max_searches / descriptionPrevious value: -"Cap the billed requests this call may make. One stay is one request, so a 30-day range at two lengths is 60; lower this to spend less and the range is sampled evenly across the calendar rather than cut short at the front."New value: +"The billed requests this call may make, up or down. One stay is one request, so a 30-day range at two lengths is 60 and a month at three is 93 -- the cap rises to cover a request that size by itself. Set it lower to spend less, or higher (hard maximum 200) for a wider grid; either way the range is sampled evenly across the calendar rather than cut short at the front."Output schema / properties / api_usage / properties / hub_requests_billedAdded 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"
+}Output schema / properties / api_usage / properties / requests_used_by_this_call / descriptionAdded value: +"How many date/destination combinations were searched -- what the answer COVERS."Output schema / properties / search_coverage / properties / stopped_earlyAdded value: +{
+ "description": "Present when something other than the cap ended the fan-out. 'deadline': the call reached its time limit and the remaining combinations were never sent or billed, so the results are real but do not cover the whole range.",
+ "type": "string"
+}Output schema / properties / search_status / descriptionPrevious value: -"Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help."New value: +"Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help. 'quota_exceeded': the search was refused because the caller's remaining allowance or plan quota cannot cover the number of combinations asked for; combos_requested and combos_allowed_now carry the two numbers. Nothing was searched beyond what it cost to read the quota. Retrying the same search does not help -- ask for fewer dates or nights, or move to a larger plan."Output schema / properties / search_status / enumPrevious value: -[
- "ok",
- "empty",
- "partial",
- "degraded",
- "trial_exhausted"
-]New value: +[
+ "ok",
+ "empty",
+ "partial",
+ "degraded",
+ "trial_exhausted",
+ "quota_exceeded"
+]find_hotel_by_name2 fields changedOutput schema / properties / search_status / descriptionPrevious value: -"Date-range searches only. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry."New value: +"Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help."Output schema / properties / search_status / enumPrevious value: -[
- "ok",
- "empty",
- "partial",
- "degraded"
-]New value: +[
+ "ok",
+ "empty",
+ "partial",
+ "degraded",
+ "trial_exhausted"
+]search_hotels2 fields changedOutput schema / properties / search_status / descriptionPrevious value: -"Date-range searches only. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry."New value: +"Date-range searches only, except 'trial_exhausted'. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry. 'trial_exhausted': the free signed-in allowance on this server is spent for today, so nothing was searched and nothing was billed; it renews at 00:00 UTC and connecting your own RapidAPI key removes the cap. Retrying does not help."Output schema / properties / search_status / enumPrevious value: -[
- "ok",
- "empty",
- "partial",
- "degraded"
-]New value: +[
+ "ok",
+ "empty",
+ "partial",
+ "degraded",
+ "trial_exhausted"
+]compare_hotel_ratesfind_hotel_by_name23 fields changedInput schema / properties / checkin_date / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / checkin_date / defaultAdded value: +nullInput schema / properties / checkin_date / descriptionPrevious value: -"First night of the stay, \"YYYY-MM-DD\"."New value: +"First night of the stay, \"YYYY-MM-DD\". Give this with checkout_date for one stay, or use checkin_date_from plus checkin_date_to for a rate calendar."Input schema / properties / checkin_date / typeRemoved value: -"string"Input schema / properties / checkin_date_fromAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "First check-in date of a range, \"YYYY-MM-DD\". Needs checkin_date_to and nights, and prices this property on every check-in date in the range -- one call, a rate calendar."
+}Input schema / properties / checkin_date_toAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Last check-in date of the range, \"YYYY-MM-DD\"."
+}Input schema / properties / checkout_date / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / checkout_date / defaultAdded value: +nullInput schema / properties / checkout_date / descriptionPrevious value: -"Departure morning, \"YYYY-MM-DD\". Must be after checkin_date."New value: +"Departure morning, \"YYYY-MM-DD\". Must be after checkin_date. Give either this or nights, not both."Input schema / properties / checkout_date / typeRemoved value: -"string"Input schema / properties / max_searchesAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Cap the billed requests this call may make. One stay is one request; lower it and the range is sampled evenly across the calendar rather than cut short at the front."
+}Input schema / properties / nightsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "How many nights to stay, as a number (3) or a list ([2, 3, 7]) to price several lengths. Derives the check-out date from each check-in date, so it replaces checkout_date rather than joining it."
+}Input schema / requiredPrevious value: -[
- "hotel_name",
- "checkin_date",
- "checkout_date"
-]New value: +[
+ "hotel_name"
+]Output schema / descriptionPrevious value: -"A completed hotel search. The hotels upstream reports no search-status header, so these results carry no search_status field."New value: +"A completed hotel search. A single stay carries no search_status: the hotels upstream reports no search-status header, and one call either answered or raised. A DATE-RANGE search does carry one, derived from the fan-out rather than from the upstream -- some of its stays can fail while others answer, and `results` then holds only the cheapest stay's properties, so `stays` is where the shape of the answer lives."Output schema / properties / caveatsAdded value: +{
+ "description": "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.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / cheapest_overallAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "checkin_date": {
+ "type": "string"
+ },
+ "checkout_date": {
+ "type": "string"
+ },
+ "currency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "nights": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "price_per_night": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "property": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The cheapest priced property for this stay, or null when it has none. The same row the upstream returned, minus its image URL: on a measured search 73% of the payload was URLs, and an image CDN link is the half no model can open. The booking link is kept."
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The cheapest stay across everything priced, or null when nothing was. `results` holds this stay's full property list."
+}Output schema / properties / partialAdded value: +{
+ "description": "Present when some stays failed but others were priced. Plain text saying how much of the request the answer covers.",
+ "type": "string"
+}Output schema / properties / providersAdded value: +{
+ "description": "One entry per source that was called, in the order they were requested. Only present when `providers` named more than the default source.",
+ "items": {
+ "additionalProperties": true,
+ "description": "What one accommodation source answered. Present for every source that was CALLED, whether or not it answered: a source with search_status 'degraded' carries a reason, a null count and no prices, which is not the same answer as a source that found nothing.",
+ "properties": {
+ "cheapest_link": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cheapest_name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cheapest_total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "count": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How many properties from this source carried a price. Null when the source did not answer -- zero would read as 'nothing there', which a failed search does not know."
+ },
+ "currency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The currency THIS row's totals are in. Rows in different currencies are not comparable and nothing is converted."
+ },
+ "detail": {
+ "description": "Plain text for the model to relay to a human.",
+ "type": "string"
+ },
+ "median_total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "provider": {
+ "description": "Which source this row is about, e.g. 'booking'.",
+ "type": "string"
+ },
+ "rating_scale": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "What a review score from this source is out of: 10 on Booking, 5 on Airbnb. Read it before comparing two scores."
+ },
+ "retrieved_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "When these rows were read, taken from the rows themselves rather than from when this answer was assembled."
+ },
+ "search_reason": {
+ "type": "string"
+ },
+ "search_status": {
+ "description": "'ok': the source answered with priced results. 'empty': it answered and had nothing for that stay -- a real answer. 'degraded': it was asked and could not answer, so count is null and an empty list from it means nothing.",
+ "enum": [
+ "ok",
+ "empty",
+ "degraded",
+ "skipped"
+ ],
+ "type": "string"
+ },
+ "taxes_included": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Whether this source's totals include tax. Null means it has not been established for that source, not that tax is excluded."
+ },
+ "top": {
+ "description": "The cheapest few priced rows from this source.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "provider",
+ "search_status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / providers_skippedAdded value: +{
+ "description": "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.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "detail": {
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "reason": {
+ "description": "'no_key': no RapidAPI key for that source's listing arrived with the call. 'not_subscribed': the key supplied is not subscribed to that listing. 'key_rejected': the key was refused outright.",
+ "type": "string"
+ },
+ "subscribe_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "provider",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / results_for_stayAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Which stay `results` belongs to on a date-range search, or null when nothing was priced. Without it the rows read as 'the search's results' and get quoted against the wrong dates."
+}Output schema / properties / search_coverageAdded value: +{
+ "additionalProperties": true,
+ "description": "What was actually priced on a date-range search. Present whether or not the request was truncated, so a model can state honestly what its answer rests on.",
+ "properties": {
+ "checkin_dates_searched": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "max_searches_per_request": {
+ "minimum": 1,
+ "type": "integer"
+ },
+ "note": {
+ "type": "string"
+ },
+ "requested_combinations": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "searched_combinations": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "stays_searched": {
+ "description": "The exact date pairs priced.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "checkin_date": {
+ "type": "string"
+ },
+ "checkout_date": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "truncated": {
+ "description": "True when the request expanded past this call's spend ceiling and was sampled. A stay absent from stays_searched was never priced, which is not the same as having no rooms.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Output schema / properties / search_statusAdded value: +{
+ "description": "Date-range searches only. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry.",
+ "enum": [
+ "ok",
+ "empty",
+ "partial",
+ "degraded"
+ ],
+ "type": "string"
+}Output schema / properties / staysAdded value: +{
+ "description": "One entry per stay the REQUEST asked for, in request order, present whether or not that stay was priced. Only on a date-range search (checkin_date_from / checkin_date_to / nights); a single stay does not carry it.\n\nRead this rather than inferring coverage from `results`: `results` holds the full property list for the CHEAPEST stay only, so a stay missing from it looks identical to a stay that had nothing. `reason` says which kind of hole an unpriced stay is: 'no_availability' (searched, answered, nothing came back), 'no_price' (properties came back, none carried a price), 'search_failed' (the search errored, so nothing is known -- not 'no rooms') or 'not_searched' (the per-call fan-out cap sampled it away). Counts are null rather than zero on those last two, because zero reads as 'nothing there' and neither case knows that.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "cheapest": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The cheapest priced property for this stay, or null when it has none. The same row the upstream returned, minus its image URL: on a measured search 73% of the payload was URLs, and an image CDN link is the half no model can open. The booking link is kept."
+ },
+ "cheapest_total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "checkin_date": {
+ "type": "string"
+ },
+ "checkout_date": {
+ "type": "string"
+ },
+ "currency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "median_total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Median stay total over this stay's priced properties -- what the date costs generally, next to what its one cheapest room costs."
+ },
+ "nights": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "price_per_night": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "cheapest_total divided by nights, rounded."
+ },
+ "priced_count": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How many of those carried a price. The others are not evidence about what the stay costs."
+ },
+ "property_count": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Properties returned for this stay. Null when it was not searched or its search errored."
+ },
+ "reason": {
+ "enum": [
+ "ok",
+ "no_availability",
+ "no_price",
+ "search_failed",
+ "not_searched"
+ ],
+ "type": "string"
+ },
+ "search_status": {
+ "enum": [
+ "ok",
+ "empty",
+ "degraded",
+ "not_searched"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "checkin_date",
+ "checkout_date",
+ "search_status",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}search_hotels24 fields changedInput schema / properties / checkin_date / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / checkin_date / defaultAdded value: +nullInput schema / properties / checkin_date / descriptionPrevious value: -"First night of the stay, \"YYYY-MM-DD\"."New value: +"First night of the stay, \"YYYY-MM-DD\". Give this with checkout_date for one stay, or use checkin_date_from plus checkin_date_to for a range of check-in dates."Input schema / properties / checkin_date / typeRemoved value: -"string"Input schema / properties / checkin_date_fromAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "First check-in date of a range, \"YYYY-MM-DD\". Needs checkin_date_to and nights, and prices one stay per check-in date in the range -- the hotel equivalent of the flights date range."
+}Input schema / properties / checkin_date_toAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Last check-in date of the range, \"YYYY-MM-DD\"."
+}Input schema / properties / checkout_date / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / checkout_date / defaultAdded value: +nullInput schema / properties / checkout_date / descriptionPrevious value: -"Departure morning, \"YYYY-MM-DD\". Must be after checkin_date."New value: +"Departure morning, \"YYYY-MM-DD\". Must be after checkin_date. Give either this or nights, not both."Input schema / properties / checkout_date / typeRemoved value: -"string"Input schema / properties / max_searchesAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Cap the billed requests this call may make. One stay is one request, so a 30-day range at two lengths is 60; lower this to spend less and the range is sampled evenly across the calendar rather than cut short at the front."
+}Input schema / properties / nightsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "How many nights to stay, as a number (3) or a list ([2, 3, 7]) to price several lengths. Derives the check-out date from each check-in date, so it replaces checkout_date rather than joining it."
+}Input schema / properties / providersAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Which sources to price this stay on, e.g. [\"booking\"], [\"airbnb\"] or [\"booking\", \"airbnb\"]. Defaults to [\"booking\"]. Each source is a separate RapidAPI subscription, so a source you have no key for is not called; it comes back named in providers_skipped with the reason and where to subscribe, rather than silently missing. filters and price_as_seen_from apply to booking only; airbnb takes price_min, price_max and room_types instead, and rows from it carry rating_scale 5 where booking's carry 10."
+}Input schema / requiredPrevious value: -[
- "destination",
- "checkin_date",
- "checkout_date"
-]New value: +[
+ "destination"
+]Output schema / descriptionPrevious value: -"A completed hotel search. The hotels upstream reports no search-status header, so these results carry no search_status field."New value: +"A completed hotel search. A single stay carries no search_status: the hotels upstream reports no search-status header, and one call either answered or raised. A DATE-RANGE search does carry one, derived from the fan-out rather than from the upstream -- some of its stays can fail while others answer, and `results` then holds only the cheapest stay's properties, so `stays` is where the shape of the answer lives."Output schema / properties / caveatsAdded value: +{
+ "description": "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.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / cheapest_overallAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "checkin_date": {
+ "type": "string"
+ },
+ "checkout_date": {
+ "type": "string"
+ },
+ "currency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "nights": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "price_per_night": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "property": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The cheapest priced property for this stay, or null when it has none. The same row the upstream returned, minus its image URL: on a measured search 73% of the payload was URLs, and an image CDN link is the half no model can open. The booking link is kept."
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The cheapest stay across everything priced, or null when nothing was. `results` holds this stay's full property list."
+}Output schema / properties / partialAdded value: +{
+ "description": "Present when some stays failed but others were priced. Plain text saying how much of the request the answer covers.",
+ "type": "string"
+}Output schema / properties / providersAdded value: +{
+ "description": "One entry per source that was called, in the order they were requested. Only present when `providers` named more than the default source.",
+ "items": {
+ "additionalProperties": true,
+ "description": "What one accommodation source answered. Present for every source that was CALLED, whether or not it answered: a source with search_status 'degraded' carries a reason, a null count and no prices, which is not the same answer as a source that found nothing.",
+ "properties": {
+ "cheapest_link": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cheapest_name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cheapest_total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "count": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How many properties from this source carried a price. Null when the source did not answer -- zero would read as 'nothing there', which a failed search does not know."
+ },
+ "currency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The currency THIS row's totals are in. Rows in different currencies are not comparable and nothing is converted."
+ },
+ "detail": {
+ "description": "Plain text for the model to relay to a human.",
+ "type": "string"
+ },
+ "median_total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "provider": {
+ "description": "Which source this row is about, e.g. 'booking'.",
+ "type": "string"
+ },
+ "rating_scale": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "What a review score from this source is out of: 10 on Booking, 5 on Airbnb. Read it before comparing two scores."
+ },
+ "retrieved_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "When these rows were read, taken from the rows themselves rather than from when this answer was assembled."
+ },
+ "search_reason": {
+ "type": "string"
+ },
+ "search_status": {
+ "description": "'ok': the source answered with priced results. 'empty': it answered and had nothing for that stay -- a real answer. 'degraded': it was asked and could not answer, so count is null and an empty list from it means nothing.",
+ "enum": [
+ "ok",
+ "empty",
+ "degraded",
+ "skipped"
+ ],
+ "type": "string"
+ },
+ "taxes_included": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Whether this source's totals include tax. Null means it has not been established for that source, not that tax is excluded."
+ },
+ "top": {
+ "description": "The cheapest few priced rows from this source.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "provider",
+ "search_status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / providers_skippedAdded value: +{
+ "description": "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.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "detail": {
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "reason": {
+ "description": "'no_key': no RapidAPI key for that source's listing arrived with the call. 'not_subscribed': the key supplied is not subscribed to that listing. 'key_rejected': the key was refused outright.",
+ "type": "string"
+ },
+ "subscribe_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "provider",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / results_for_stayAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Which stay `results` belongs to on a date-range search, or null when nothing was priced. Without it the rows read as 'the search's results' and get quoted against the wrong dates."
+}Output schema / properties / search_coverageAdded value: +{
+ "additionalProperties": true,
+ "description": "What was actually priced on a date-range search. Present whether or not the request was truncated, so a model can state honestly what its answer rests on.",
+ "properties": {
+ "checkin_dates_searched": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "max_searches_per_request": {
+ "minimum": 1,
+ "type": "integer"
+ },
+ "note": {
+ "type": "string"
+ },
+ "requested_combinations": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "searched_combinations": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "stays_searched": {
+ "description": "The exact date pairs priced.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "checkin_date": {
+ "type": "string"
+ },
+ "checkout_date": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "truncated": {
+ "description": "True when the request expanded past this call's spend ceiling and was sampled. A stay absent from stays_searched was never priced, which is not the same as having no rooms.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Output schema / properties / search_statusAdded value: +{
+ "description": "Date-range searches only. 'ok': every stay searched was priced. 'empty': they all answered and none had priced availability -- a real answer. 'partial': some stays were priced and some errored. 'degraded': every stay errored, so nothing is known; safe to retry.",
+ "enum": [
+ "ok",
+ "empty",
+ "partial",
+ "degraded"
+ ],
+ "type": "string"
+}Output schema / properties / staysAdded value: +{
+ "description": "One entry per stay the REQUEST asked for, in request order, present whether or not that stay was priced. Only on a date-range search (checkin_date_from / checkin_date_to / nights); a single stay does not carry it.\n\nRead this rather than inferring coverage from `results`: `results` holds the full property list for the CHEAPEST stay only, so a stay missing from it looks identical to a stay that had nothing. `reason` says which kind of hole an unpriced stay is: 'no_availability' (searched, answered, nothing came back), 'no_price' (properties came back, none carried a price), 'search_failed' (the search errored, so nothing is known -- not 'no rooms') or 'not_searched' (the per-call fan-out cap sampled it away). Counts are null rather than zero on those last two, because zero reads as 'nothing there' and neither case knows that.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "cheapest": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The cheapest priced property for this stay, or null when it has none. The same row the upstream returned, minus its image URL: on a measured search 73% of the payload was URLs, and an image CDN link is the half no model can open. The booking link is kept."
+ },
+ "cheapest_total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "checkin_date": {
+ "type": "string"
+ },
+ "checkout_date": {
+ "type": "string"
+ },
+ "currency": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "median_total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Median stay total over this stay's priced properties -- what the date costs generally, next to what its one cheapest room costs."
+ },
+ "nights": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "price_per_night": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "cheapest_total divided by nights, rounded."
+ },
+ "priced_count": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How many of those carried a price. The others are not evidence about what the stay costs."
+ },
+ "property_count": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Properties returned for this stay. Null when it was not searched or its search errored."
+ },
+ "reason": {
+ "enum": [
+ "ok",
+ "no_availability",
+ "no_price",
+ "search_failed",
+ "not_searched"
+ ],
+ "type": "string"
+ },
+ "search_status": {
+ "enum": [
+ "ok",
+ "empty",
+ "degraded",
+ "not_searched"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "checkin_date",
+ "checkout_date",
+ "search_status",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}find_hotel_by_name1 field changedInput schema / properties / price_as_seen_from / descriptionPrevious value: -"Two-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."New value: +"Two-letter country code, e.g. \"de\". Prices the stay as a shopper resident in that country would see it. Call each country a few times on this same property before reporting a gap, because rates move between calls and gaps are usually modest and property-dependent."search_hotels1 field changedInput schema / properties / price_as_seen_from / descriptionPrevious value: -"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."New value: +"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. For a rate-parity check hold one named property fixed and call each country a few times, because rates move between calls and one call per country can show a gap that is not there. Omit it for a neutral price."find_hotel_by_name4 fields changedOutput schema / descriptionAdded value: +"A completed hotel search. The hotels upstream reports no search-status header, so these results carry no search_status field."Output schema / propertiesAdded value: +{
+ "api_usage": {
+ "additionalProperties": true,
+ "description": "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.",
+ "properties": {
+ "note": {
+ "description": "The same figures as a sentence, for the model to relay.",
+ "type": "string"
+ },
+ "plan_requests_limit": {
+ "type": "integer"
+ },
+ "plan_requests_remaining": {
+ "type": "integer"
+ },
+ "requests_used_by_this_call": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "applied_filters": {
+ "description": "Which of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through."
+ },
+ "message": {
+ "type": "string"
+ },
+ "needs_api_key": {
+ "description": "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.",
+ "type": "boolean"
+ },
+ "quota_exhausted": {
+ "description": "True when the caller's RapidAPI plan has no requests left for the current period.",
+ "type": "boolean"
+ },
+ "result_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "results": {
+ "description": "The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "signup_url": {
+ "description": "Where the caller subscribes or changes plan.",
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "results"
+]Output schema / titleAdded value: +"Hotel search result"search_hotels4 fields changedOutput schema / descriptionAdded value: +"A completed hotel search. The hotels upstream reports no search-status header, so these results carry no search_status field."Output schema / propertiesAdded value: +{
+ "api_usage": {
+ "additionalProperties": true,
+ "description": "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.",
+ "properties": {
+ "note": {
+ "description": "The same figures as a sentence, for the model to relay.",
+ "type": "string"
+ },
+ "plan_requests_limit": {
+ "type": "integer"
+ },
+ "plan_requests_remaining": {
+ "type": "integer"
+ },
+ "requests_used_by_this_call": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "applied_filters": {
+ "description": "Which of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through."
+ },
+ "message": {
+ "type": "string"
+ },
+ "needs_api_key": {
+ "description": "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.",
+ "type": "boolean"
+ },
+ "quota_exhausted": {
+ "description": "True when the caller's RapidAPI plan has no requests left for the current period.",
+ "type": "boolean"
+ },
+ "result_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "results": {
+ "description": "The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "signup_url": {
+ "description": "Where the caller subscribes or changes plan.",
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "results"
+]Output schema / titleAdded value: +"Hotel search result"find_hotel_by_name7 fields changedInput schema / properties / adults / descriptionAdded value: +"Number of adult guests."Input schema / properties / checkin_date / descriptionAdded value: +"First night of the stay, \"YYYY-MM-DD\"."Input schema / properties / checkout_date / descriptionAdded value: +"Departure morning, \"YYYY-MM-DD\". Must be after checkin_date."Input schema / properties / children / descriptionAdded value: +"Number of children sharing the room."Input schema / properties / currency / descriptionAdded value: +"ISO currency code for the prices returned, e.g. \"usd\"."Input schema / properties / hotel_name / descriptionAdded value: +"The 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."Input schema / properties / price_as_seen_from / descriptionAdded value: +"Two-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."search_hotels9 fields changedInput schema / properties / adults / descriptionAdded value: +"Number of adult guests. Defaults to the upstream default when omitted."Input schema / properties / budget_per_night / descriptionAdded value: +"Only return properties at or below this nightly price, in `currency`."Input schema / properties / checkin_date / descriptionAdded value: +"First night of the stay, \"YYYY-MM-DD\"."Input schema / properties / checkout_date / descriptionAdded value: +"Departure morning, \"YYYY-MM-DD\". Must be after checkin_date."Input schema / properties / children / descriptionAdded value: +"Number of children sharing the room."Input schema / properties / currency / descriptionAdded value: +"ISO currency code for the prices returned, e.g. \"usd\"."Input schema / properties / destination / descriptionAdded value: +"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."Input schema / properties / filters / descriptionAdded value: +"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."Input schema / properties / price_as_seen_from / descriptionAdded value: +"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."find_hotel_by_namesearch_hotelsReal-time Google Flights fares for agents. Three things people do with this server. Scan for deals: one call takes a date range and a list of destination airports, expands every combination server side, and returns each fare with Google's own low, typical or high verdict. Put live search in your app: flat JSON with a bookable link on every result, and round trips priced as paired legs. Run a 24/7 AI travel agent: add the server, sign in with Google, and schedule it. No ads, no sponsored content. You bring your own RapidAPI key, so every search is billed to your plan and never to anyone else's. Add https://flights.flightpowers.com/mcp , click Sign in, sign in with Google, and paste your RapidAPI key once on the page that opens. Scripts and clients without a sign-in button send the key as x-rapidapi-key on the same URL.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Official MCP server for MAQAMI, a hotel and flight booking platform with 3M+ hotels. Search live hotel rates and flights, look up places, airports and hotel details, then prebook and book. Remote Streamable HTTP endpoint, no API key required.
Booking.com stays by destination and dates, and full property details, as structured JSON.
Add one secure layer between your agents and this server.
