Skip to main content
Glama

Get property details — static facts, no live availability

get_property_details
Read-only

Static record for a specific property — identified by its id. Returns the complete amenity list, photos, booking sources, dedup metadata, detailed location, and the headline rating (rating + rating_count) by default. Review DATA beyond the headline — the ratings breakdown and the actual review texts — is opt-in via the include parameter (see below); pass it whenever the user's question is about guest experience. Carries no price unless called with dates: a price only exists for a concrete stay window.

Useful when the user wants to inspect or compare a specific option in depth — facilities, neighborhood, what guests say — without yet committing to specific dates.

HOW TO GET REVIEWS (when you need to reason about guest experience): pass include. reviews_aggregate gives the score + counts + per-OTA breakdown; reviews_sample/reviews_extended give the actual review texts. Without include, none of these are returned (you get only the headline rating/rating_count). See the include section below.

For live availability and a real per-operator quote for a specific stay window, the path is check_property_availability instead. The two tools coexist by design: this one answers "what is this property like" with stable, cacheable data; the other answers "can I book it for these dates at what price" with live, date-specific quotes. Calling this tool when the user has specific dates in mind and wants to know whether the property is bookable will not surface the availability/quote — the user will then have to wait for a second round-trip to the availability tool.

Input: the id field from a search_stays result (opaque string starting with prop_, e.g. prop_69ce2ddcbf46061e4095778b). For a property the user has named directly, resolve the place name through resolve_destination and run a targeted search_stays first to obtain the id.

Optional include=["reviews_aggregate"] attaches a per-source breakdown of review counts and average ratings — useful when the user asks about overall sentiment or wants to see how each booking source rates the property. It summarizes ALL reviews (score + total count), so it is the right tool for "how is it rated".

Review texts are available via two includes, both deliberately capped to avoid token waste:

  • reviews_sample — up to 5 recent review texts. Enough to get the gist of what guests say.

  • reviews_extended — up to 20 recent review texts, for a deeper qualitative read. Supersedes reviews_sample when both are passed.

Reach for reviews_extended only when 5 are genuinely not enough — the returned list carries a reviews_meta block (returned, total_available, capped, note) that tells you how many texts exist and confirms the cap is intentional: the omitted reviews are older and the aggregate already reflects all of them, so you do NOT need to try to fetch everything. Note: review texts are returned only when called WITHOUT dates (the dated availability path does not carry them).

user_country, currency, and language carry the user's locale, not the property's. When this call carries dates (live prices), prices come back in currency if set, else derived from user_country, else USD — so pass user_country and/or currency whenever you know the user's location/currency; don't rely on the USD default. user_country and language also localize the web_url booking link. Language default is "en"; country default is "US".

All rating-like fields are on a 0-5 scale (Google Places-compatible): the top-level rating, reviews_aggregate.score_0_5, and each per-OTA score under distribution_by_ota.

Without dates this tool returns no price (price is null, offers empty) and availability_status is unknown (no dates were considered). The live quote, when needed, comes from check_property_availability.

web_url is a ready-to-open booking link for the property. Pass it verbatim when the user asks for a booking link — booking URLs are not reconstructed by hand.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
api_keyNoYour anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). Pass it in THIS field on every call — this is how the tool authenticates. If you don't have a key yet, first check your MCP client configuration, your persistent memory, and earlier in this conversation; otherwise call `b2a_get_key` to get one instantly (do not wait for a 401). Reuse the same key on every subsequent call. It is not a sensitive secret: no account, payment, or personal data is attached.
includeNoOptional enrichments, always a list — pass ["reviews_aggregate"], never the bare string. reviews_aggregate = score + total count + per-OTA distribution (summarizes ALL reviews). reviews_sample = up to 5 recent review texts. reviews_extended = up to 20 recent review texts (supersedes reviews_sample). The text list is intentionally capped to save tokens; reviews_meta declares returned vs available. Prefer reviews_sample and the aggregate; use reviews_extended only when a deeper qualitative read is genuinely needed.
currencyNoCurrency of the returned prices (ISO-4217, 3-letter uppercase, e.g. 'USD', 'EUR', 'GBP', 'CAD'). SET THIS (or `user_country`) to price in the user's currency — if you set NEITHER, prices default to USD. Prices come straight from the booking sources in this currency; never convert them yourself.
languageNoUser's UI language (2-letter lowercase). Drives the booking link language and server-rendered narrative; pass the language the user is speaking. Falls back to 'en'.
property_idYesOpaque property id (e.g. 'prop_69ce2ddcbf...') OR a bluepillow.com property page URL (e.g. 'https://www.bluepillow.com/search/68d1a2...') — the id is extracted automatically. Use the URL form when the user pasted a bluepillow.com link.
user_countryNoUser's country (ISO-3166 alpha-2 uppercase). Drives the booking-link locale AND, when `currency` is not set, the pricing currency (US->USD, CA->CAD, euro-area->EUR). Pass the user's own country, not the property's home country. Falls back to 'US' when omitted.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
nameYes
brandNo
chainNo
priceNo
starsNo
imagesNo
offersNo
ratingYes
web_urlNo
featuresNoStructured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when the endpoint path is active.
locationYes
amenitiesNo
cluster_idNo
dedup_metaNo
descriptionNoFree-text property description from the canonical source. Only populated when the endpoint path is active (use_bp_single_property_endpoint=True) and dates are present.
ota_coverageYes
rating_countNo
reviews_metaNoProvenance for reviews_sample on property detail: how many review texts were returned vs available, and that the cap is deliberate (token efficiency). null on search or when reviews were not requested.
property_typeYes
thumbnail_urlNo
reviews_sampleNo
reviews_aggregateNorating_count = reviews backing the score (OTA aggregate, e.g. 156). comment_count = readable review TEXTS available (e.g. 53), fetchable via reviews_sample/reviews_extended. They differ: most guests rate, fewer write text — do not conflate them.
availability_statusNoPer the dates passed in the request: available = live bookable quotes in offers (price is the curated best); unavailable = BP reported no rooms for these dates (offers=[], price=null); unknown = no dates considered (no price exists without a dated query).

TDQS

A4.9/5.0
Behavior5/5

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

Despite annotations already marking readOnlyHint=true and openWorldHint, the description adds substantial behavioral context: the 0-5 rating scale, the fact that price is null and availability_status is 'unknown' without dates, the intentional capping of review texts with a reviews_meta block, and the localization fallback chain for currency. There is 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 well-structured with clear sections and front-loaded key information, but it is verbose and repeats similar points (e.g., no price without dates, the contrast with check_property_availability) multiple times. Each sentence ultimately earns its place, but tightening would improve conciseness.

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 tool's complexity (6 parameters, multiple include options, date-dependent price behavior, sibling tool relationship), the description covers every aspect: the need for an id, the opt-in review paths, the cap on review texts with meta details, the localization logic, and the explicit pointer to the live-availability sibling. With an output schema present, return values need no further explanation.

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

Parameters5/5

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

Even though schema coverage is 100%, the description enriches the parameters significantly. It explains the include enum behavior in depth (reviews_aggregate vs sample vs extended, supersession, caps), clarifies that property_id accepts both opaque ids and URLs (auto-extraction), and details the interaction between user_country/currency/language for pricing and booking-link localization — all beyond the schema text.

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 the tool returns a static record for a specific property by id, enumerates the exact fields (amenity list, photos, booking sources, dedup metadata, location, headline rating), and explicitly contrasts with check_property_availability. This gives a specific verb+resource+scope and fully distinguishes it from sibling tools.

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?

The description explicitly says when to use this tool ('when the user wants to inspect or compare a specific option in depth... without committing to dates'), when NOT to use it (for live availability/quote), and names the alternative (check_property_availability). It also prescribes the workflow to obtain a property id via search_stays. This is beyond the minimum required.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Tools are mostly distinct: resolve_destination and discover_destinations_near both produce destination IDs but differ in input (name vs coordinates/radius), which the descriptions clarify well. get_property_details and check_property_availability are explicitly differentiated (static 'what is it like' vs live 'can I book for dates'). Minor overlap only between the two destination-resolution tools.

Naming Consistency2/5

Naming is inconsistent. Most tools use verb_object pattern (resolve_destination, search_stays, check_property_availability, get_property_details), but b2a_get_key breaks this entirely with its obscure 'b2a' prefix and mixed capitalization, and discover_destinations_near is inconsistent with the others (verb_plural instead of verb_single). The b2a_get_key name is notably cryptic and doesn't convey its purpose.

Tool Count5/5

Six tools is well-scoped for a hotel search/booker MCP server. Each tool fills a distinct role: key acquisition, destination resolution, area discovery, search/comparison, property details, and availability/pricing. No redundancy and no bloat.

Completeness4/5

The core workflow (resolve → search → compare → get details → check availability → book via link) is well covered. Minor gaps: there's no explicit cancellation/form-fill tool (though booking handoff via deeplink covers this) and no pagination-specific helper beyond cursors. Overall the travel journey is complete for a search-and-compare server.

Resources