Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

booking_reviews

Fetch Booking.com hotel guest reviews by hotel ID and country code; filter by text, paginate, and get scores, room types, and stay dates.

Instructions

Booking.com hotel reviews. Returns guest reviews for a Booking.com hotel. hotel_id and hotel_country_code are required, both from a booking-search result. search_text filters review content, page is 1-based and limit is 1 to 25 (default 10). Reviews have score, title, positive_text, negative_text, room_type and stay dates; rating_scores and reviews_count summarise the hotel.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based result page, default 1
limitNoReviews per page, 1-25, default 10
hotel_idYesBooking.com hotel id, from a prior search's property id
hotel_scoreNoHotel's overall review score
search_textNoOptional free-text search over review content
destination_idNoDestination id (ufi), from a prior search response
hotel_country_codeYesHotel's country code, from a prior search response

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return shape (score, title, positive_text, negative_text, room_type, stay dates, rating_scores, reviews_count) and pagination defaults, but never states it is a safe read-only operation, nor any auth or rate-limit behavior.

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?

Front-loaded with the core purpose, then provenance, then filtering/pagination, then return content. Dense but every sentence is functional, with only mild redundancy against the schema's own parameter descriptions.

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, describing returned fields is appropriate and present. Required params, their source, pagination bounds and filtering are all covered; the only gap is the absence of any safety/read-only statement for a tool that has no annotations.

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 coverage is 100%, so the baseline is 3, but the description adds real value by naming `booking-search` specifically as the provenance of the two required ids, whereas the schema only says 'from a prior search'. It also restates the search_text, page, and limit semantics consistently with the schema.

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 ('Returns guest reviews for a Booking.com hotel'), immediately separating it from siblings like booking_hotel_detail, booking_search, and booking_attractions_reviews. An agent knows exactly what domain object it acts on.

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?

Gives a clear prerequisite: hotel_id and hotel_country_code must come from a `booking-search` result, which tells the agent this tool cannot be called standalone. It does not, however, distinguish when to prefer this over other review sources (e.g. booking_attractions_reviews).

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

Deploy Server

Other Tools