Blue Pillow Hotels & Stays
Server Details
Neutral hotel & stay price comparison for AI agents: live prices from 16+ booking sites. No signup.
- Status
- Healthy
- Uptime
- 100.0% over 64 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 6 tools
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).
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.
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.
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 toolscheck_property_availabilityCheck live availability and per-operator quotes for a stayARead-onlyInspect
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, orunknown. 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 carriesamount(total stay),amount_per_night(per-night),currency,breakfast_included,refundable,rooms_left, anddeeplink_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 inoffers[], andsort=price_ascgives pure price order. Eachdeeplink_urlis 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 ofoffers[0]for callers that just want the curated headline.nullwhen 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.
| Name | Required | Description | Default |
|---|---|---|---|
| dates | Yes | 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. | |
| guests | Yes | Guest composition. Adults is required; children and infants default to zero. | |
| api_key | No | 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. | |
| currency | No | 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. | |
| language | No | User's UI language (2-letter lowercase). Drives the booking link language; falls back to 'en'. | |
| property_id | Yes | Opaque 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_country | No | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| brand | No | |
| chain | No | |
| price | No | |
| stars | No | |
| images | No | |
| offers | No | |
| rating | Yes | |
| web_url | No | |
| features | No | Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available. |
| location | Yes | |
| amenities | No | |
| cluster_id | No | |
| dedup_meta | No | |
| description | No | Free-text property description, when the source provides one. Usually null on search results. |
| ota_coverage | Yes | |
| rating_count | No | |
| reviews_meta | No | Provenance 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_type | Yes | |
| thumbnail_url | No | |
| reviews_sample | No | |
| reviews_aggregate | No | rating_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_status | No | 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). |
TDQS
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.
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.
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.
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.
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.
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 pointARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | 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. | |
| lon | Yes | Longitude of the centre point, decimal degrees (WGS84). Negative west of Greenwich. | |
| type | No | Optional filter; same semantics as resolve_destination. Areas are returned only when `area` is asked for explicitly. | |
| api_key | No | 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. | |
| language | No | Language of the returned destination names (2-letter lowercase). Pass the language the user is speaking; defaults to 'en'. | en |
| radius_km | No | Search radius in km from the point. Defaults to 5 km (city-center scope). |
Output Schema
| Name | Required | Description |
|---|---|---|
| candidates | Yes | |
| total_matches | Yes | |
| total_matches_capped_at | No |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | Optional 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. | |
| label | No | Optional 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
| Name | Required | Description |
|---|---|---|
| key | Yes | The anonymous key (prefix 'pk_anon_'), used as the `api_key` argument of the other tools. |
| rate_limit | No | Quota attached to this key, when the issuer reported one. |
TDQS
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.
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.
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.
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.
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.
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 availabilityARead-onlyInspect
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 supersedesreviews_sample.reviews_metareports 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.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | 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. | |
| include | No | 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. | |
| currency | No | 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`. | |
| language | No | User'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_id | Yes | Opaque 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_country | No | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| brand | No | |
| chain | No | |
| price | No | |
| stars | No | |
| images | No | |
| offers | No | |
| rating | Yes | |
| web_url | No | |
| features | No | Structured feature/facility tags (e.g. HouseFacilities, PropertyTypes). Populated alongside description when available. |
| location | Yes | |
| amenities | No | |
| cluster_id | No | |
| dedup_meta | No | |
| description | No | Free-text property description, when the source provides one. Usually null on search results. |
| ota_coverage | Yes | |
| rating_count | No | |
| reviews_meta | No | Provenance 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_type | Yes | |
| thumbnail_url | No | |
| reviews_sample | No | |
| reviews_aggregate | No | rating_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_status | No | 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). |
TDQS
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.
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.
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.
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.
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.
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 idARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Destination name in English or canonical local form (not a translation). | |
| type | No | 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. | |
| api_key | No | 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. | |
| country | No | Country: ISO-3166 alpha-2 (preferred), alpha-3, or extended name in any supported language. Unrecognized values are silently ignored (fail-open). | |
| language | No | Render destination names + breadcrumbs in this language. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| candidates | Yes | |
| total_matches | Yes | |
| total_matches_capped_at | No | |
| disambiguation_recommended | Yes |
TDQS
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.
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.
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.
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.
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.
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 operatorsARead-onlyInspect
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) andimages, capped to one photo;get_property_detailsreturns the full gallery.web_url, a link to the property page with the stay already encoded.priceandoffers[]: the live quote for the requested dates, present only when availability was confirmed. Each offer hasota,amount(total stay),amount_per_night,currency,breakfast_included,refundable,rooms_leftanddeeplink_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.pricemirrorsoffers[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_ascorders by price alone. There is no date-agnostic "from" price.availability_status:available(live quotes inoffers),unavailable(no rooms for those dates) orunknown(the operators returned nothing conclusive — not evidence that the property is full). The defaultavailability_mode=strictreturns onlyavailableresults;include_unavailablealso 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 thatbboxor a parent destination fits better).destination_id: the opaque id fromresolve_destination, passed verbatim.poi_id: the opaque id of a point of interest, fromresolve_destinationordiscover_destinations_near.bbox: an explicit map rectangle. A property is not a location:get_property_detailscovers a known property.
Pagination: the next_cursor of a response goes into page.cursor for
the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 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. | |
| sort | No | 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. | |
| dates | Yes | 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. | |
| guests | Yes | 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. | |
| api_key | No | 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. | |
| filters | No | 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']. | |
| include | No | 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. | |
| currency | No | 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. | |
| language | No | User'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. | |
| location | Yes | 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. | |
| user_country | No | 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. | |
| availability_mode | No | strict (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_overbudget | No | Opt-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_bounds | No | Opt-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
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| results | Yes | |
| metadata | Yes | |
| alternatives | No |
TDQS
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.
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.
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.
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.
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.
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.
6 tool updates
- Changed
check_property_availability1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
discover_destinations_near1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
get_anonymous_key1 field changed- changed
Output schema / properties / key / descriptionPrevious 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."
- Changed
get_property_details1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
resolve_destination1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
search_stays1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
7 tool updates
- Removed
b2a_get_key - Changed
check_property_availability1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
discover_destinations_near1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Added
get_anonymous_key - Changed
get_property_details1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
resolve_destination1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
search_stays1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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 tool updates
- Changed
check_property_availability3 fields changed- changed
Output schema / properties / availability_status / descriptionPrevious 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)." - changed
Output schema / properties / description / descriptionPrevious 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." - changed
Output schema / properties / features / descriptionPrevious 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."
- Changed
get_property_details3 fields changed- changed
Output schema / properties / availability_status / descriptionPrevious 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)." - changed
Output schema / properties / description / descriptionPrevious 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." - changed
Output schema / properties / features / descriptionPrevious 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."
- Changed
search_stays9 fields changed- changed
Output schema / properties / alternatives / properties / out_of_bounds / items / properties / availability_status / descriptionPrevious 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)." - changed
Output schema / properties / alternatives / properties / out_of_bounds / items / properties / description / descriptionPrevious 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." - changed
Output schema / properties / alternatives / properties / out_of_bounds / items / properties / features / descriptionPrevious 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." - changed
Output schema / properties / alternatives / properties / overbudget / items / properties / availability_status / descriptionPrevious 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)." - changed
Output schema / properties / alternatives / properties / overbudget / items / properties / description / descriptionPrevious 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." - changed
Output schema / properties / alternatives / properties / overbudget / items / properties / features / descriptionPrevious 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." - changed
Output schema / properties / results / items / properties / availability_status / descriptionPrevious 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)." - changed
Output schema / properties / results / items / properties / description / descriptionPrevious 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." - changed
Output schema / properties / results / items / properties / features / descriptionPrevious 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."
2 tool updates
- Changed
b2a_get_key2 fields changed- changed
Input schema / properties / agent / descriptionPrevious 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." - changed
Input schema / properties / label / descriptionPrevious 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."
- Changed
get_property_details2 fields changed- changed
Input schema / properties / currency / descriptionPrevious 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`." - changed
Input schema / properties / user_country / descriptionPrevious 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."
2 tool updates
- Changed
discover_destinations_near3 fields changed- changed
Input schema / properties / type / descriptionPrevious 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." - changed
Input schema / properties / type / enumPrevious value: -[ - "city", - "neighborhood", - "airport", - "poi" -]New value: +[ + "city", + "neighborhood", + "airport", + "poi", + "area" +] - changed
Output schema / properties / candidates / items / properties / type / enumPrevious value: -[ - "city", - "neighborhood", - "airport", - "poi" -]New value: +[ + "city", + "neighborhood", + "airport", + "poi", + "area" +]
- Changed
resolve_destination3 fields changed- changed
Input schema / properties / type / descriptionPrevious 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." - changed
Input schema / properties / type / enumPrevious value: -[ - "city", - "neighborhood", - "airport", - "poi" -]New value: +[ + "city", + "neighborhood", + "airport", + "poi", + "area" +] - changed
Output schema / properties / candidates / items / properties / type / enumPrevious value: -[ - "city", - "neighborhood", - "airport", - "poi" -]New value: +[ + "city", + "neighborhood", + "airport", + "poi", + "area" +]
1 tool update
- Changed
search_stays1 field changed- changed
Input schema / properties / filters / properties / property_types / descriptionPrevious 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."
1 tool update
- Changed
search_stays1 field changed- changed
Input schema / properties / filters / properties / amenities / descriptionPrevious 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."
2 tool updates
- Changed
get_property_details1 field changed- changed
Input schema / properties / include / descriptionPrevious 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."
- Changed
search_stays4 fields changed- changed
Input schema / properties / include / descriptionPrevious 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." - changed
Input schema / properties / location / properties / type / descriptionPrevious 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." - added
Input schema / properties / location / properties / value / anyOfAdded 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" + } +] - changed
Input schema / properties / location / properties / value / descriptionPrevious 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."
3 tool updates
- Changed
b2a_get_key1 field changed- changed
Output 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" +}
- Changed
discover_destinations_near3 fields changed- added
Input schema / properties / language / descriptionAdded value: +"Language of the returned destination names (2-letter lowercase). Pass the language the user is speaking; defaults to 'en'." - added
Input schema / properties / lat / descriptionAdded 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." - added
Input schema / properties / lon / descriptionAdded value: +"Longitude of the centre point, decimal degrees (WGS84). Negative west of Greenwich."
- Changed
search_stays5 fields changed- added
Input schema / properties / filters / descriptionAdded 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']." - added
Input schema / properties / guests / descriptionAdded 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." - added
Input schema / properties / location / descriptionAdded 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." - added
Input schema / properties / page / descriptionAdded 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." - added
Input schema / properties / sort / descriptionAdded 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."
2 tool updates
- Changed
check_property_availability1 field changed- changed
Input schema / properties / dates / descriptionPrevious 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."
- Changed
search_stays1 field changed- changed
Input schema / properties / dates / descriptionPrevious 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."
5 tool updates
- Changed
check_property_availability3 fields changed- changed
Input schema / properties / api_key / descriptionPrevious 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." - added
Input schema / properties / currencyAdded 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" +} - changed
Input schema / properties / user_country / descriptionPrevious 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."
- Changed
discover_destinations_near1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
get_property_details3 fields changed- changed
Input schema / properties / api_key / descriptionPrevious 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." - added
Input schema / properties / currencyAdded 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" +} - changed
Input schema / properties / user_country / descriptionPrevious 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."
- Changed
resolve_destination1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
search_stays3 fields changed- changed
Input schema / properties / api_key / descriptionPrevious 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." - added
Input schema / properties / currencyAdded 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" +} - changed
Input schema / properties / user_country / descriptionPrevious 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."
5 tool updates
- Changed
check_property_availability1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
discover_destinations_near1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
get_property_details1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
resolve_destination1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
- Changed
search_stays1 field changed- changed
Input schema / properties / api_key / descriptionPrevious 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."
6 tool updates
- First observed
b2a_get_key - First observed
check_property_availability - First observed
discover_destinations_near - First observed
get_property_details - First observed
resolve_destination - First observed
search_stays
Related MCP Connectors
AI hotel search and booking: millions of properties, 85,000+ cities, live rates.
Book real hotel and resort stays from any AI agent: all-in pricing, hosted Stripe checkout, no key.
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Free hotel comparison for AI assistants: 77k hotels on the same criteria, with reasons. No key.
Related MCP Servers
AlicenseNot gradedqualityBmaintenanceEnables AI agents to search, compare, and book hotels with real-time pricing and availability, supporting multiple location types, star ratings, and price filters.12MIT
Dida Hotel MCPofficial
AlicenseNot gradedqualityDmaintenanceEnables AI agents to search and book hotels globally with real-time pricing and inventory from over 2 million properties.46MIT
RollingGo Hotel MCPofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to search, compare, and book hotels worldwide through natural language, with real-time pricing and availability, plus price monitoring and order management.48MIT- FlicenseAqualityBmaintenanceEnables 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-
Glama MCP Gateway
Add one secure layer between your agents and this server.