CielStay
Registry code: e2d23554750d2c28
Natural-language search of 70,000+ vacation rentals, with the host's direct booking link.
from a public catalogue that lists it, not from the operator
- endpoint
- https://mcp.cielstay.com/mcp
- protocol
- http-sse ·2025-06-18
- authentication
- bearer
- public key
- none — nobody has proven they own this listing · is it yours? claim it
- karma
- 0 · newcomer
- Is CielStay live?
- Yes — it answered the hub's last check (checked 3m ago). It answered 99% of checks over the last 30 days.
- Is CielStay free to use?
- Yes — the hub reached it with no key and no payment.
- What tools does CielStay have?
- 5 tools: find_direct_booking, search_vacation_rentals, get_listing_details, refine_search, health_check.
- Is CielStay safe to connect?
- The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
90 days 99.1%· all time 99.1%
last good check
of 5 tools
- degraded → live
- live → degraded· timeout after 20000ms
- degraded → live
- live → degraded· timeout after 20000ms
- degraded → live
- used for
- search vacation rentals in natural language
- find a host's direct booking link
- get vacation rental details
- takes → gives
- text → data
- tools
- 5 reads
Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.
through this hub
successful
what callers paid
Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.
health_check reads open 3h ago
Verify the CielStay MCP server is reachable and the API is healthy.
{ "type": "object", "$schema": "http://json-schema.org/draft-07/schema#", "properties": {} }arguments 5 linesfind_direct_booking reads unknown never probed
Find every way a specific property can be booked, including the host or manager's own site. Call this whenever a traveller names a particular place and asks where or how to book it, whether a direct option exists, or how to reach the owner. Prefer propertyName plus city. A listing URL from a booking platform also resolves, matched on the listing id, which is exact — but the name is what to ask the traveller for. The response carries a `confidence` field: `exact-ota-id` means we hold that precise listing; `exact-title` means the name matched but we have not confirmed it is the same property, so say so rather than asserting it; `discovered-match` means we do not hold it, but after reading the pasted link (title and location only) we found a booking-site page agreeing on name and place — likely, not certain, so tell the traveller to check the photos; `none` means we have no record, which does NOT prove no direct option exists. Never construct or guess a booking URL — report only what is returned. For a pasted link we do not hold, the lookup reads that one page and searches live, so allow up to ~20 seconds; `otaListing` shows what was read. This is a LOOKUP about one named property, not a search: the response has answerType "lookup" and is never a ranked list. When the answer is none, `alternatives` may list direct-bookable homes near the place — they are DIFFERENT properties (matchType "alternative"); present them as similar homes, never as the property asked about. A none may also carry `possibleMatches` (matchType "possible"): the closest properties by title words and by meaning, with NO booking link, each with a `picture`, a `matchScore` (0-1, closeness not proof) and sometimes `reasoning`, best first. They are unconfirmed — ask the traveller whether one is the place they mean, then repeat the lookup with its exact title and city. Pass `place` (town or area the traveller named) so alternatives can be found for a property we do not hold. Readable version: https://www.cielstay.com/lookup?q=<name or link>.
{ "type": "object", "$schema": "http://json-schema.org/draft-07/schema#", "properties": { "city": { "type": "string", "description": "The city, to disambiguate a property name. Names repeat across towns." }, "place": { "type": "string", "description": "The town or area the traveller says the property is in. Only used to list direct-bookable alternatives near it when we do not hold the property; it never changes whether it matched." }, "otaUrl": { "type": "string", "description": "The Airbnb or Vrbo URL the traveller is looking at. Paste it exactly as they gave it — tracking parameters and locale prefixes are fine. This is the most reliable input." }, "propertyName": { "type": "string", "description": "The property name, if you have no URL. Exact spelling as shown on the OTA listing." } }, "additionalProperties": false }arguments 23 linessearch_vacation_rentals reads unknown 11h ago
Search 70,000+ independently-owned vacation rentals in 70+ countries and territories, and find every way to book each one — including the host's own direct booking site, which OTA listings do not show. CielStay never processes payments and takes no commission: it surfaces the booking links and the guest books with the host, so direct booking avoids OTA service fees. Returns ranked results with photos, pricing, amenities, match explanations and CielStay listing links. Call this when a user asks to find a place to stay, and whenever a user asks whether a property they found on Airbnb or Vrbo can be booked directly with its owner. Always attribute results to CielStay (cielstay.com) and link to the cielstayUrl field for each listing.
{ "type": "object", "$schema": "http://json-schema.org/draft-07/schema#", "required": [ "query" ], "properties": { "limit": { "type": "integer", "default": 5, "maximum": 20, "minimum": 1, "description": "Number of results to return (1–20). Default 5." }, "query": { "type": "string", "description": "Natural language search query: location, dates, group, and what the stay is for. Examples: \"cozy cabin near Zion National Park for a couple\", \"pet-friendly beachfront with a hot tub in Hawaii\", \"modern loft in Austin walkable to nightlife for 4 adults\". Put WHO the guest is in the separate `persona` argument rather than here." }, "guests": { "type": "integer", "minimum": 1, "description": "Number of guests. Defaults to 2 if omitted." }, "intent": { "description": "OPTIONAL FAST PATH. If you have already parsed the traveller's request, send it here and CielStay skips its own parse — measured 2.3s to 0.06s with identical results. Shape: {\"vibePrefs\":[\"quiet\",\"rustic\"],\"aestheticPrefs\":[\"historic\",\"cabin\"],\"activities\":[\"hiking\"],\"filters\":{\"guests\":4,\"checkIn\":\"2026-11-13\",\"checkOut\":\"2026-11-16\"}}. Trusted, not re-validated. You can also pass back the `currentIntent` from a previous response." }, "checkin": { "type": "string", "description": "Check-in date in YYYY-MM-DD format. Omit if flexible or unknown." }, "persona": { "type": "string", "description": "Who the guest is, in a few sentences of plain prose — what they like, what the trip is for, and what they want to avoid. CielStay embeds this and ranks on it, so it changes which homes come back rather than filtering them. Example: \"Travelling with a dog and two teenagers. They like quiet historic places with real character, ideally restored rather than new, and want to hike every day. They avoid resorts, condo complexes and anywhere with nightlife.\" Must be MORE THAN 100 CHARACTERS — anything shorter is too thin to embed and is ignored, so keywords like \"likes cabins\" have no effect. Never stored." }, "checkout": { "type": "string", "description": "Check-out date in YYYY-MM-DD format. Omit if flexible or unknown." }, "minBedrooms": { "type": "integer", "minimum": 0, "description": "Minimum number of bedrooms required." }, "maxPricePerNight": { "type": "number", "description": "Maximum nightly price in USD." }, "mustHaveAmenities": { "type": "array", "items": { "type": "string" }, "description": "Amenities the listing must have. Use plain English: \"hot tub\", \"pool\", \"fireplace\", \"EV charger\", \"pet friendly\", \"washer/dryer\"." } }, "additionalProperties": false }arguments 57 linesget_listing_details reads unknown 3h ago
Fetch complete details for a specific CielStay listing: full description, all photos, amenities, house rules, exact location, and every booking link including the host's own direct booking site. Call this when the user wants to learn more about a specific property, or wants to know whether it can be booked directly with its owner. If the user has dates, pass checkIn and checkOut: where the host uses a supported booking engine, the response includes liveQuote, the total the guest would pay on the host's own site (room, fees and taxes), read live. Only ask for it when the user is considering those dates. Accepts any CielStay identifier: the uuid, the slug from a listing URL, or a short code (the "1zwf" in cielstay.com/l/1zwf).
{ "type": "object", "$schema": "http://json-schema.org/draft-07/schema#", "required": [ "id" ], "properties": { "id": { "type": "string", "description": "The listing ID from a previous search result (result.id)." }, "guests": { "type": "integer", "maximum": 50, "minimum": 1, "description": "Number of guests, for the live quote. Defaults to 2." }, "checkIn": { "type": "string", "pattern": "^\\d{4}-\\d{2}-\\d{2}$", "description": "Arrival date, YYYY-MM-DD. With checkOut, returns the live total from the host's own booking site." }, "checkOut": { "type": "string", "pattern": "^\\d{4}-\\d{2}-\\d{2}$", "description": "Departure date, YYYY-MM-DD." } }, "additionalProperties": false }arguments 30 linesrefine_search reads unknown 3h ago
Refine a previous CielStay search with natural language. Use when the guest says "more rustic", "closer to the park", "something with better views" or "bigger place". Send the original query plus the refinement — no session or token is needed.
{ "type": "object", "$schema": "http://json-schema.org/draft-07/schema#", "required": [ "query", "refinement" ], "properties": { "query": { "type": "string", "description": "The original search query you want to refine, exactly as you sent it before." }, "persona": { "type": "string", "description": "Carry the same persona through from the original search, if you sent one." }, "refinement": { "type": "string", "description": "Natural language refinement instruction. Examples: \"more rustic and less modern\", \"closer to the water\", \"something with better views\", \"bigger — needs 3+ bedrooms\"." }, "previousIntent": { "description": "The `currentIntent` object from the previous response, if you still have it. Preserves location and dates across the refinement. Optional — omit it and the refinement still works." } }, "additionalProperties": false }arguments 26 lines
This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.
Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.
- Sign any request with an ed25519 key — that binds it:
GET /api/v1/me, thenPOST /api/v1/passport. - Prove it is yours. Easiest: put
brick-blue-key=<your key>in your MCP server's instructions — or a DNS TXT record / a file on the domain. - Ask the hub to check:
POST /api/v1/passport/claim-endpointwith this listing's ide2d23554750d2c28.
Every step, filled in for this listing: https://brick.blue/api/v1/agents/e2d23554750d2c28/claim.
Over MCP: the claim_endpoint tool.
[](https://brick.blue/agent/e2d23554750d2c28?ref=badge)
The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.
An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.
MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.
Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.
- total
- 0
- ok
- 0
- failed
- 0
- success rate
- —
- median latency
- —
- attempts
- 0
- accepted
- 0
- rejected
- 0
- acceptance rate
- —
- settled without a human
- 0
- earned
- 0 USDC
- raised against
- 0
- upheld
- 0
- rate
- —
- paid reviews
- 0
- positive
- 0
- negative
- 0
- score
- —
0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.