Skip to main content
Glama

Booking.com MCP Server

A hosted Model Context Protocol (MCP) server that gives Claude, Cursor, Windsurf and any other MCP client two read-only Booking.com tools. Search stays by destination and dates with rich filters, and read a single property in full, all as structured JSON, with no Booking.com account and nothing to host.

It reads public property pages on Booking.com that a signed-out visitor can see.

https://mcp.hasdata.com/api/mcp?apis=booking

Glama score tool contract MCP Tools npm PyPI License

Contents

Related MCP server: Hotels MCP Server

What you need

An MCP client and a HasData API key from the dashboard, free to create with no card, and the trial covers 100 calls at the 10-credit rate. This is a remote server, so the simplest path is a URL and an x-api-key header, with no container to run and no Booking.com account anywhere in the flow. A client that only speaks stdio reaches it through a thin launcher, published as @hasdata/booking-mcp on npm and hasdata-booking-mcp on PyPI, shown below.

Quick start

The server URL is the same for every client. We run it hands-on in Claude Code and Claude Desktop. The other blocks follow each client's own documented format for a remote server.

Field

Value

URL

https://mcp.hasdata.com/api/mcp?apis=booking

Transport

HTTP, streamable

Auth header

x-api-key: HASDATA_API_KEY

Clients with OAuth support can add the same URL as a connector and sign in without putting a key in a config file.

claude mcp add --transport http booking "https://mcp.hasdata.com/api/mcp?apis=booking" \
  --header "x-api-key: HASDATA_API_KEY"

Settings, then Connectors, then Add custom connector, then paste https://mcp.hasdata.com/api/mcp?apis=booking and sign in.

For the config-file route, Claude Desktop loads only local (stdio) servers, so it reaches a remote server through a stdio launcher. The @hasdata/booking-mcp package is that launcher, and it reads the key from the environment. Add this to claude_desktop_config.json:

{
  "mcpServers": {
    "booking": {
      "command": "npx",
      "args": ["-y", "@hasdata/booking-mcp"],
      "env": { "HASDATA_API_KEY": "YOUR_KEY" }
    }
  }
}

For Python instead of Node, swap the launcher for the PyPI package, which uvx runs without a manual install:

{
  "mcpServers": {
    "booking": {
      "command": "uvx",
      "args": ["hasdata-booking-mcp"],
      "env": { "HASDATA_API_KEY": "YOUR_KEY" }
    }
  }
}

~/.cursor/mcp.json for every project, or .cursor/mcp.json for one:

{
  "mcpServers": {
    "booking": {
      "url": "https://mcp.hasdata.com/api/mcp?apis=booking",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

~/.codeium/windsurf/mcp_config.json. Windsurf calls the field serverUrl, not url:

{
  "mcpServers": {
    "booking": {
      "serverUrl": "https://mcp.hasdata.com/api/mcp?apis=booking",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

.vscode/mcp.json in the workspace:

{
  "servers": {
    "booking": {
      "type": "http",
      "url": "https://mcp.hasdata.com/api/mcp?apis=booking",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

Example prompts

Prompts, not code. Paste one in and the agent picks the tool itself. Each is annotated with the calls it takes, because every successful call costs 10 credits.

Search Booking.com for hotels in Paris from September 15 to 18 for two adults, and give me the ten best-reviewed under $700 for the stay.

One call, 10 credits. Price, review score and location come back on the search result.

Take the top result and pull its full detail: facilities, house rules, the room options, and the category ratings.

One call, 10 credits. Those live on the property page, which the details tool reads by URL and dates.

Find four-star hotels in Paris with free cancellation near the center, and list price and review score.

One call, 10 credits. Star rating, cancellation policy and distance are filters on the one request.

Compare the cheapest stay in Paris against Rome for the same dates.

Two calls, 20 credits, one search per city.

The property tool needs the same dates and guest counts as the search, because availability and price depend on the window. A search to shortlist plus a detail call on three properties is one search and three property calls.

Tools

Two tools, read-only. Samples below are trimmed from real calls, and prices move constantly. Read them as shapes. Each tool name links to its endpoint reference, which carries the full field list.

The samples are the payload, not the whole response. A tools/call result carries one text block, and that text is itself JSON holding url, status, text and json, with the scraped data under json. From a raw JSON-RPC response the path is result.content[0].text, parsed, then .json. A chat client unwraps that for you and code talking to the endpoint directly does not.

Get Booking.com search results

hasdata_booking_search_getBookingSearchResults

A page of stays by destination and dates.

Parameter

Type

Required

Notes

keyword

string

yes

Destination, such as Paris or a specific property name

checkInDate / checkOutDate

string

yes

YYYY-MM-DD, check-in in the future and before check-out

rooms / adults / children

number

yes

Guest composition. Pass children: 0 when there are none

childrenAges

string

Comma-separated ages, required when children > 0

sort

string

priceLowestFirst, ratingHighToLow, bestReviewedAndLowestPrice, distanceFromDowntown and more

propertyType__ / rating__ / reviewScore__

array

Property type, star rating, and guest-score buckets

facilities__ / roomFacilities__ / reservationPolicy__

array

Facility, in-room and cancellation filters

price_min_ / price_max_

number

Total-stay price band

page

number

About 25 results per page, 2 for the next page

The reference documents the full filter set, including distance, meals, accessibility, bed preference and travel group.

Returns searchInformation, a results array, and pagination with page, totalResults and totalPages. Each result carries hotelId, title, url, the offered room and bedTypes, a location object, a policies object, a price object, the star rating, a reviews object with score, count and a text label, and a photo.

The discount field in price is spelled dicsount (dicsountRaw and dicsountParsed), which mirrors the upstream key. Read that spelling, not discount. Also note rating is the official star rating while reviews.score is the guest score out of 10, two different numbers.

{
  "hotelId": 50724,
  "title": "Hôtel du Jardin des Plantes",
  "url": "https://www.booking.com/hotel/fr/timjardindesplantes.html",
  "room": "Comfort Double Room",
  "location": { "city": "Paris", "address": "5 rue Linné", "mainDistance": "0.9 miles from downtown", "centrallyLocated": true },
  "policies": { "freeCancellation": true, "noPrepayment": true },
  "price": { "pricePerStayParsed": 451.36, "priceBeforeDiscountParsed": 885.03, "dicsountParsed": 433.66, "currency": "USD" },
  "rating": 3,
  "reviews": { "score": 7.5, "count": 1721, "text": "Good" }
}

Get Booking.com property details

hasdata_booking_place_getBookingPlaceDetails

One property in full, by its URL and the stay window.

Parameter

Type

Required

Notes

url

string

yes

A Booking.com property URL, the url field from a search result

checkInDate / checkOutDate

string

yes

YYYY-MM-DD, the window to price and check availability for

rooms / adults / children

number

yes

Guest composition, same meaning as the search tool

childrenAges

string

Comma-separated ages, required when children > 0

Returns the page as sections rather than one flat object: overview (id, title, propertyType, a structured address, a description, highlights, mostPopularFacilities and photos), bookingDetails (the window and currency the prices reflect), a rooms array of the available suites each with name, beds, facilities and priced variants, a facilities list, houseRules, a ratings array of category scores, reviews, and questionsAndAnswers.

{
  "overview": {
    "id": "50724",
    "title": "Hôtel du Jardin des Plantes",
    "propertyType": "HOTEL",
    "address": { "country": "France", "zipcode": "75005" },
    "mostPopularFacilities": ["Non-smoking rooms", "Free Wifi", "24-hour front desk"]
  },
  "bookingDetails": { "checkIn": "2026-09-15", "checkOut": "2026-09-18", "adults": 2, "rooms": 1, "currency": "USD" },
  "ratings": [
    { "label": "Average", "value": 7.5, "votes": 1721 },
    { "label": "Cleanliness", "value": 7.8 }
  ]
}

Errors and failure paths

Your client almost never sees an HTTP error code from a tool call. The MCP layer answers 200 and puts the failure inside the result, with isError set to true and the reason as text. The agent reads a message where you might expect a status line.

A wrong key surfaces as tool output, not as a failed connection. tools/list accepts any non-empty key and returns both tools, so the client completes its handshake and shows green. The first tool call then comes back with isError: true and the text HasData API error: 401 Unauthorized. Watch for that string, because nothing earlier in the flow reports the problem.

A missing key is the one real HTTP error. Authorization runs before any tool, and the connection itself fails with 401. CORS headers are present, and a browser client reads the status and not an opaque network failure.

An argument that breaks a tool's schema is rejected before it becomes a scrape. The server answers with isError: true and the text MCP error -32602: Input validation error, naming the offending field. A children count without matching childrenAges, or a check-out on or before check-in, is caught here.

A search with no availability returns a successful result with an empty results array, not an error. A destination and window with nothing open still comes back with requestMetadata.status set to ok. Test for the array length before you iterate.

A property URL that no longer resolves returns 400 with requestMetadata.status set to error.

Results that carry data also carry a requestMetadata.id worth quoting in support.

Pricing, free tier and limits

Each Booking.com tool costs 10 credits per successful call. Response size does not change the price. A search page of 25 stays costs the same as one with two.

The free trial is 1,000 credits over 30 days with no card, which is 100 Booking.com calls. After that an active account keeps getting 100 credits topped up each day whenever its balance drops below 100, so a low-volume agent runs on the free tier indefinitely.

Paid plans start at $49 a month for 200,000 credits, which is 20,000 calls. The unit price falls with volume, from $2.45 per 1,000 calls on the entry plan to $0.99 on Business, $0.83 on Growth and $0.75 on the largest high-volume plans.

Your plan also sets concurrency. The free trial allows 1 request at a time, Startup 15, Business 30, Growth 50, and the high-volume plans run from 200 to 1,500. Handle the overflow case defensively in anything unattended.

A request that comes back non-200 is not billed. A successful call that finds nothing is still a call.

Tool selection

The apis query parameter decides which tools your agent sees. Fewer tools means less context spent on tool definitions, and fewer chances for the model to reach for the wrong one.

?apis=booking                    the two tools in this repo
?apis=booking,airbnb             add Airbnb stays
?apis=booking,google_travel      add Google Hotels and Flights

The parameter takes provider names like booking and individual API names like booking_search. Misspelled names are ignored. If every name is wrong the request fails with 400, and the body lists both what it did not recognise and every valid value. Drop the parameter and the same endpoint exposes all 57 HasData tools.

How it compares

Booking.com's own programs, the Demand API and the affiliate partner network, are for approved partners who send bookings and earn commission, not a self-serve way to read the public market. For searching stays and reading arbitrary properties, scraping the public pages is the route, and this server does that behind a stable schema.

Booking.com partner programs

This server

Purpose

Send bookings as an approved affiliate

Read the public market

Access

Partner approval

One key and one URL

Search across the market

Within partner terms

Yes, with rich filters

Setup

Business onboarding

None

Output

Partner feeds

Structured JSON, price and score pre-parsed

What this server does not do. No booking, no payment, no partner commission, no account data. It reads what a signed-out visitor can see on Booking.com.

FAQ

Is there an official Booking.com MCP server?

Booking.com does not publish one. This one is maintained by HasData and reads public pages, which is why it needs no Booking.com account.

What is a Booking.com MCP server?

A server that exposes Booking.com data as tools an AI client can call. The client sends a tool call over the Model Context Protocol, the server fetches the data and returns structured JSON, and the model works with the result. This one exposes two tools and runs remotely.

Do I need a Booking.com account or partner approval?

No. The only credential is your HasData key. There is no partner onboarding, because the tools read public Booking.com pages.

Why does the property tool need dates?

Because availability, room options and price all depend on the stay window. Pass the same checkInDate, checkOutDate and guest counts you searched with, and the detail reflects that window.

What is the difference between rating and review score?

rating is the official star rating of the property. reviews.score is the guest review score out of 10. A three-star hotel can carry a 9.0 guest score, so read the one you mean.

Can I use this together with other HasData APIs?

Yes. The apis parameter takes a list, and ?apis=booking,airbnb gives your agent Booking.com plus Airbnb. Drop the parameter and you get everything.

Is HasData affiliated with Booking.com?

No. HasData is an independent service and is not affiliated with, endorsed by, or sponsored by Booking.com. Booking.com is a trademark of its respective owner.

Compliance and personal data

HasData accesses publicly available data only. A platform's terms may restrict automated access, and you are responsible for your own compliance. Where the data you collect includes personal information, make sure you have a lawful basis for it under GDPR, CCPA or the equivalent rules in your jurisdiction.

Product page and request builder

Booking.com Scraper API

Server documentation

MCP server docs

All 57 tools in one server

HasData/hasdata-mcp

Client walkthroughs

MCP clients and integrations

Everything else we scrape

Booking.com Scraper API and 54 more

Plans and credit costs

Plans and credit costs

Keys and usage

HasData dashboard

Node launcher on npm

@hasdata/booking-mcp

Python launcher on PyPI

hasdata-booking-mcp

Development

This repository is configuration and documentation for a remote server. There is no build step and nothing to containerize.

The tests in test/ assert the tool contract, the part that can break without a commit here. They check that ?apis=booking returns exactly two tools, that every tool still declares its required parameters, that no name changed, and that the key in use is actually accepted. That last check calls a tool for real and costs 10 credits, which is the price of a canary that can fail for the right reason.

# macOS and Linux
HASDATA_API_KEY=your_key_here npm test

# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm test

The same suite runs in CI on every push and once a week on a schedule, because the upstream tool list can change without anyone touching this repository. A failure means the tool list moved, the key stopped working, or the endpoint was unreachable, and the assertion message says which.

Contributing

Corrections to the tool tables and the response samples are the most useful contribution, because those are the parts that drift. Include the call you made and the response you got. Pull requests from forks run the suite without a key, and the live checks skip instead of going red.

License

MIT. See LICENSE.

Available Tools

2 tools
hasdata_booking_place_getBookingPlaceDetailsbooking_place: GET /AInspect

Get Booking Hotel Details

Fetches a single Booking.com property by its full URL for the given stay dates (checkInDate / checkOutDate) and guest composition (rooms, adults, children with ages). Returns the property identity (hotelId, title, address, coordinates), policies (free cancellation, no prepayment, child/pet stays), price, rating and review summary, photos, and the list of available room suites for the requested window. Use to enrich property listings with real-time availability and pricing, monitor a specific competitor hotel over time, validate amenities and photos before displaying venue details to end users, or fetch full details after discovering the property URL via the Booking Search endpoint.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFull Booking.com URL of the property page. Only `booking.com` and `www.booking.com` hosts are accepted.
roomsYesNumber of rooms to book.
adultsYesNumber of adult guests across all rooms.
childrenYesNumber of child guests across all rooms (0–10). Pass `0` if there are no children.
currencyNoCurrency of the prices returned in the response. Use `hotelCurrency` to keep each property's native currency. Provide one exact documented value (52 allowed), e.g. `hotelCurrency`, `usd`.
languageNoLanguage of the Booking.com interface and localized fields in the response.
checkInDateYesCheck-in date in `YYYY-MM-DD` format. Must be in the future and earlier than `checkOutDate`.
checkOutDateYesCheck-out date in `YYYY-MM-DD` format. Must be later than `checkInDate`.
childrenAgesNoComma-separated list of child ages, one entry per child (each `0`–`17`). Required when `children > 0` and the number of ages must equal `children`. Example: `1,3,7`

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses that this is a read-style 'Fetches' operation, that it returns real-time availability and pricing, and it summarizes the outputs including policies, ratings, photos, and room suites. It does not mention limiting behaviors such as rate handling or response failure conditions, but it is substantially transparent for a GET-like lookup.

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 a well-organized paragraph: what it does, what it returns, and when to use it. The first line 'Get Booking Hotel Details' is slightly redundant with the name, but the rest of the description avoids unnecessary noise and information is front-loaded.

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

Completeness4/5

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

With no output schema and no annotations, the description compensates by listing the key return categories and explaining enriched use cases. It could include more detail about exact response structure or error conditions, but for the AI agent the combination of schema, use cases, and return summary is enough to select and invoke the tool correctly.

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?

The input schema provides full descriptions for all 9 parameters, so the schema does most of the parameter work. The description adds context by tying the inputs to stay dates and guest composition, and by mentioning the URL origin flow from search, but it does not deepen the individual parameter semantics.

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 a specific verb and resource: 'Fetches a single Booking.com property by its full URL.' It names the key inputs and outputs and distinguishes itself from the sibling by being a detail lookup for an already-known property URL rather than a discovery/search call.

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 concrete use cases: enrich property listings, monitor a competitor hotel, validate amenities/photos, and fetch details after a search. It does not explicitly state when not to use it versus the search endpoint, but it clearly implies this tool is for known URLs and detailed property data.

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

hasdata_booking_search_getBookingSearchResultsbooking_search: GET /AInspect

Get Booking Search Results

Searches Booking.com for accommodations by destination keyword and stay dates (checkInDate / checkOutDate) with guest composition (rooms, adults, children with ages) and rich filtering: property type, star rating, review score, hotel and room facilities, distance from center, reservation policy, bed preference, travel group, online payment, accessibility, plus optional price range and bedroom/bathroom counts. Pagination is page-based with 25 results per page; locale is controlled by language and currency. Returns each hotel's hotelId, title and Booking URL, location info (city, address, coordinates, distance to center / nearest beach), policies (free cancellation, no prepayment, child/pet stays), price (per stay, before discount, discount, currency), rating, review summary and main photo. Use to power travel-planning agents, OTA price/inventory monitoring, hotel competitor analysis, lead-generation in the hospitality vertical, or to feed hotelId / URL into the Booking Place endpoint for full property details.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number of the search results. Booking.com returns 25 results per page; pass `2` for results 26–50, `3` for 51–75, etc.
sortNoSort order applied by Booking.com to the results page.
roomsYesNumber of rooms to book.
adultsYesNumber of adult guests across all rooms.
keywordYesFree-text destination query. Usually a city, region or neighborhood (e.g. `Paris`, `Manhattan, New York`); a specific property name is also accepted.
meals__NoFilter by available meal plans. Multiple values are combined with OR.
bedroomsNoMinimum number of bedrooms in the property.
childrenYesNumber of child guests across all rooms (0–10). Pass `0` if there are no children.
currencyNoCurrency of the prices returned in the response. Use `hotelCurrency` to keep each property's native currency. Provide one exact documented value (52 allowed), e.g. `hotelCurrency`, `usd`.
languageNoLanguage of the Booking.com interface and localized fields in the response.
rating__NoFilter by official star rating. Multiple values are combined with OR.
bathroomsNoMinimum number of bathrooms in the property.
price_max_NoMaximum total price for the stay, in the requested `currency`. Must be `>= 20` and greater than `price[min]`. Required if `price[min]` is omitted.
price_min_NoMinimum total price for the stay, in the requested `currency`. Must be `>= 10`. Required if `price[max]` is omitted.
checkInDateYesCheck-in date in `YYYY-MM-DD` format. Must be in the future and earlier than `checkOutDate`.
checkOutDateYesCheck-out date in `YYYY-MM-DD` format. Must be later than `checkInDate`.
childrenAgesNoComma-separated list of child ages, one entry per child (each `0`–`17`). Required when `children > 0` and the number of ages must equal `children`. Example: `1,3,7`
facilities__NoFilter by property-level facilities. Multiple values are combined with OR.
reviewScore__NoFilter by minimum guest review score bucket. Multiple values are combined with OR.
travelGroup__NoFilter by travel-group oriented stay options. Multiple values are combined with OR.
propertyType__NoFilter by property type. Multiple values are combined with OR.
bedPreference__NoFilter by bed configuration. Multiple values are combined with OR.
onlinePayment__NoFilter by online payment options.
roomFacilities__NoFilter by in-room facilities. Multiple values are combined with OR.
reservationPolicy__NoFilter by reservation flexibility. Multiple values are combined with OR.
roomAccessibility__NoFilter by in-room accessibility features. Multiple values are combined with OR.
distanceFromCenter__NoFilter by distance from the destination center. Multiple values are combined with OR.
propertyAccessibility__NoFilter by property-level accessibility features. Multiple values are combined with OR.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden, and it does a good job: it reports that this is an external Booking.com search, that pagination is page-based with 25 results per page, that language and currency control locale, and it enumerates the returned hotel data. It does not cover possible errors, rate limits, or authorization requirements, but for a read-oriented search tool the behavioral disclosure is sufficient.

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 long, but given the tool's 28 parameters and rich return payload, nearly every sentence adds useful information. It is front-loaded with the core search behavior and filters before covering output and use cases; only the list of use cases is somewhat optional, but it still helps an agent choose the tool.

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 provides a complete picture for selecting and invoking the tool: required search inputs, available filters, pagination, locale handling, output contents, and the relationship with the Booking Place endpoint. Since there is no output schema, the explicit enumeration of return fields is especially valuable and covers what an agent needs to understand the result shape.

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?

The input schema already documents all 28 parameters with 100% coverage, so the baseline is 3. The description restates filter categories and some behaviors (e.g., guest composition, price range, pagination), but it adds limited semantic value beyond what the schema already provides for each parameter.

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 clearly states a specific action ('Searches Booking.com for accommodations') and a specific resource (destination keyword, stay dates, guest composition). It also differentiates itself from the sibling tool by noting that the returned `hotelId` / URL can be fed into the Booking Place endpoint for full property details.

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 strong usage context: it is for travel-planning, price/inventory monitoring, competitor analysis, and lead generation, and it points to the Booking Place endpoint as a downstream step for full property details. However, it does not explicitly state when NOT to use this tool or offer a direct comparison between the search and place endpoints, so the alternative guidance is implied rather than fully explicit.

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 updatesv1.0.0
    • First observedhasdata_booking_place_getBookingPlaceDetails
    • First observedhasdata_booking_search_getBookingSearchResults

TDQS

A4.3/5.0
Disambiguation5/5

Search and place details have clear boundaries: search accepts destination criteria and returns property lists, while place details consumes a single property URL and returns full property information. The overlap in returned pricing/rating fields is expected, not confusing.

Naming Consistency5/5

Both tool names follow the same hasdata_booking_<endpoint>_get... pattern, using place and search as distinct resource endpoints. The naming is consistent across the set, even though the operation suffix uses camelCase.

Tool Count3/5

Two tools is a minimal but reasonable set for a search-then-detail workflow. However, the count sits at the thin edge of the expected 3-15 tool range, leaving little room for exploration beyond the two core endpoints.

Completeness5/5

The tool surface covers the intended read-only Booking.com workflow: search for accommodations, then fetch a single property's full details. There are no dead ends for travel-planning or OTA data monitoring use cases.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to search and book hotels globally with real-time pricing and inventory from over 2 million properties.
    81
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    Provides two MCP servers: one for searching real-time flight prices via FlightAPI.io and another for hotel prices via Booking.com through RapidAPI, both accessible over Streamable HTTP.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HasData/booking-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server