Skip to main content
Glama

Booking.com Hotel Search (Live Prices)

by com.flightpowers
OverviewAdmin

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
Transport
Streamable HTTP
URL
Repository
mtnrabi/travel-agent-skills
GitHub Stars
0

TDQS

A4.6/5.0
Disambiguation5/5

The two tools have clearly distinct granularities: search_hotels targets a destination and returns multiple properties, while find_hotel_by_name targets a specific named property. There is no meaningful overlap in what the tools are meant to do.

Naming Consistency5/5

Both tools follow a predictable verb + noun pattern: search_hotels and find_hotel_by_name. The naming style is consistent and immediately conveys what each tool does.

Tool Count3/5

With only two tools, the server feels minimal but is narrowly scoped to live hotel search and single-property lookup. The count is borderline rather than clearly well-scoped.

Completeness4/5

The core hotel search workflow is covered: destination-wide search and targeted property lookup with live pricing, review scores, room type, and booking links. Minor gaps exist around additional filtering or property-detail operations, but agents can work around them.

Available Tools

2 tools
find_hotel_by_nameFlightPowers: find one hotel by nameA
Read-only
Inspect

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 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
NameRequiredDescriptionDefault
adultsNoNumber of adult guests.
childrenNoNumber of children sharing the room.
currencyNoISO currency code for the prices returned, e.g. "usd".
hotel_nameYesThe 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_dateYesFirst night of the stay, "YYYY-MM-DD".
checkout_dateYesDeparture morning, "YYYY-MM-DD". Must be after checkin_date.
price_as_seen_fromNoTwo-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
NameRequiredDescription
messageNo
resultsYesThe itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
api_usageNoWhat 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_urlNoWhere the caller subscribes or changes plan.
result_countNo
needs_api_keyNoTrue 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_filtersNoWhich of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through.
quota_exhaustedNoTrue 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?

The description goes well beyond the annotations, disclosing that rates go stale within minutes, that results should never be reused, that the caller must supply their own RapidAPI key, and that the response reports usage in api_usage. It also explains that price_as_seen_from gaps are real but require repeated calls to confirm. No contradiction with the readOnlyHint/destructiveHint 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 longer than average but every section earns its place: purpose and input first, then pricing-behavior caveats, then authentication and quota information. It is well-structured and front-loaded with the core lookup behavior.

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

Completeness5/5

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

For an external API read tool with 7 parameters and an output schema, the description covers the essential operational context: live data behavior, staleness, authentication mechanism, quota attribution, and usage reporting. An agent has everything needed to invoke it correctly and interpret the operational constraints.

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?

The schema already documents all parameters well, but the description adds meaningful guidance: no internal property ID is needed, adding the city helps disambiguate chain properties, and price_as_seen_from should be tested with repeated calls before reporting a gap. This is real value beyond the schema descriptions.

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 'FlightPowers single-property lookup' and specifies exactly what it does: live Booking.com availability and pricing for one named property. It clearly distinguishes itself from the sibling search_hotels by being the single-property counterpart.

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 explicitly states the intended use cases: 'check one specific hotel, or to track a single property's price over time.' It does not explicitly name search_hotels as the alternative for multi-property discovery, but the single-property framing makes the dividing line clear.

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

search_hotelsFlightPowers: search hotelsA
Read-only
Inspect

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

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
NameRequiredDescriptionDefault
adultsNoNumber of adult guests. Defaults to the upstream default when omitted.
filtersNoProperty filters to apply, e.g. ["free_cancellation", "breakfast_included"]. An unknown name is rejected with the list of valid ones rather than being ignored.
childrenNoNumber of children sharing the room.
currencyNoISO currency code for the prices returned, e.g. "usd".
destinationYesWhere 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_dateYesFirst night of the stay, "YYYY-MM-DD".
checkout_dateYesDeparture morning, "YYYY-MM-DD". Must be after checkin_date.
budget_per_nightNoOnly return properties at or below this nightly price, in `currency`.
price_as_seen_fromNoTwo-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
NameRequiredDescription
messageNo
resultsYesThe itineraries or properties found, already sorted and deduplicated. An empty array is only meaningful when search_status is 'empty'.
api_usageNoWhat 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_urlNoWhere the caller subscribes or changes plan.
result_countNo
needs_api_keyNoTrue 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_filtersNoWhich of the requested filters the upstream actually applied. Untyped: the shape is the upstream's, echoed through.
quota_exhaustedNoTrue when the caller's RapidAPI plan has no requests left for the current period.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already signal read-only and non-destructive, but the description adds substantial behavioral context: rates 'go stale within minutes,' calls are not idempotent, and usage counts against the caller's own RapidAPI plan. It also warns that apparent country gaps can be artifacts ('never read one call per country as a gap'), which is exactly the kind of nuance an agent needs. No contradiction with the 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?

Organized into purpose, caveats, freshness, and auth sections; every sentence is dense with operational signal. The price-parity guidance slightly repeats the schema, but it is important enough to reinforce. There is no filler.

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

Completeness5/5

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

Given the output schema exists and annotations cover safety, the description closes the remaining gaps: external API key requirement, usage billing, result freshness, and the rate-parity procedure. An agent could invoke this tool correctly without needing follow-up clarification.

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?

Schea covers all 9 parameters (100%), so the baseline is 3. The description adds real value beyond the schema by documenting the hidden auth parameter (x-rapidapi-key header, ?rapidapi_key= query, or client key field, first non-empty wins) and by reinforcing the free-text destination semantics and the price_as_seen_from parity methodology. It doesn't add new detail for filters/currency/adults, but the schema already handles those.

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?

One sentence states the tool's verb and resource: 'live Booking.com availability and nightly prices for a destination and date range.' It specifies free-text input and the returned fields. The 'no other travel tool here can do' claim differentiates it from siblings like find_hotel_by_name without confusing the two.

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

Usage Guidelines5/5

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

Explicitly positions this as the tool for free-text destination/date-range searches and the only tool for `price_as_seen_from` resident-pricing comparisons ('no other travel tool here can do'). It gives concrete invocation guidance (hold one property fixed, call each country a few times, never reuse stale results) and a hard prerequisite (caller's own RapidAPI key). It doesn't enumerate every when-not-to-use case, but the alternatives are clearly implied.

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.

  1. 2 tool updates
    • 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. 2 tool updates
    • 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"
  3. 2 tool updates
    • 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."
  4. 2 tool updates
    • First observedfind_hotel_by_name
    • First observedsearch_hotels

Frequently Asked Questions

Discussions

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

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

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.

Resources