Booking.com Hotel Search (Live Prices)

Name: Booking.com Hotel Search (Live Prices)
Author: mtnrabi

Server Details

Live Booking.com hotel prices, plus per-country pricing for rate-parity monitoring.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 07:16
Transport: Streamable HTTP
URL
Repository: mtnrabi/travel-agent-skills
GitHub Stars: 0

Available Tools

2 tools

find_hotel_by_nameFind one hotel by nameA

Read-only

Inspect

Get 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 and a booking link. Use it to check one specific hotel, or to track a single property's price over time.

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.

ParametersJSON Schema

Name	Required	Description
`adults`	No	Number of adult guests.
`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`	Yes	First night of the stay, "YYYY-MM-DD".
`checkout_date`	Yes	Departure morning, "YYYY-MM-DD". Must be after checkin_date.
`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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	Yes	The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
`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.
`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.
`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.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark this as read-only and non-destructive, but the description adds substantial behavioral context: rates go stale within minutes, results must not be reused, pricing gaps are property-dependent and move between calls, caller's own RapidAPI key is required, and api_usage is reported. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat long but every sentence earns its place: core purpose, input guidance, return fields, use cases, caveats, stale-data warning, and auth requirements. It is front-loaded with the main function and structures the fine print afterward, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool does, required inputs, return contents, usage caveats, authentication requirements, and quota implications. With an output schema present and annotations indicating read-only behavior, nothing essential is missing for an agent to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds meaningful nuance for hotel_name (typed as a person would, adding city disambiguates, no internal ID) and for price_as_seen_from (shopper-resident pricing, call multiple times before reporting gaps). This goes beyond the schema's baseline definitions.

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

Purpose5/5

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

States a specific verb and resource: 'Get availability and pricing for one named property.' It is clearly distinguished from the sibling search_hotels by emphasizing a single named property and no internal ID need, with explicit use cases (check one hotel, track a single property's price over time).

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

Usage Guidelines4/5

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

The description gives clear context for when to use the tool: checking one specific hotel or tracking a single property. It implies the alternative (broader search) by contrast, though it does not explicitly name search_hotels or state when to prefer it. It also provides practical usage guidance around stale rates and calling each country multiple times.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_hotelsSearch hotelsA

Read-only

Inspect

Search live hotel 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 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.

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

ParametersJSON Schema

Name	Required	Description
`adults`	No	Number of adult guests. Defaults to the upstream default when omitted.
`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".
`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.
`budget_per_night`	No	Only return properties at or below this nightly price, in `currency`.
`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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	No
`results`	Yes	The itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
`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.
`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.
`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.

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the read-only/destructive annotations, the description reveals that results go stale within minutes, rates move between calls, and repeated calls are required for reliable parity gaps. It also discloses authentication mechanics (multiple accepted key locations, first non-empty wins) and api_usage reporting. No statement contradicts the readOnlyHint/openWorldHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well structured: purpose, parity caveat, freshness warning, and API key setup each get their own paragraph, with no filler. The main action is front-loaded in the first sentence. It is longer than minimal but every sentence carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter live-search tool with an output schema, the description covers what is needed to call it safely: destination/date semantics, required API key, rate volatility, parity-use guidance, and response accounting via api_usage. With annotations covering safety and an output schema covering returns, nothing significant is missing. The only mild gap is explicit sibling routing, which was already scored in usage_guidelines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 9 parameters. The description mostly echoes the schema's destination and price_as_seen_from guidance rather than adding new parameter-level semantics. Authentication and rate staleness guidance are valuable context but are not about the input parameters, so the baseline score of 3 applies.

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

Purpose5/5

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

The description opens with 'Search live hotel availability and nightly prices for a destination and date range,' which names a specific action, resource, and scope. It also lists return fields (price, review score, room type, location, booking link) and contrasts free-text destination search with the sibling's name-based lookup. This leaves little ambiguity about what the tool does.

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

Usage Guidelines4/5

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

It clearly identifies when to use live destination-and-date searches, including free-text destinations and rate-parity use cases ('which no other travel tool here can do'). It does not explicitly state 'use find_hotel_by_name when you already know the hotel name,' so the alternative/exclusion guidance is less direct than it could be. Prerequisites (RapidAPI key) and freshness requirements are stated, which helps call selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesSep 2, 2026

Changedfind_hotel_by_name1 field changed

changedInput schema / properties / price_as_seen_from / description

Previous 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."

Changedsearch_hotels1 field changed

changedInput schema / properties / price_as_seen_from / description

Previous 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."

2 tool updatesAug 27, 2026

Changedfind_hotel_by_name4 fields changed

addedOutput schema / description

Added value: +"A completed hotel search. The hotels upstream reports no search-status header, so these results carry no search_status field."

addedOutput schema / properties

Added 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"
+  }
+}

addedOutput schema / required
```
Added value: +[
+  "results"
+]
```
addedOutput schema / title
```
Added value: +"Hotel search result"
```

Changedsearch_hotels4 fields changed

addedOutput schema / description

Added value: +"A completed hotel search. The hotels upstream reports no search-status header, so these results carry no search_status field."

addedOutput schema / properties

Added 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"
+  }
+}

addedOutput schema / required
```
Added value: +[
+  "results"
+]
```
addedOutput schema / title
```
Added value: +"Hotel search result"
```

2 tool updatesAug 26, 2026

Changedfind_hotel_by_name7 fields changed

addedInput schema / properties / adults / description
```
Added value: +"Number of adult guests."
```

addedInput schema / properties / checkin_date / description

Added value: +"First night of the stay, \"YYYY-MM-DD\"."

addedInput schema / properties / checkout_date / description

Added value: +"Departure morning, \"YYYY-MM-DD\". Must be after checkin_date."

addedInput schema / properties / children / description

Added value: +"Number of children sharing the room."

addedInput schema / properties / currency / description

Added value: +"ISO currency code for the prices returned, e.g. \"usd\"."

addedInput schema / properties / hotel_name / description

Added 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."

addedInput schema / properties / price_as_seen_from / description

Added 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."

Changedsearch_hotels9 fields changed

addedInput schema / properties / adults / description

Added value: +"Number of adult guests. Defaults to the upstream default when omitted."

addedInput schema / properties / budget_per_night / description

Added value: +"Only return properties at or below this nightly price, in `currency`."

addedInput schema / properties / checkin_date / description

Added value: +"First night of the stay, \"YYYY-MM-DD\"."

addedInput schema / properties / checkout_date / description

Added value: +"Departure morning, \"YYYY-MM-DD\". Must be after checkin_date."

addedInput schema / properties / children / description

Added value: +"Number of children sharing the room."

addedInput schema / properties / currency / description

Added value: +"ISO currency code for the prices returned, e.g. \"usd\"."

addedInput schema / properties / destination / description

Added 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."

addedInput schema / properties / filters / description

Added 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."

addedInput schema / properties / price_as_seen_from / description

Added 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."

2 tool updatesAug 18, 2026
- First observedfind_hotel_by_name
- First observedsearch_hotels

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

HasData Booking.comOAuth
com.hasdata
Booking.com stays by destination and dates, and full property details, as structured JSON.
Travel & Transportation Search
14
Hotel Rate Monitoring APIOAuth
io.github.veyvey45-eng
Remote MCP server for hotel rate monitoring, parity checks, and pricing intelligence via Apify.
Web Scraping E-commerce & Retail Monitoring
2
mcp-server A
com.pricetik
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Travel & Transportation E-commerce & Retail
2
Blue Pillow Hotels & Stays A
com.bluepillow
Neutral hotel & stay price comparison for AI agents: live prices from 16+ booking sites. No signup.
Travel & Transportation E-commerce & Retail
62

Related MCP Servers

MAQAMI Travel
Travel & Transportation E-commerce & Retail
negm17111995
A
license
Not graded
quality
B
maintenance
Book hotels worldwide — search, price, prebook & book across 249 countries. 65 tools for hotel search, flights, loyalty, analytics. Zero API keys needed. at best prices for hotels 3 M+ property
Updated 2 months ago (2026-07-03 22:56 UTC)
22
1
MIT
hotel-rates-mcp
Travel & Transportation Search
RobertoReale
A
license
Not graded
quality
C
maintenance
Enables verified, bookable hotel price checking with tax-inclusive totals, OTA tax status flags, and durable Booking.com fallback links for budget travel planning.
Updated 3 months ago (2026-06-08 19:53 UTC)
MIT
hotels-skill
Travel & Transportation Web Scraping
Anmoldureha
F
license
Not graded
quality
D
maintenance
Enables real-time hotel search and pricing data from Booking.com for AI agents and Claude.
Updated 7 months ago (2026-02-16 08:14 UTC)
7
2
-
Booking MCP Server
Research & Data Travel & Transportation Web Scraping
HasData
A
license
A
quality
A
maintenance
Enables MCP clients to search stays by destination and dates with rich filters and read full property details as structured JSON, without needing a Booking.com account or self-hosting.
Updated 10 days ago (2026-08-27 08:06 UTC)
4
2
511
4
MIT

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

The two tools have clearly distinct scopes: one resolves a specific named property, the other searches a destination. An agent would not confuse 'find_hotel_by_name' with 'search_hotels' because the inputs and outputs differ meaningfully.

Naming Consistency4/5

Both names follow a verb_noun pattern with underscores, though 'find_hotel_by_name' includes a modifier while 'search_hotels' is plain. This is a minor stylistic deviation, not a source of confusion.

Tool Count3/5

Two tools is minimal for a hotel search server, but the pair covers the two fundamental entry points: a specific property lookup and a destination search. It feels slightly thin rather than well-scoped.

Completeness4/5

For a server focused on live prices and availability, the two tools cover the essential queries: destination-level search and property-level lookup. There is no booking or filtering tool, but those are outside the stated purpose, making the surface adequate.

Server Details

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

MAQAMI Travel

hotel-rates-mcp

hotels-skill

Booking MCP Server

Glama MCP Gateway

TDQS

Resources