Booking.com Hotel Search (Live Prices)
REMOTE · HOTELS.FLIGHTPOWERS.COM
Live Booking.com hotel prices, plus per-country pricing for rate-parity monitoring.
Available components
Last scanned (3 hours ago)
Scores higher than 99% of remote servers
Reachable. Last reached 17 Oct 2026.
Category E-commerce
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security97
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability54
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 3772 tokens (~1257/item across 3 items; 3 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 3 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 4 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 23 Sept 26 0
- “search_hotels” reworded the description of “max_searches” cosmetic
- “find_hotel_by_name” reworded the description of “max_searches” cosmetic
2 cosmetic changes on this day. Switch on “Show cosmetic changes” to see them.
- 17 Sept 26 0
- Stability: 0.97 → pass security
- The server rewrote its instructions, which are the text every model session reads security
- Tool “compare_hotel_rates” rewrote its description, which is the text the model reads security
- Tool “find_hotel_by_name” rewrote its description, which is the text the model reads security
- Tool “search_hotels” rewrote its description, which is the text the model reads security
- 15 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “search_hotels” rewrote its description, which is the text the model reads security
- Tool “find_hotel_by_name” rewrote its description, which is the text the model reads security
- Schema quality: 821 → 1172 ▼ functional
- New tool “compare_hotel_rates” functional
- “find_hotel_by_name” added an optional parameter “nights” cosmetic
- “search_hotels” added an optional parameter “checkin_date_to” cosmetic
- “search_hotels” added an optional parameter “max_searches” cosmetic
- “search_hotels” added an optional parameter “nights” cosmetic
- “search_hotels” added an optional parameter “providers” cosmetic
- “search_hotels” added an optional parameter “checkin_date_from” cosmetic
- “find_hotel_by_name” added an optional parameter “checkin_date_from” cosmetic
- “find_hotel_by_name” added an optional parameter “checkin_date_to” cosmetic
- “find_hotel_by_name” added an optional parameter “max_searches” cosmetic
- “search_hotels” reworded the description of “checkin_date” cosmetic
- “search_hotels” reworded the description of “checkout_date” cosmetic
- “find_hotel_by_name” reworded the description of “checkin_date” cosmetic
- “find_hotel_by_name” reworded the description of “checkout_date” cosmetic
- “search_hotels” made “checkin_date” optional cosmetic
- “search_hotels” made “checkout_date” optional cosmetic
- “find_hotel_by_name” made “checkin_date” optional cosmetic
- “find_hotel_by_name” made “checkout_date” optional cosmetic
- 10 Sept 26 0
- Transport: unverified → pass ▲ security
- Injection markers: unverified → pass ▲ security
- Authorization: Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. security
- Endpoint reachability: behind authorisation → reachable ▲ functional
- MCP protocol: unverified → pass ▲ functional
- Stability: unverified → 0.77 ▲ functional
- Tool coverage: unverified → 100 ▲ functional
- 9 Sept 26 0
- Endpoint reachability: reachable → behind authorisation ▼ security
- Tool safety: pass → unverified ▼ security
- Stability: 0.70 → unverified ▼ security
- Transport: pass → unverified ▼ security
- Authorization: partial → pass ▲ security
- First check of Authorization: pass security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 17 Oct 2026 · Probed https://hotels.flightpowers.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=hotels.flightpowers.com | CN=YR2,O=Let's Encrypt,C=US | 18 Aug 2026 | 16 Nov 2026 | RSA 2048 | SHA256-RSA | 6ff8f1f22411d134b16efad8920fadd79cc |
| SANs: hotels.flightpowers.com | ||||||
| CN=YR2,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | 4ebd24947e24d394802d84a52fd5b319 |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of hotels.flightpowers.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| flightpowers.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://hotels.flightpowers.com/.well-known/oauth-protected-resource/mcp"
Bearer resource_metadata="https://hotels.flightpowers.com/.well-known/oauth-protected-resource/mcp"| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000 |
Protected resource metadata
| Document | https://hotels.flightpowers.com/.well-known/oauth-protected-resource/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://hotels.flightpowers.com/mcp |
| Authorisation server | https://hotels.flightpowers.com |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://hotels.flightpowers.com/mcp | Verified | 200 | |
| http (plaintext) | http://hotels.flightpowers.com/mcp | HTTPS enforced | 308 | https://hotels.flightpowers.com/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
compare_hotel_rates FlightPowers: compare hotel rates across sources ~573
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 | Type | Req | Description |
|---|---|---|---|
| adults | – | – | Number of adult guests. Defaults to the upstream default when omitted. |
| checkin_date | string | yes | First night of the stay, "YYYY-MM-DD". |
| checkout_date | string | yes | Departure morning, "YYYY-MM-DD". Must be after checkin_date. |
| children | – | – | Number of children sharing the room. |
| currency | – | – | 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… |
| destination | string | 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. |
| providers | – | – | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| adults | – | – | – |
| api_usage | object | – | 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. |
| caveats | array | – | 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. |
| checkin_date | string | – | – |
| checkout_date | string | – | – |
| children | – | – | – |
| currency | – | – | The currency every source was ASKED for. |
| destination | string | – | – |
| message | string | – | – |
| needs_api_key | boolean | – | 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. |
| nights | – | – | Nights between the two dates, or null when the dates could not be read as dates. |
| providers | array | yes | – |
| providers_skipped | array | – | 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 miss… |
| quota_exhausted | boolean | – | True when the caller's RapidAPI plan has no requests left for the current period. |
| signup_url | string | – | Where the caller subscribes or changes plan. |
No examples provided.
find_hotel_by_name FlightPowers: find one hotel by name ~865
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 http…
| Name | Type | Req | Description |
|---|---|---|---|
| adults | – | – | Number of adult guests. |
| checkin_date | – | – | 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. |
| checkin_date_from | – | – | 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. |
| checkin_date_to | – | – | Last check-in date of the range, "YYYY-MM-DD". |
| checkout_date | – | – | Departure morning, "YYYY-MM-DD". Must be after checkin_date. Give either this or nights, not both. |
| children | – | – | Number of children sharing the room. |
| currency | – | – | ISO currency code for the prices returned, e.g. "usd". |
| hotel_name | string | 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. |
| max_searches | – | – | 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 ca… |
| nights | – | – | 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. |
| price_as_seen_from | – | – | 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| api_usage | object | – | 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. |
| applied_filters | – | – | Which of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through. |
| caveats | array | – | 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. |
| cheapest_overall | – | – | The cheapest stay across everything priced, or null when nothing was. `results` holds this stay's full property list. |
| message | string | – | – |
| needs_api_key | boolean | – | 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. |
| partial | string | – | Present when some stays failed but others were priced. Plain text saying how much of the request the answer covers. |
| providers | array | – | One entry per source that was called, in the order they were requested. Only present when `providers` named more than the default source. |
| providers_skipped | array | – | 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 miss… |
| quota_exhausted | boolean | – | True when the caller's RapidAPI plan has no requests left for the current period. |
| result_count | integer | – | – |
| results | array | 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… |
| results_for_stay | – | – | 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. |
| search_coverage | object | – | 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. |
| search_status | string | – | 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 pric… |
| signup_url | string | – | Where the caller subscribes or changes plan. |
| stays | array | – | 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… |
No examples provided.
search_hotels FlightPowers: search hotels ~1,215
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 `?rapida…
| Name | Type | Req | Description |
|---|---|---|---|
| adults | – | – | Number of adult guests. Defaults to the upstream default when omitted. |
| budget_per_night | – | – | Only return properties at or below this nightly price, in `currency`. |
| checkin_date | – | – | 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. |
| checkin_date_from | – | – | 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. |
| checkin_date_to | – | – | Last check-in date of the range, "YYYY-MM-DD". |
| checkout_date | – | – | Departure morning, "YYYY-MM-DD". Must be after checkin_date. Give either this or nights, not both. |
| children | – | – | Number of children sharing the room. |
| currency | – | – | ISO currency code for the prices returned, e.g. "usd". |
| destination | string | 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. |
| filters | – | – | 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. |
| max_searches | – | – | 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.… |
| nights | – | – | 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. |
| price_as_seen_from | – | – | 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… |
| providers | – | – | 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 i… |
| Name | Type | Req | Description |
|---|---|---|---|
| api_usage | object | – | 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. |
| applied_filters | – | – | Which of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through. |
| caveats | array | – | 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. |
| cheapest_overall | – | – | The cheapest stay across everything priced, or null when nothing was. `results` holds this stay's full property list. |
| message | string | – | – |
| needs_api_key | boolean | – | 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. |
| partial | string | – | Present when some stays failed but others were priced. Plain text saying how much of the request the answer covers. |
| providers | array | – | One entry per source that was called, in the order they were requested. Only present when `providers` named more than the default source. |
| providers_skipped | array | – | 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 miss… |
| quota_exhausted | boolean | – | True when the caller's RapidAPI plan has no requests left for the current period. |
| result_count | integer | – | – |
| results | array | 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… |
| results_for_stay | – | – | 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. |
| search_coverage | object | – | 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. |
| search_status | string | – | 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 pric… |
| signup_url | string | – | Where the caller subscribes or changes plan. |
| stays | array | – | 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… |
No examples provided.
How do I install the Booking.com Hotel Search (Live Prices) MCP server?
Booking.com Hotel Search (Live Prices) is a hosted endpoint at https://hotels.flightpowers.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · hotels.flightpowers.com
claude mcp add --transport http com-flightpowers-booking 'https://hotels.flightpowers.com/mcp'
What is the Booking.com Hotel Search (Live Prices) MCP server?
Booking.com Hotel Search (Live Prices) is an MCP server listed in the public MCP registry as com.flightpowers/booking. Live Booking.com hotel prices, plus per-country pricing for rate-parity monitoring. This page covers its hosted endpoint (https://hotels.flightpowers.com/mcp).
Is the Booking.com Hotel Search (Live Prices) MCP server safe to use?
Booking.com Hotel Search (Live Prices) scores 91 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Booking.com Hotel Search (Live Prices) MCP server expose?
Booking.com Hotel Search (Live Prices) exposes 3 tools: search_hotels, find_hotel_by_name, compare_hotel_rates. Their descriptions and schemas cost roughly 2,653 tokens of context every time the server is loaded.
Does the Booking.com Hotel Search (Live Prices) MCP server require authentication?
Yes. Booking.com Hotel Search (Live Prices) asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Booking.com Hotel Search (Live Prices) MCP server still maintained?
Booking.com Hotel Search (Live Prices) is still listed as active in the MCP registry. We last reached this channel on 17 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.