Skip to main content
Glama

Server Details

Neutral hotel & stay price comparison for AI agents: live prices from 16+ booking sites. No signup.

Ownership verified
Status
Healthy
Uptime
100.0% over 64 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct action: resolve_destination maps a place name to an id, discover_destinations_near enumerates destinations near coordinates, search_stays finds properties, get_property_details returns static facts/reviews, check_property_availability quotes a specific stay window, and get_anonymous_key handles auth. The descriptions explicitly delineate the near-overlaps (search_stays vs check_property_availability, resolve_destination vs discover_destinations_near).

Naming Consistency5/5

All six names use a consistent snake_case verb_noun/verb_noun_qualifier pattern (get_anonymous_key, get_property_details, check_property_availability, discover_destinations_near, resolve_destination, search_stays). No mixed conventions or vague standalone verbs.

Tool Count5/5

Six tools is well-scoped for an accommodation comparator, with each tool earning its place across the discover→search→inspect→quote pipeline. No redundancy or filler.

Completeness4/5

The surface covers the full pre-booking lifecycle: auth, destination resolution/discovery, search, details, and live availability, with pagination handled by page.cursor. The only apparent gap is an explicit booking step, but this is an intentional deeplink handoff rather than a true dead end.

Available Tools

6 tools
check_property_availabilityCheck live availability and per-operator quotes for a stayA
Read-only
Inspect

Live availability and per-operator quote for a specific property over a specific stay window. Performs a live date-aware lookup against the BluePillow search layer, returns date-specific prices, rooms-left scarcity signals, breakfast-included and refundable flags, and a per-operator deep link to complete the booking.

Useful when the user has specific dates in mind for a property they already identified — typically via search_stays or get_property_details. The complementary get_property_details tool answers "what is this property like" with static facts; this tool answers "can I book it for these dates at what price" with live, date-specific data.

Follow-up questions about a property from an earlier search_stays result — is it still available, what does it cost for other dates or guests — use that result's id as property_id.

Required input: property_id (the id from a search_stays result, opaque string starting with prop_), dates (check_in + check_out, ISO 8601), and guests (adults / children / infants composition). Without these the live lookup cannot proceed.

Natural-language date references — "tonight", "this weekend", "next weekend", "the weekend of July 4", "Memorial Day weekend", "long weekend in May" — translate to concrete check_in / check_out values at the call site; concrete ISO dates also work. check_in is a date in the real-time calendar that is today or later; past values are rejected at the API boundary.

user_country, currency, and language carry the user's locale, not the property's. Prices are returned in currency if set, else derived from user_country, else USD — pass user_country and/or currency whenever you know the user's location/currency so the quote matches what they'll pay; don't rely on the USD default. user_country and language also localize the web_url booking link.

Response shape:

  • availability_status — available, unavailable, or unknown. Available means rooms confirmed at the operator level for the requested window; quote freely. Unavailable means no rooms for these dates — surface that explicitly to the user with a suggestion of alternate dates (there is no price for these dates).

  • offers[] — per-operator quotes. Each carries amount (total stay), amount_per_night (per-night), currency, breakfast_included, refundable, rooms_left, and deeplink_url. offers[0] is the best value for money as Blue Pillow ranks it: price weighed against what is included (breakfast, free cancellation) and the operator's historical reliability, with a small commercial component. It is not necessarily the cheapest — the full per-operator list is always in offers[], and sort=price_asc gives pure price order. Each deeplink_url is a BluePillow tracked-redirect URL (bluepillow.com/…) that records the click and forwards the user to the operator's booking page — pass it verbatim, never reconstruct it or replace it with a raw OTA link.

  • price — mirror of offers[0] for callers that just want the curated headline. null when unavailable (no price for these dates).

Per-night vs total — amount_per_night is per-night; amount on each offer is the total for the requested stay. Phrasings like "€X/night via Booking, breakfast included, €Y total" are unambiguous; bare numbers without a unit ("€192") get misread.

Scarcity signals: low rooms_left values (1-3) are useful cues — "1 room left at €X on Booking" reads naturally. Free cancellation (refundable=true) and breakfast-included are decision factors worth surfacing proactively when present on some offers but not others.

When all results across operators are unavailable, that's the signal to say so explicitly to the user and offer to widen the dates or look at alternatives.

For final booking confirmation, hand the user the corresponding deeplink_url (or the property's web_url) — booking URLs are not reconstructed by hand.

ParametersJSON Schema
NameRequiredDescriptionDefault
datesYesStay window. Natural-language references such as 'tonight', 'this weekend', 'the weekend of July 4', 'Memorial Day weekend' translate to concrete check_in / check_out at the call site. check_in is a date in the real-time calendar that is today or later — past values are rejected at the API boundary. Clock calibration: this schema was published in August 2026, so today is August 2026 OR LATER; an assumed 'today' in 2024/2025 is a stale training-time clock.
guestsYesGuest composition. Adults is required; children and infants default to zero.
api_keyNoAnonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call.
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; 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

ParametersJSON Schema
NameRequiredDescription
idYes
nameYes
brandNo
chainNo
priceNo
starsNo
imagesNo
offersNo
ratingYes
web_urlNo
featuresNoStructured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available.
locationYes
amenitiesNo
cluster_idNo
dedup_metaNo
descriptionNoFree-text property description, when the source provides one. Usually null on search results.
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_statusNoavailable = live bookable quotes in offers for the requested dates (price is the curated best); unavailable = no rooms reported for these dates (offers=[], price=null); unknown = availability not established, either because the call carried no dates or because the operators returned nothing conclusive (offers=[], price=null).

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly/openWorld/non-destructive); the description adds substantial behavioral context beyond them: live date-aware lookup, past-date rejection at the API boundary, the currency fallback chain and its USD default, the tracking nature of `deeplink_url` ('pass verbatim, never reconstruct'), and the curated ranking semantics of `offers[0]` (not necessarily cheapest, sort=price_asc for pure price order). It also prescribes explicit handling of the `unavailable` terminal state.

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?

Well front-loaded — purpose, then routing, then inputs, then response shape — with headers that make it skimmable. It is nonetheless long, and a few points are stated twice (booking URLs must not be hand-reconstructed appears in both the deeplink bullet and the closing line; the 'surface unavailable explicitly' instruction appears twice), so it is not maximally tight.

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 7-parameter, nested-object, availability-driven tool with an output schema, this covers everything an agent needs: required inputs, the three availability states and what each implies for the user, per-night vs total disambiguation, scarcity and refundability as decision factors, and the fallback behavior when all operators are unavailable.

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; the description nonetheless reinforces interpretively non-obvious points — that `user_country`/`currency`/`language` are the USER's locale and not the property's, that omitting both currency inputs silently yields USD, and that `property_id` may be a raw prop_ id or a pasted bluepillow.com URL. It doesn't add much beyond the schema text, but the locale-vs-property framing and the 'don't rely on the USD default' instruction carry real selection value.

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 opening sentence gives a specific verb (live lookup) and resource (availability + per-operator quotes for a stay), with the exact scope of the window. It explicitly distinguishes itself from the sibling `get_property_details` — 'what is this property like' (static) vs 'can I book it for these dates at what price' (live) — so an agent can route without opening either schema.

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?

States the triggering condition ('user has specific dates in mind for a property they already identified — typically via search_stays or get_property_details') and names the alternative tools and follow-up scenarios (checking other dates/guests, reusing a prior `id`). This is explicit when-to-use plus when-to-use-something-else.

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

discover_destinations_nearDiscover destinations near a pointA
Read-only
Inspect

Curated destinations — cities, neighborhoods, airports, points of interest — within a radius of a geographic point, for use as a destination_id in subsequent search_stays calls. Useful when coordinates are already in hand (from world knowledge, from a previous tool result, or directly from the user) and the agent needs to enumerate which curated destinations cover that area before searching for properties.

Also useful as a fan-out entry point for region-level intents — broad areas such as 'Tuscany', 'Pacific Northwest', 'New England', or 'Central Europe' — where the agent can pass an approximate regional centroid and surface a list of sub-destinations the user may then narrow down to before a focused search.

Returns up to 5 candidates ordered by distance. The radius defaults to 5 km; widens up to 50 km for broader queries.

ParametersJSON Schema
NameRequiredDescriptionDefault
latYesLatitude of the centre point, decimal degrees (WGS84). Typically the coordinates of a city or region already known from world knowledge or from an earlier resolve_destination call.
lonYesLongitude of the centre point, decimal degrees (WGS84). Negative west of Greenwich.
typeNoOptional filter; same semantics as resolve_destination. Areas are returned only when `area` is asked for explicitly.
api_keyNoAnonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call.
languageNoLanguage of the returned destination names (2-letter lowercase). Pass the language the user is speaking; defaults to 'en'.en
radius_kmNoSearch radius in km from the point. Defaults to 5 km (city-center scope).

Output Schema

ParametersJSON Schema
NameRequiredDescription
candidatesYes
total_matchesYes
total_matches_capped_atNo

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), so the description's added behavioral detail is what matters here: it discloses the hard cap of 5 candidates, distance ordering, the 5 km default radius, and that the radius widens up to 50 km for broad queries. It omits what happens on zero results, but the disclosure is well beyond the annotation baseline.

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 definition, then usage contexts, then return/radius behavior. Three paragraphs is slightly long for the payload, but each sentence contributes a distinct fact (destination types, coordinate sources, fan-out pattern, cap, radius range) rather than restating.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description still supplies the result count and ordering. For a read-only discovery tool with full schema coverage, nothing essential is missing, though edge cases like no matches within radius are unaddressed.

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 every parameter including enums and the api_key requirement is already documented; baseline is 3. The description adds only marginal parameter meaning (radius widening for broad queries), which the schema already implies via its min/max bounds.

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?

Names a specific verb (discover) and resource (curated destinations: cities, neighborhoods, airports, POIs) plus the radius constraint, and states the output's downstream role as a destination_id for search_stays. This clearly separates it from resolve_destination and search_stays without opening either schema.

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 two concrete when-to-use scenarios: coordinates already in hand (world knowledge, prior tool result, user), and region-level fan-out for broad areas like 'Tuscany'. It does not explicitly name resolve_destination as the alternative to use when you have a name instead of coordinates, leaving that routing to inference.

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

get_anonymous_keyGet an anonymous API key for Blue Pillow Hotels & StaysAInspect

Issues a free anonymous key for Blue Pillow Hotels & Stays, with no account or sign-up. The other tools of this server take the key in their api_key argument. A key does not expire, so the same key can be used for later calls; calling this tool again issues a new one. Keys carry per-key rate limits and let Blue Pillow count usage and booking-link referrals per key, as described in the privacy policy (https://b2a.bluepillow.com/legal/privacy).

Optional label and agent (max 64 chars each) are stored with the key to name the client that requested it (e.g. 'claude-desktop', 'chatgpt', 'cursor-ide'); they should not contain personal data and do not affect rate limits or capabilities. Integrators who need higher limits can write to info@bluepillow.com.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentNoOptional identifier, stored with the key, of the agent platform requesting it (e.g. 'claude-code', 'chatgpt', 'cursor-ide'). Do not include personal data. Free-form, max 64 chars.
labelNoOptional name stored with the key, such as the client app requesting it (e.g. 'claude-desktop' or 'chatgpt'). Do not include personal data. Not a secret, not validated for uniqueness.

Output Schema

ParametersJSON Schema
NameRequiredDescription
keyYesThe anonymous key (prefix 'pk_anon_'), used as the `api_key` argument of the other tools.
rate_limitNoQuota attached to this key, when the issuer reported one.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare the mutation profile (readOnlyHint false, idempotentHint false, destructiveHint false), and the description adds substantial non-obvious behavior beyond them: keys never expire, repeated calls mint a new key rather than reusing one, keys carry per-key rate limits, and usage/referrals are tracked per key with a privacy-policy link. That is exactly the context an agent needs before treating the key as durable state.

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 action, then behavior, then the optional parameters and support contact. Slightly long and the privacy-policy URL is parenthetical, but each sentence carries actionable information and nothing is padded.

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?

With an output schema present, the return payload need not be described. The description covers provenance, lifecycle (non-expiring, re-issuable), rate-limit implications, parameter constraints, and an escalation route, leaving no material gap for calling the 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 coverage is 100%, so the two optional params are already documented, but the description still adds meaning the schema does not: the labels are metadata only, do not affect rate limits or capabilities, and should not contain personal data. It corroborates rather than merely repeats 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?

The description states a specific verb and resource ('issues a free anonymous key for Blue Pillow Hotels & Stays') and immediately distinguishes it from all siblings by noting they consume the key via their `api_key` argument. An agent can tell this is the entry-point credential tool without opening any other schema.

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 gives clear context on when this is needed (no account/sign-up, key feeds the other tools' api_key), and clarifies the repeat-call case ('calling this tool again issues a new one') plus the escalation path (email for higher limits). It stops short of an explicit 'call this before search_stays/get_property_details' ordering instruction, so it is clear but not fully prescriptive.

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

get_property_detailsGet property details — static facts, no live availabilityA
Read-only
Inspect

Details and guest reviews for one specific property — hotel, B&B, hostel, apartment, villa — identified by its id. Answers questions such as what guests think of it, whether it is clean, quiet or comfortable, the most common complaints, how the breakfast is, which facilities it offers, where exactly it is, or how it compares with another option. It also serves follow-up questions about a property returned earlier by search_stays: the id of that result is the property_id here.

Returns the amenity list, photos, booking sources, location and the headline rating (rating + rating_count). Guest-review data is added through include:

  • reviews_aggregate — score, total count and per-source breakdown; it summarizes all reviews.

  • reviews_sample — up to 5 recent review texts.

  • reviews_extended — up to 20 recent review texts for a deeper read; it supersedes reviews_sample. reviews_meta reports how many texts exist and that the cap is deliberate: the omitted texts are older, and the aggregate already reflects them.

It takes no dates and carries no price: a price only exists for a concrete stay window, which is what check_property_availability quotes. In the response price is null, offers is empty and availability_status is unknown.

Input: property_id is the id of a search_stays result (an opaque string starting with prop_) or a bluepillow.com property URL. For a property known only by name, resolve_destination and a targeted search_stays return its id.

user_country, currency and language carry the user's locale and localize the web_url link to the property page. Language default is "en"; country default is "US". All rating fields are on a 0-5 scale.

ParametersJSON Schema
NameRequiredDescriptionDefault
api_keyNoAnonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call.
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.
currencyNoUser's preferred currency (ISO-4217, 3-letter uppercase, e.g. 'USD', 'EUR'), carried into the `web_url` booking link. This tool returns no prices; live quotes come from `check_property_availability`.
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). Localizes the `web_url` booking link. Pass the user's own country, not the property's home country. Falls back to 'US' when omitted.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYes
nameYes
brandNo
chainNo
priceNo
starsNo
imagesNo
offersNo
ratingYes
web_urlNo
featuresNoStructured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available.
locationYes
amenitiesNo
cluster_idNo
dedup_metaNo
descriptionNoFree-text property description, when the source provides one. Usually null on search results.
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_statusNoavailable = live bookable quotes in offers for the requested dates (price is the curated best); unavailable = no rooms reported for these dates (offers=[], price=null); unknown = availability not established, either because the call carried no dates or because the operators returned nothing conclusive (offers=[], price=null).

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, non-destructive, open-world), and the description adds substantive behavior: price is null, offers empty, availability_status unknown in the response; review text is deliberately capped with reviews_meta declaring returned-vs-available; reviews_extended supersedes reviews_sample. That is real context beyond structured fields.

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 purpose, then the no-price caveat, then the include semantics and id provenance. It is somewhat long and the include list is restated almost verbatim from the schema description, which is redundant, but each remaining 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?

Given an output schema exists, return values need not be enumerated, yet the description still flags the key response shape (null price, empty offers, unknown availability) so an agent won't misread the payload. Combined with id provenance and locale defaults, nothing needed to call this correctly is missing.

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%, but the description still adds semantics the schema doesn't force: property_id is the id of a search_stays result or a pasted URL, and user_country/currency/language localize only the web_url link rather than filtering results. The include preference ordering (prefer reviews_sample) is genuinely useful, though much of the enum detail is duplicated verbatim from 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?

Specific verb+resource ('Details and guest reviews for one specific property') with an explicit scope boundary against the nearest sibling: 'static facts, no live availability' and 'It takes no dates and carries no price'. An agent can distinguish this from check_property_availability without opening either schema.

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?

Explicit when-to-use (follow-up questions about a property returned by search_stays, qualitative review questions), when-not (anything price- or date-dependent), and named alternatives (check_property_availability for quotes, resolve_destination + search_stays for name-only lookups). Routing is fully specified.

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

resolve_destinationResolve destination name to idA
Read-only
Inspect

Converts a destination name into a destination id usable in search_stays. The canonical entry point when the user's request mentions a place name and coordinates are not already known from a prior call in this session. If coordinates are already in hand from an earlier tool result, passing them directly to search_stays skips this resolver step.

Accepts cities, neighborhoods, airports, points of interest, and named areas such as islands or districts ('Tenerife', 'Crete', 'Trastevere'), written locally or in English. Names are matched against Blue Pillow's own place slugs, which exist for English, Italian, German and Spanish; in other languages the English name is the most reliable. Accents are optional — 'São Paulo' and 'Sao Paulo' resolve alike. A qualifier after the name is tolerated ('Austin, Texas'). The country parameter disambiguates names that occur in multiple places (for example Springfield MA vs Springfield IL vs Springfield MO).

The type parameter narrows the kind of destination returned. poi is the narrowest match and has partial coverage on the comparator side; when the agent's own geographic knowledge can already geocode the POI to lat/lon, passing coordinates to search_stays is the more reliable path. An area candidate can be large: its location.default_radius_km says how far a search on its id reaches (an island's may include its neighbours); when the user wants one part of it, coordinates of that part are the tighter search.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesDestination name in English or canonical local form (not a translation).
typeNoDestination kind. city: primary urban unit (default). neighborhood: quarter/borough. airport: airport as spatial reference for stays nearby. poi: point of interest as a spatial anchor for nearby-accommodation lookup — not a tourism/attraction database; narrowest match with partial coverage. When the agent already knows the POI's lat/lon from world knowledge, `search_stays` with coordinates is the more reliable path. area: a named area the comparator does not class as a city — an island, a district, a region (Tenerife, Crete, Kato Paphos); matched by exact name only.
api_keyNoAnonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call.
countryNoCountry: ISO-3166 alpha-2 (preferred), alpha-3, or extended name in any supported language. Unrecognized values are silently ignored (fail-open).
languageNoRender destination names + breadcrumbs in this language.en

Output Schema

ParametersJSON Schema
NameRequiredDescription
candidatesYes
total_matchesYes
total_matches_capped_atNo
disambiguation_recommendedYes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered; the description adds real behavioral context beyond that: slug-based matching limited to English/Italian/German/Spanish, accent-insensitivity, tolerance of qualifiers, `poi` partial coverage on the comparator side, and the fact that an `area` candidate's `location.default_radius_km` may reach neighbouring places. It stops short of saying what happens when a name fails to resolve, which is the main gap.

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?

Three paragraphs, front-loaded with the core purpose and routing rule before the matching and type detail. Efficient for the semantic complexity involved, though the `poi` caveat is restated in both the description and the schema's `type` field, which is redundant.

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?

An output schema exists, so return values need not be explained, and the description covers routing, matching rules, disambiguation and the `area` radius caveat. The one missing piece is failure behavior — what the agent should do if a name does not resolve — which matters for a resolver the whole search flow depends on.

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 baseline is 3, but the description earns more by explaining *why* `country` matters (Springfield MA vs IL vs MO) and how `type` narrows results, including the strategic advice to bypass the resolver for well-known POIs. Some of this (poi partial coverage) is duplicated verbatim in the schema rather than added.

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 precise verb+resource ('Converts a destination name into a destination id usable in `search_stays`') and immediately differentiates itself from the sibling it feeds. An agent can tell this resolver apart from `search_stays` and `discover_destinations_near` without opening any schema.

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?

Gives an explicit entry-point rule ('canonical entry point when the user's request mentions a place name and coordinates are not already known') and an explicit when-not rule with the alternative ('If coordinates are already in hand... passing them directly to `search_stays` skips this resolver step'). It also adds a second routing condition for `poi` types. Nothing is left to inference.

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

search_staysSearch accommodation — compare offers across operatorsA
Read-only
Inspect

Multi-operator accommodation comparator for a geographic area and a stay: dates (required), guests and optional filters. Returns a ranked list of properties — hotels, B&Bs, apartments, villas, hostels and more — with the booking sites that offer each one and their live availability and per-operator price for the requested dates. Questions about one property found here (guest opinions, facilities, a live re-quote) are served by get_property_details and check_property_availability with that result's id.

Dates: natural-language references ("this weekend", "the weekend of July 4", "long weekend in May") translate to concrete check_in / check_out values at the call site; ISO dates also work.

Locale: user_country, currency and language carry the user's locale, not the destination's. Prices come back in currency if set, otherwise in the currency of user_country (US→USD, CA→CAD, GB→GBP, euro-area→EUR), otherwise USD. Each offer is quoted by its operator in that currency; nothing is converted. user_country and language also localize the booking link.

Each result carries:

  • location.lat / location.lon, suitable for plotting the results on a map.

  • thumbnail_url (first photo, or null) and images, capped to one photo; get_property_details returns the full gallery.

  • web_url, a link to the property page with the stay already encoded.

  • price and offers[]: the live quote for the requested dates, present only when availability was confirmed. Each offer has ota, amount (total stay), amount_per_night, currency, breakfast_included, refundable, rooms_left and deeplink_url — a Blue Pillow tracked link that records the click and forwards to the operator's booking page; it is what attributes the booking to Blue Pillow, which a raw operator URL does not. price mirrors offers[0], Blue Pillow's best value for money (price weighed against breakfast, free cancellation and operator reliability, with a small commercial component), not necessarily the cheapest; sort=price_asc orders by price alone. There is no date-agnostic "from" price.

  • availability_status: available (live quotes in offers), unavailable (no rooms for those dates) or unknown (the operators returned nothing conclusive — not evidence that the property is full). The default availability_mode=strict returns only available results; include_unavailable also returns the other two.

Reading the numbers: amount_per_night is per night and amount is the total stay, so a quote reads clearly with its unit ("€X/night via Booking, €Y total"). rooms_left signals scarcity; refundable and breakfast_included often separate otherwise similar options.

Ratings are on a 0-5 scale (rating, reviews_aggregate.score_0_5, review scores and filters.min_rating; "8 out of 10" is 4.0). Upstream scores arrive rounded, so rating is coarse and reads best together with rating_count. rating, stars and rating_count may be 0 or absent in this list even when the property has them; get_property_details returns the fuller reviews_aggregate. Here reviews_aggregate carries score_0_5, rating_count (reviews behind the score) and comment_count (review texts available) — two different magnitudes. include=["reviews_sample"] adds up to 5 recent review texts per property, useful for qualitative criteria ("great breakfast", "quiet area"); a deeper read on one property is get_property_details with reviews_extended.

Filters: filters.min_rating and filters.price_max_eur narrow the results; filters.property_types and filters.amenities rank rather than filter, so each result's property_type and amenities show what it actually is. Property type tokens: hotel, apartment, house, villa, bb, hostel, farmstay, holiday-home (common Italian and English synonyms are accepted). Common amenity codes: wi-fi, parking, pool, air-conditioning, kitchen, garden, pets-allowed, for-families, facilities-for-disabled, non-smoking-only.

Location modes:

  • coordinates: a known lat/lon (default radius 5 km, up to 50 km; beyond that bbox or a parent destination fits better).

  • destination_id: the opaque id from resolve_destination, passed verbatim.

  • poi_id: the opaque id of a point of interest, from resolve_destination or discover_destinations_near.

  • bbox: an explicit map rectangle. A property is not a location: get_property_details covers a known property.

Pagination: the next_cursor of a response goes into page.cursor for the next page.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPagination. `limit` caps results per page (1-100). To fetch the next page pass `cursor` with the `next_cursor` value from the previous response — cursors are opaque and are never constructed by hand.
sortNoResult ordering. score_desc (default) is the balanced relevance ranking and suits most requests; price_asc when the user asked for the cheapest; rating_desc when they asked for the best-reviewed; conversion_desc favours what comparable travellers actually booked.
datesYesCheck-in and check-out dates (ISO 8601, YYYY-MM-DD). Natural-language references — 'tonight', 'this weekend', 'the weekend of July 4', 'Memorial Day weekend', 'long weekend in May' — translate to concrete check_in / check_out values at the call site. The comparator only serves future stays: check_in is a date in the real-time calendar that is today or later. A reference like 'the weekend of June 2' resolves to the next occurrence after today, never a past anniversary; if the current year is unclear, confirm with the user before calling. Clock calibration: this schema was published in August 2026, so today is August 2026 OR LATER (likely later — schemas outlive their publish date). An assumed 'today' in 2024/2025 is a stale training-time clock; years before 2026 are always in the past. Past check_in values are rejected at the API boundary with a hint carrying the actual current date.
guestsYesParty composition. `adults` is required; give `children_ages` (one age per child, 0-17) rather than a child count — operators price by age. `rooms` defaults to 1; raise it when the party needs separate rooms rather than one shared.
api_keyNoAnonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call.
filtersNoStructured narrowing applied server-side, before ranking. Prefer these over filtering the results yourself: they run across the whole inventory, not just the page you received. Qualitative criteria that do not map here ("quiet", "great breakfast") are better served by include=['reviews_sample'].
includeNoOptional enrichments, always a list — pass ["reviews_sample"], never the bare string. 'reviews_sample' attaches the 5 most recent individual reviews per property — use for qualitative queries (breakfast, service, ...). One extra Mongo round-trip per page; omit by default.
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, which may not be the user's. Prices come straight from the booking sources in this currency; never convert them yourself. Each offer reflects the currency its operator actually quoted.
languageNoUser's UI language (2-letter lowercase). Drives the booking link language and any server-rendered narrative content. Pass the language the user is currently speaking. Falls back to 'en' when omitted.
locationYesWhere to search, as a {type, value} pair. Use destination_id for a place resolved via resolve_destination, poi_id for a point of interest, coordinates for a known lat/lon, or bbox for an explicit map rectangle. A property is NOT a location — use get_property_details for a known property.
user_countryNoUser's country (ISO-3166 alpha-2 uppercase). Drives the booking-link locale (the landing page rendered when the user clicks `web_url`) AND, when `currency` is not set, the pricing currency (US->USD, CA->CAD, euro-area->EUR). Pass the user's own country, not the destination's. Falls back to 'US' when omitted.
availability_modeNostrict (default): return ONLY properties available for the requested dates. include_unavailable: also return properties with no availability (each tagged availability_status). Use strict unless the user explicitly wants to see sold-out options.
include_overbudgetNoOpt-in. When few available results fit the budget, also return (in alternatives.overbudget) available properties in the same area just above price_max_eur. Requires filters.price_max_eur.
include_out_of_boundsNoOpt-in. When the requested area yields few available results, also return (in alternatives.out_of_bounds) properties just outside the area, within the original budget. Present these explicitly as alternatives, never mixed with primary results.

Output Schema

ParametersJSON Schema
NameRequiredDescription
pageYes
resultsYes
metadataYes
alternativesNo

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, but the description adds substantial load-bearing behavior: prices are never converted (operator-quoted currency), default USD/US fallbacks, `price` mirrors `offers[0]` and is a value ranking not the cheapest, `unknown` availability is not proof of being full, and filters rank rather than filter. These are non-obvious traits an agent would otherwise get wrong.

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

Conciseness3/5

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

The description is well front-loaded and organized into labeled sections (Dates, Locale, Filters, Location modes, Pagination), but it is very long and spends several paragraphs cataloging per-result fields (`thumbnail_url`, `images`, `reviews_aggregate`, `offers[]`) even though an output schema exists. Much of that is duplication of the structured contract rather than added selection value.

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 14-parameter, nested, open-world comparator, the description covers the hard parts — date resolution and clock calibration, currency/locale semantics, ranking-vs-filtering behavior, availability states, and pagination — while the output schema carries the return shape. Nothing an agent needs to invoke it correctly is missing.

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 semantics the schema doesn't foreground: locale parameters describe the user not the destination, `include=['reviews_sample']` is for qualitative criteria, and `next_cursor` feeds `page.cursor`. These genuinely extend parameter meaning beyond the structured fields.

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 opening sentence names a specific verb and resource ('multi-operator accommodation comparator for a geographic area and a stay') and explicitly scopes it as a cross-operator search rather than a single-property lookup. It distinguishes itself from siblings by naming `get_property_details` and `check_property_availability` for single-property questions. An agent can select it without opening the schema.

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?

It gives explicit when-to-use routing: single-property follow-ups go to `get_property_details`/`check_property_availability`, location resolution goes through `resolve_destination`, and `availability_mode=strict` is the default unless the user wants sold-out options. It also maps user intents to `sort` values ('cheapest' → price_asc, 'best-reviewed' → rating_desc). Little is left to inference.

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.

  1. 6 tool updates
    • Changedcheck_property_availability1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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 `get_anonymous_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."New value: +"Anonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call."
    • Changeddiscover_destinations_near1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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 `get_anonymous_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."New value: +"Anonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call."
    • Changedget_anonymous_key1 field changed
      • changedOutput schema / properties / key / description
        Previous value: -"The anonymous API key (prefix 'pk_anon_'). Long-lived and reusable: pass it as the `api_key` argument on every subsequent tool call, and keep it across sessions."New value: +"The anonymous key (prefix 'pk_anon_'), used as the `api_key` argument of the other tools."
    • Changedget_property_details1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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 `get_anonymous_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."New value: +"Anonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call."
    • Changedresolve_destination1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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 `get_anonymous_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."New value: +"Anonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call."
    • Changedsearch_stays1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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 `get_anonymous_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."New value: +"Anonymous key for this server (format 'pk_anon_…'), as returned by `get_anonymous_key`. Required by this tool; the same key works for every call."
  2. 7 tool updates
    • Removedb2a_get_key
    • Changedcheck_property_availability1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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."New value: +"Your 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 `get_anonymous_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."
    • Changeddiscover_destinations_near1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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."New value: +"Your 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 `get_anonymous_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."
    • Addedget_anonymous_key
    • Changedget_property_details1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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."New value: +"Your 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 `get_anonymous_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."
    • Changedresolve_destination1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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."New value: +"Your 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 `get_anonymous_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."
    • Changedsearch_stays1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your 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."New value: +"Your 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 `get_anonymous_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."
  3. 3 tool updates
    • Changedcheck_property_availability3 fields changed
      • changedOutput schema / properties / availability_status / description
        Previous value: -"Per 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)."New value: +"available = live bookable quotes in offers for the requested dates (price is the curated best); unavailable = no rooms reported for these dates (offers=[], price=null); unknown = availability not established, either because the call carried no dates or because the operators returned nothing conclusive (offers=[], price=null)."
      • changedOutput schema / properties / description / description
        Previous value: -"Free-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."New value: +"Free-text property description, when the source provides one. Usually null on search results."
      • changedOutput schema / properties / features / description
        Previous value: -"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when the endpoint path is active."New value: +"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available."
    • Changedget_property_details3 fields changed
      • changedOutput schema / properties / availability_status / description
        Previous value: -"Per 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)."New value: +"available = live bookable quotes in offers for the requested dates (price is the curated best); unavailable = no rooms reported for these dates (offers=[], price=null); unknown = availability not established, either because the call carried no dates or because the operators returned nothing conclusive (offers=[], price=null)."
      • changedOutput schema / properties / description / description
        Previous value: -"Free-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."New value: +"Free-text property description, when the source provides one. Usually null on search results."
      • changedOutput schema / properties / features / description
        Previous value: -"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when the endpoint path is active."New value: +"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available."
    • Changedsearch_stays9 fields changed
      • changedOutput schema / properties / alternatives / properties / out_of_bounds / items / properties / availability_status / description
        Previous value: -"Per 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)."New value: +"available = live bookable quotes in offers for the requested dates (price is the curated best); unavailable = no rooms reported for these dates (offers=[], price=null); unknown = availability not established, either because the call carried no dates or because the operators returned nothing conclusive (offers=[], price=null)."
      • changedOutput schema / properties / alternatives / properties / out_of_bounds / items / properties / description / description
        Previous value: -"Free-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."New value: +"Free-text property description, when the source provides one. Usually null on search results."
      • changedOutput schema / properties / alternatives / properties / out_of_bounds / items / properties / features / description
        Previous value: -"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when the endpoint path is active."New value: +"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available."
      • changedOutput schema / properties / alternatives / properties / overbudget / items / properties / availability_status / description
        Previous value: -"Per 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)."New value: +"available = live bookable quotes in offers for the requested dates (price is the curated best); unavailable = no rooms reported for these dates (offers=[], price=null); unknown = availability not established, either because the call carried no dates or because the operators returned nothing conclusive (offers=[], price=null)."
      • changedOutput schema / properties / alternatives / properties / overbudget / items / properties / description / description
        Previous value: -"Free-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."New value: +"Free-text property description, when the source provides one. Usually null on search results."
      • changedOutput schema / properties / alternatives / properties / overbudget / items / properties / features / description
        Previous value: -"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when the endpoint path is active."New value: +"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available."
      • changedOutput schema / properties / results / items / properties / availability_status / description
        Previous value: -"Per 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)."New value: +"available = live bookable quotes in offers for the requested dates (price is the curated best); unavailable = no rooms reported for these dates (offers=[], price=null); unknown = availability not established, either because the call carried no dates or because the operators returned nothing conclusive (offers=[], price=null)."
      • changedOutput schema / properties / results / items / properties / description / description
        Previous value: -"Free-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."New value: +"Free-text property description, when the source provides one. Usually null on search results."
      • changedOutput schema / properties / results / items / properties / features / description
        Previous value: -"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when the endpoint path is active."New value: +"Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available."
  4. 2 tool updates
    • Changedb2a_get_key2 fields changed
      • changedInput schema / properties / agent / description
        Previous value: -"Optional agent identifier recorded on the key — useful when an agent platform wants to attribute issuance to itself (e.g. 'claude-code', 'cursor-ide'). Free-form, max 64 chars."New value: +"Optional identifier, stored with the key, of the agent platform requesting it (e.g. 'claude-code', 'cursor-ide'). Do not include personal data. Free-form, max 64 chars."
      • changedInput schema / properties / label / description
        Previous value: -"Optional free-form label recorded on the key for observability (e.g. 'claude-desktop' or a user handle). Not a secret, not validated for uniqueness."New value: +"Optional name stored with the key, such as the client app requesting it (e.g. 'claude-desktop'). Do not include personal data. Not a secret, not validated for uniqueness."
    • Changedget_property_details2 fields changed
      • changedInput schema / properties / currency / description
        Previous value: -"Currency 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."New value: +"User's preferred currency (ISO-4217, 3-letter uppercase, e.g. 'USD', 'EUR'), carried into the `web_url` booking link. This tool returns no prices; live quotes come from `check_property_availability`."
      • changedInput schema / properties / user_country / description
        Previous value: -"User'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."New value: +"User's country (ISO-3166 alpha-2 uppercase). Localizes the `web_url` booking link. Pass the user's own country, not the property's home country. Falls back to 'US' when omitted."
  5. 2 tool updates
    • Changeddiscover_destinations_near3 fields changed
      • changedInput schema / properties / type / description
        Previous value: -"Optional filter; same semantics as resolve_destination."New value: +"Optional filter; same semantics as resolve_destination. Areas are returned only when `area` is asked for explicitly."
      • changedInput schema / properties / type / enum
        Previous value: -[
        -  "city",
        -  "neighborhood",
        -  "airport",
        -  "poi"
        -]New value: +[
        +  "city",
        +  "neighborhood",
        +  "airport",
        +  "poi",
        +  "area"
        +]
      • changedOutput schema / properties / candidates / items / properties / type / enum
        Previous value: -[
        -  "city",
        -  "neighborhood",
        -  "airport",
        -  "poi"
        -]New value: +[
        +  "city",
        +  "neighborhood",
        +  "airport",
        +  "poi",
        +  "area"
        +]
    • Changedresolve_destination3 fields changed
      • changedInput schema / properties / type / description
        Previous value: -"Destination kind. city: primary urban unit (default). neighborhood: quarter/borough. airport: airport as spatial reference for stays nearby. poi: point of interest as a spatial anchor for nearby-accommodation lookup — not a tourism/attraction database; narrowest match with partial coverage. When the agent already knows the POI's lat/lon from world knowledge, `search_stays` with coordinates is the more reliable path."New value: +"Destination kind. city: primary urban unit (default). neighborhood: quarter/borough. airport: airport as spatial reference for stays nearby. poi: point of interest as a spatial anchor for nearby-accommodation lookup — not a tourism/attraction database; narrowest match with partial coverage. When the agent already knows the POI's lat/lon from world knowledge, `search_stays` with coordinates is the more reliable path. area: a named area the comparator does not class as a city — an island, a district, a region (Tenerife, Crete, Kato Paphos); matched by exact name only."
      • changedInput schema / properties / type / enum
        Previous value: -[
        -  "city",
        -  "neighborhood",
        -  "airport",
        -  "poi"
        -]New value: +[
        +  "city",
        +  "neighborhood",
        +  "airport",
        +  "poi",
        +  "area"
        +]
      • changedOutput schema / properties / candidates / items / properties / type / enum
        Previous value: -[
        -  "city",
        -  "neighborhood",
        -  "airport",
        -  "poi"
        -]New value: +[
        +  "city",
        +  "neighborhood",
        +  "airport",
        +  "poi",
        +  "area"
        +]
  6. 1 tool update
    • Changedsearch_stays1 field changed
      • changedInput schema / properties / filters / properties / property_types / description
        Previous value: -"Canonical tokens: hotel, apartment, house, villa, bb, hostel, farmstay, holiday-home. Italian/English synonyms (agriturismo, bnb, appartamento, casa, ...) are accepted and normalized server-side."New value: +"Preferred property types. Like `amenities`, this steers rather than excludes: the types listed here come first and a minority of other types can still appear in the page. Read each result's `property_type` when the distinction matters to the user. Canonical tokens: hotel, apartment, house, villa, bb, hostel, farmstay, holiday-home. Italian/English synonyms (agriturismo, bnb, appartamento, casa, ...) are accepted and normalized server-side."
  7. 1 tool update
    • Changedsearch_stays1 field changed
      • changedInput schema / properties / filters / properties / amenities / description
        Previous value: -"Required amenity codes — property must have ALL listed (AND semantics). Common: wi-fi, parking, pool, air-conditioning, kitchen, garden, pets-allowed, for-families, facilities-for-disabled, non-smoking-only."New value: +"Preferred amenity codes. This ranks, it does not filter: properties declaring every code listed here come first and nothing is dropped, because upstream declarations are incomplete — an absent code is not evidence the service is missing. Read each result's `amenities` to see what is actually declared. Common: wi-fi, parking, pool, air-conditioning, kitchen, garden, pets-allowed, for-families, facilities-for-disabled, non-smoking-only."
  8. 2 tool updates
    • Changedget_property_details1 field changed
      • changedInput schema / properties / include / description
        Previous value: -"Optional enrichments. 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."New value: +"Optional 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."
    • Changedsearch_stays4 fields changed
      • changedInput schema / properties / include / description
        Previous value: -"Optional enrichments. 'reviews_sample' attaches the 5 most recent individual reviews per property — use for qualitative queries (breakfast, service, ...). One extra Mongo round-trip per page; omit by default."New value: +"Optional enrichments, always a list — pass [\"reviews_sample\"], never the bare string. 'reviews_sample' attaches the 5 most recent individual reviews per property — use for qualitative queries (breakfast, service, ...). One extra Mongo round-trip per page; omit by default."
      • changedInput schema / properties / location / properties / type / description
        Previous value: -"property_id is NOT supported here; use get_property_details."New value: +"Selects the shape of value: destination_id and poi_id take an id string, coordinates takes {lat, lon, radius_km?}, bbox takes {nw: [lat,lon], se: [lat,lon]}. property_id is NOT supported here; use get_property_details."
      • addedInput schema / properties / location / properties / value / anyOf
        Added value: +[
        +  {
        +    "description": "destination_id/poi_id: opaque id string from resolve_destination or discover_destinations_near (e.g. 'dest_590c54056664cf2c60c5c2f6'). Pass it verbatim — the 'dest_'/'poi_' prefix is accepted. NEVER pass a free-form name like 'Ancona'; the API rejects bad identifiers with 400 invalid_request.",
        +    "type": "string"
        +  },
        +  {
        +    "additionalProperties": false,
        +    "description": "coordinates: a known point, searched within radius_km.",
        +    "properties": {
        +      "lat": {
        +        "description": "Latitude in decimal degrees.",
        +        "maximum": 90,
        +        "minimum": -90,
        +        "type": "number"
        +      },
        +      "lon": {
        +        "description": "Longitude in decimal degrees.",
        +        "maximum": 180,
        +        "minimum": -180,
        +        "type": "number"
        +      },
        +      "radius_km": {
        +        "description": "Search radius in km (default 5).",
        +        "exclusiveMinimum": 0,
        +        "type": "number"
        +      }
        +    },
        +    "required": [
        +      "lat",
        +      "lon"
        +    ],
        +    "type": "object"
        +  },
        +  {
        +    "additionalProperties": false,
        +    "description": "bbox: an explicit map rectangle, given by its north-west and south-east corners.",
        +    "properties": {
        +      "nw": {
        +        "description": "North-west corner as [lat, lon].",
        +        "items": {
        +          "type": "number"
        +        },
        +        "maxItems": 2,
        +        "minItems": 2,
        +        "type": "array"
        +      },
        +      "se": {
        +        "description": "South-east corner as [lat, lon].",
        +        "items": {
        +          "type": "number"
        +        },
        +        "maxItems": 2,
        +        "minItems": 2,
        +        "type": "array"
        +      }
        +    },
        +    "required": [
        +      "nw",
        +      "se"
        +    ],
        +    "type": "object"
        +  }
        +]
      • changedInput schema / properties / location / properties / value / description
        Previous value: -"Shape depends on type:\n- destination_id/poi_id: opaque id string from resolve_destination or discover_destinations_near (e.g. 'dest_590c54056664cf2c60c5c2f6'). Pass it verbatim — the 'dest_'/'poi_' prefix is accepted. NEVER pass a free-form name like 'Ancona'; the API rejects bad identifiers with 400 invalid_request.\n- coordinates: {lat, lon, radius_km?} (radius_km default 5).\n- bbox: {nw: [lat,lon], se: [lat,lon]}."New value: +"Shape depends on type — see each option below."
  9. 3 tool updates
    • Changedb2a_get_key1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
        +  "additionalProperties": false,
        +  "properties": {
        +    "key": {
        +      "description": "The anonymous API key (prefix 'pk_anon_'). Long-lived and reusable: pass it as the `api_key` argument on every subsequent tool call, and keep it across sessions.",
        +      "type": "string"
        +    },
        +    "rate_limit": {
        +      "additionalProperties": false,
        +      "description": "Quota attached to this key, when the issuer reported one.",
        +      "properties": {
        +        "requests_per_day": {
        +          "type": "integer"
        +        },
        +        "requests_per_minute": {
        +          "type": "integer"
        +        }
        +      },
        +      "type": "object"
        +    }
        +  },
        +  "required": [
        +    "key"
        +  ],
        +  "type": "object"
        +}
    • Changeddiscover_destinations_near3 fields changed
      • addedInput schema / properties / language / description
        Added value: +"Language of the returned destination names (2-letter lowercase). Pass the language the user is speaking; defaults to 'en'."
      • addedInput schema / properties / lat / description
        Added value: +"Latitude of the centre point, decimal degrees (WGS84). Typically the coordinates of a city or region already known from world knowledge or from an earlier resolve_destination call."
      • addedInput schema / properties / lon / description
        Added value: +"Longitude of the centre point, decimal degrees (WGS84). Negative west of Greenwich."
    • Changedsearch_stays5 fields changed
      • addedInput schema / properties / filters / description
        Added value: +"Structured narrowing applied server-side, before ranking. Prefer these over filtering the results yourself: they run across the whole inventory, not just the page you received. Qualitative criteria that do not map here (\"quiet\", \"great breakfast\") are better served by include=['reviews_sample']."
      • addedInput schema / properties / guests / description
        Added value: +"Party composition. `adults` is required; give `children_ages` (one age per child, 0-17) rather than a child count — operators price by age. `rooms` defaults to 1; raise it when the party needs separate rooms rather than one shared."
      • addedInput schema / properties / location / description
        Added value: +"Where to search, as a {type, value} pair. Use destination_id for a place resolved via resolve_destination, poi_id for a point of interest, coordinates for a known lat/lon, or bbox for an explicit map rectangle. A property is NOT a location — use get_property_details for a known property."
      • addedInput schema / properties / page / description
        Added value: +"Pagination. `limit` caps results per page (1-100). To fetch the next page pass `cursor` with the `next_cursor` value from the previous response — cursors are opaque and are never constructed by hand."
      • addedInput schema / properties / sort / description
        Added value: +"Result ordering. score_desc (default) is the balanced relevance ranking and suits most requests; price_asc when the user asked for the cheapest; rating_desc when they asked for the best-reviewed; conversion_desc favours what comparable travellers actually booked."
  10. 2 tool updates
    • Changedcheck_property_availability1 field changed
      • changedInput schema / properties / dates / description
        Previous value: -"Stay window. Natural-language references such as 'tonight', 'this weekend', 'the weekend of July 4', 'Memorial Day weekend' translate to concrete check_in / check_out at the call site. check_in is a date in the real-time calendar that is today or later — past values are rejected at the API boundary."New value: +"Stay window. Natural-language references such as 'tonight', 'this weekend', 'the weekend of July 4', 'Memorial Day weekend' translate to concrete check_in / check_out at the call site. check_in is a date in the real-time calendar that is today or later — past values are rejected at the API boundary. Clock calibration: this schema was published in August 2026, so today is August 2026 OR LATER; an assumed 'today' in 2024/2025 is a stale training-time clock."
    • Changedsearch_stays1 field changed
      • changedInput schema / properties / dates / description
        Previous value: -"Check-in and check-out dates (ISO 8601, YYYY-MM-DD). Natural-language references — 'tonight', 'this weekend', 'the weekend of July 4', 'Memorial Day weekend', 'long weekend in May' — translate to concrete check_in / check_out values at the call site. The comparator only serves future stays: check_in is a date in the real-time calendar that is today or later. A reference like 'the weekend of June 2' resolves to the next occurrence after today, never a past anniversary; if the current year is unclear, confirm with the user before calling. Past check_in values are rejected at the API boundary."New value: +"Check-in and check-out dates (ISO 8601, YYYY-MM-DD). Natural-language references — 'tonight', 'this weekend', 'the weekend of July 4', 'Memorial Day weekend', 'long weekend in May' — translate to concrete check_in / check_out values at the call site. The comparator only serves future stays: check_in is a date in the real-time calendar that is today or later. A reference like 'the weekend of June 2' resolves to the next occurrence after today, never a past anniversary; if the current year is unclear, confirm with the user before calling. Clock calibration: this schema was published in August 2026, so today is August 2026 OR LATER (likely later — schemas outlive their publish date). An assumed 'today' in 2024/2025 is a stale training-time clock; years before 2026 are always in the past. Past check_in values are rejected at the API boundary with a hint carrying the actual current date."
  11. 5 tool updates
    • Changedcheck_property_availability3 fields changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your 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."
      • addedInput schema / properties / currency
        Added value: +{
        +  "description": "Currency 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.",
        +  "pattern": "^[A-Z]{3}$",
        +  "type": "string"
        +}
      • changedInput schema / properties / user_country / description
        Previous value: -"User's country (ISO-3166 alpha-2 uppercase). Drives the booking link locale; pass the user's own country, not the property's home country. Falls back to 'IT' when omitted."New value: +"User'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."
    • Changeddiscover_destinations_near1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your 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."
    • Changedget_property_details3 fields changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your 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."
      • addedInput schema / properties / currency
        Added value: +{
        +  "description": "Currency 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.",
        +  "pattern": "^[A-Z]{3}$",
        +  "type": "string"
        +}
      • changedInput schema / properties / user_country / description
        Previous value: -"User's country (ISO-3166 alpha-2 uppercase). Drives the booking link locale; pass the user's own country, not the property's home country. Falls back to 'IT' when omitted."New value: +"User'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."
    • Changedresolve_destination1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your 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."
    • Changedsearch_stays3 fields changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your 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."
      • addedInput schema / properties / currency
        Added value: +{
        +  "description": "Currency 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, which may not be the user's. Prices come straight from the booking sources in this currency; never convert them yourself. Each offer reflects the currency its operator actually quoted.",
        +  "pattern": "^[A-Z]{3}$",
        +  "type": "string"
        +}
      • changedInput schema / properties / user_country / description
        Previous value: -"User's country (ISO-3166 alpha-2 uppercase). Drives the booking link locale: the landing page rendered when the user clicks `web_url` uses this country, not the property's home country. Pass the user's own country, not the destination's. Falls back to 'IT' when omitted."New value: +"User's country (ISO-3166 alpha-2 uppercase). Drives the booking-link locale (the landing page rendered when the user clicks `web_url`) AND, when `currency` is not set, the pricing currency (US->USD, CA->CAD, euro-area->EUR). Pass the user's own country, not the destination's. Falls back to 'US' when omitted."
  12. 5 tool updates
    • Changedcheck_property_availability1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous b2a Bluepillow API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."
    • Changeddiscover_destinations_near1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous b2a Bluepillow API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."
    • Changedget_property_details1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous b2a Bluepillow API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."
    • Changedresolve_destination1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous b2a Bluepillow API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."
    • Changedsearch_stays1 field changed
      • changedInput schema / properties / api_key / description
        Previous value: -"Your anonymous b2a Bluepillow API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."New value: +"Your anonymous Blue Pillow Hotels & Stays API key (format 'pk_anon_…'). If you do NOT already have one — check your MCP client configuration, your persistent memory, and earlier in this conversation first — call `b2a_get_key` to obtain one before calling this tool (do not wait for a 401). PRIMARY way to authenticate: pass the key here on every call. Clients able to attach an HTTP 'Authorization: Bearer <key>' header may do that instead and omit this field — but passing it here always works and is the recommended path for tool calls. The key is not a sensitive secret: it carries no account, payment, or personal data; reuse the same key on every call."
  13. 6 tool updates
    • First observedb2a_get_key
    • First observedcheck_property_availability
    • First observeddiscover_destinations_near
    • First observedget_property_details
    • First observedresolve_destination
    • First observedsearch_stays

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to search, compare, and book hotels with real-time pricing and availability, supporting multiple location types, star ratings, and price filters.
    12
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to search and book hotels globally with real-time pricing and inventory from over 2 million properties.
    46
    MIT
  • F
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to search hotel rooms by number of nights within a flexible date range, returning real prices and the cheapest deals with booking links. It also supports city resolution, hotel listing, and offer details for external booking completion.
    4
    -
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources