You can use this read-only MCP server to find CuddlyNest hotel destinations and pull detailed public hotel listing information with live room prices and availability.
cuddlynest_search — resolve a city/area string to matching CuddlyNest destination candidates (name, city/state/country, coordinates, property count), with optional stay dates/guest/currency parameters echoed for later use.
cuddlynest_listing_details — given a hotel URL or numeric product_id, return static listing data (name, description, address, coordinates, star rating, amenities, images) plus live room options for the requested dates.
Retrieve room-level pricing details: unit price, currency, remaining rooms, guest capacity, price breakdown, room filters, and cancellation policy type/text.
Get reliable cheapest-room price via rooms.fromPrice, plus partner names supplying the offers (e.g. dida travels, hxpro, ratehawk).
Control stay parameters (check-in/check-out, adults, children/child ages, infants, number of rooms) and currency for price lookups.
Optionally bypass robots.txt for listing-page fetches and set a custom browser timeout via environment variable.
No booking or payment functionality — it is read-only by design.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CuddlyNest Search & Listings MCP Server Search for hotels in Barcelona and show prices for 2 adults this weekend"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for searching CuddlyNest hotels and retrieving listing details, including room options, prices, availability and cancellation policies.
Read-only by design: search and listing details only. No booking, no payment.
Seeded from the MCP-server scaffolding of
openbnb-org/mcp-server-airbnb(MIT). The MCP transport/registration layer is reused; the data-fetching layer is a full rewrite. The original copyright notice is retained in LICENSE per the MIT terms.
CuddlyNest does not serve room prices in its static HTML. Pricing renders
client-side on the public listing page, backed by the site's own
infrastructure and third-party wholesale suppliers (dida travels,
hotelplanner, ratehawk, hxpro, rakuten, …).
This server reads that data the same way a visitor does: it opens the real, public listing page in a headless browser (Playwright/Chromium), lets the page's own JavaScript load the rooms, waits for them to render, and reads the result out of the DOM.
Scope — public content only. This is deliberately aligned with what the tech team recommended: read the same public page a visitor sees, using the same transport already used for amenities/images/location. The server does not call CuddlyNest's internal WebSocket, does not touch their auth/token endpoints, and carries no access token. An earlier draft that minted an anonymous token and spoke to the private WebSocket directly was dropped — nothing established that as authorized.
Data | Source |
Name, description, address, coordinates, star rating, amenities, images | Listing page |
Room title, partner, | Rendered listing page DOM, via a React-fiber walk ( |
Destination → city/state/country/coords/slug |
|
|
|
extractRoomsFromDom() walks every price-shaped text node (COL$742,637), then
walks up its React fiber tree to the nearest ancestor component whose props
carry both unit_price and roomGroups. Those props are the room offer the
page already rendered.
This is coupled to CuddlyNest's current frontend internals (a React prop shape,
not a stable contract). If they ship a frontend change it can start returning
zero rooms even though the public page still shows prices. The single place to
update is the detector condition 'unit_price' in p && 'roomGroups' in p in
scrape-listing.ts. npm run e2e:sansiraka is meant to
catch that early (non-zero exit, not a silent empty result).
The fromPriceText ("From COL$…") field uses a looser heuristic and can come
back null even on a healthy scrape; rooms.fromPrice (cheapest extracted
unit) is the reliable figure.
Related MCP server: Amadeus Hotel API MCP Server
Node.js 18+
A Chromium build for Playwright. npm install runs playwright install chromium automatically (postinstall); if that is blocked in your
environment, run npx playwright install chromium once by hand.
{
"mcpServers": {
"cuddlynest": {
"command": "npx",
"args": ["-y", "@cuddlynest/mcp-server-cuddlynest"]
}
}
}Add "--ignore-robots-txt" to args to bypass robots.txt for the
listing-page fetches. CUDDLYNEST_SCRAPE_TIMEOUT_MS (default 35000) caps how
long the browser waits for prices to render.
cuddlynest_searchResolve a destination to its CuddlyNest candidates via the public autosuggestion API — name, city/state/country, coordinates, property count.
Parameter | Required | Description |
| yes | City / area string, e.g. |
| no | echoed back for downstream use |
Returns: { query, guests, candidates[], note }. This tool does not
enumerate a destination's hotels — call cuddlynest_listing_details for a
specific hotel.
cuddlynest_listing_detailsStatic basics and rooms/pricing for one hotel.
Parameter | Required | Description |
| yes | Listing URL or numeric |
| for pricing |
|
| no | defaults 2 / 0 / – / 0 / 1 |
| no | ISO 4217, default |
| no | ignore robots.txt for the static fetch |
Returns: { productId, hotelUrl, guests, staticListing, staticError, rooms, roomsError, notes }.
rooms.units[] is the extracted room offers, each with title, partnerName,
unitPrice, currency, remainingRooms, guests, cancellationPolicyType,
cancellationPolicyText, priceBreakdown, roomFilters. rooms also carries
fromPrice, partnersSeen, listingUrl, scrapedAt.
npm install # installs deps + Chromium (postinstall)
npm run build # sync-version + tsc -> dist/
npm run typecheck
npm test # offline: smoke test (stdio) + scraper tests
npm run e2e:sansiraka # ONLINE: real scrape of cuddlynest.com, structural asserts
npm run watchtest-scrape.js — buildListingUrl (pure) + extractRoomsFromDom replayed
against fixtures/hotel-sansiraka-2026-10-05.json (a real capture from
cuddlynest.com on 2026-09-01: Hotel Sansiraka 4395541, 2026-10-05→08, 2
adults + 1 child age 2, COP — 9 rooms across dida travels / hxpro / ratehawk /
rakuten). A local headless Chromium rebuilds the page's DOM+fiber shape from
that fixture and checks the extractor reconstructs it — no network.
test-extension.js — MCP handshake, tool listing, cuddlynest_search
(hits the autosuggestion API), cuddlynest_listing_details product_id parsing.
scripts/e2e-hotel-sansiraka.mjs — runs a real scrape of the Sansiraka
listing and asserts the live result matches the fixture's structure (room
object shape/keys, non-empty, partner variety). Live prices and the exact
partner set drift from the fixture — that's expected.
Last real e2e run (2026-09-01): 7 rooms from dida travels / hxpro / ratehawk /
hotelplanner; dida travels prices matched the fixture exactly; rakuten had no
availability that run. Structure ✅.
index.ts — MCP server, tool schemas, routing, robots.txt handling
cuddlynest.ts — hotel-URL parsing, static-listing ld+json parse,
destination autosuggestion, result shaping
scrape-listing.ts — resolveListingPath, buildListingUrl, scrapeListing
(headless browser), extractRoomsFromDom (React-fiber walk)
util.ts — generic object/JSON helpers
Not affiliated with CuddlyNest. Reads publicly available listing information.
Respects robots.txt by default for the static listing fetch (override for
testing). Be mindful of request frequency — each cuddlynest_listing_details
call with dates launches a browser and loads one page.
MIT — see LICENSE.
Get details for a specific CuddlyNest hotel: static basics (name, location, description, amenities, images) from the listing page, plus live room options, prices, availability and cancellation policies streamed from CuddlyNest's wholesale-supplier WebSocket (accumulated across partial messages).
| Name | Required | Description | Default |
|---|---|---|---|
| hotel | Yes | CuddlyNest hotel URL or numeric product_id. The product_id is the trailing number in a listing URL, e.g. https://www.cuddlynest.com/hotel/us/le-meridien-boston-cambridge-4264955 -> 4264955. | |
| rooms | No | Number of rooms (default: 1) | |
| adults | No | Number of adults (default: 2) | |
| checkin | No | Check-in date (YYYY-MM-DD) | |
| infants | No | Number of infants (default: 0) | |
| checkout | No | Check-out date (YYYY-MM-DD) | |
| children | No | Number of children (default: 0, or derived from childAges) | |
| currency | No | ISO 4217 currency code for prices (default: USD), e.g. USD, EUR, COP | |
| childAges | No | Age of each child at check-in, e.g. [2, 7]. Sets `children` when given. | |
| destinationSlug | No | CuddlyNest internal destination slug for the hotel's city (e.g. 'SantaMartaMagdalenaColombia'). Optional — derived from the listing page's city/state/country when omitted. | |
| ignoreRobotsText | No | Ignore robots.txt for the listing-page fetch on this request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does well by revealing the two data sources — a listing page and a wholesale-supplier WebSocket — and by noting that live data is accumulated across partial messages. It does not mention reliability, rate limits, or exact asynchronous behavior of the WebSocket, but the disclosed behavior is materially useful.
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 a single dense sentence that front-loads the core action and then layers static vs. live data sources, ending with the partial-message accumulation caveat. It is efficient and readable, though the parentheticals make it somewhat long; no sentence is wasted.
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 11 parameters, no annotations, and no output schema, the description covers the essential context: what data is returned, where it comes from, and what the live parameters are for. It does not describe the return shape or partial-failure behavior in detail, but the listed result categories are enough for an agent to invoke 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 description coverage is 100%, so the baseline is 3. The description adds useful overall context by clarifying that parameters like checkin/checkout/adults drive the live pricing and availability stream, while the hotel parameter identifies the listing. It does not add per-parameter detail beyond what the schema already provides.
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 opens with a specific verb and resource ('Get details for a specific CuddlyNest hotel') and lists concrete result categories: static basics, live room options, prices, availability, and cancellation policies. This clearly distinguishes it from the sibling cuddlynest_search, which by name handles search rather than retrieval of a specific listing.
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?
The intended use is clear: call this when you already have a specific CuddlyNest hotel and want both static and live details. However, it does not explicitly name cuddlynest_search or state when not to use this tool, so it falls just short of fully explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a destination on CuddlyNest (city / area) to its candidates via the autosuggestion API, including the internal slug used for pricing lookups. NOTE: enumerating the hotels in a destination (with prices) needs a further capture — for live room prices on a known hotel use cuddlynest_listing_details.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | No | Number of rooms (default: 1) | |
| adults | No | Number of adults (default: 2) | |
| checkin | No | Check-in date (YYYY-MM-DD) | |
| infants | No | Number of infants (default: 0) | |
| checkout | No | Check-out date (YYYY-MM-DD) | |
| children | No | Number of children (default: 0, or derived from childAges) | |
| currency | No | ISO 4217 currency code for prices (default: USD), e.g. USD, EUR, COP | |
| childAges | No | Age of each child at check-in, e.g. [2, 7]. Sets `children` when given. | |
| destination | Yes | Destination to search (city / area), e.g. 'Santa Marta, Colombia'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal that this is an autosuggestion/destination-resolution step, not a full hotel-price enumerator, and calls out that a further capture is needed. However, it does not disclose response shape beyond 'candidates' and 'internal slug', nor does it address error behavior, rate limits, or whether the call is read-only. With no annotations, more behavioral context would be expected for a higher score.
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?
Two sentences with no filler. The core purpose is front-loaded, and the caveat about the need for a further capture is concise and actionable. Every sentence earns its place.
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?
The tool has 9 parameters, no output schema, and no annotations, so complexity is moderate-high. The description gives a clear purpose and next-step routing, but it leaves ambiguity about why parameters like checkin, checkout, rooms, adults, and currency are present in an autosuggestion call and what exactly the returned candidates look like beyond the slug. Adequate for basic use, but with clear gaps.
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. The description adds a little meaning around the destination and slug, but it does not clarify how the optional occupancy, date, or currency parameters relate to the autosuggestion step or whether they are pass-through values for later pricing. The schema already documents each parameter, so this is adequate but not additive.
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 uses a specific verb and resource: it resolves a destination to autosuggestion candidates and surfaces the internal slug for pricing lookups. It also explicitly distinguishes itself from cuddlynest_listing_details by noting it does not enumerate hotels with prices, so an agent can tell the tools apart.
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 clearly states when to use this tool: to resolve a city/area destination to candidates with slugs. It also explains what this tool is not for, enumerating hotels with prices, and directs the agent to cuddlynest_listing_details for live room prices on a known hotel. This is explicit routing with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools are clearly distinct: one resolves destinations via autosuggestion, while the other retrieves details for a specific known hotel. There is no meaningful overlap or ambiguity between them.
Both tools share the cuddlynest_ prefix and use snake_case, but one uses a verb phrase (search) while the other uses a noun phrase (listing_details). The pattern is readable and predictable, with only minor stylistic inconsistency.
With only two tools, the server feels thin for a 'Search & Listings' offering. The tools cover two discrete actions, but the count is borderline and likely limits what agents can accomplish.
The server can resolve a destination and fetch details for a known hotel, but it lacks any tool to enumerate or search hotels within a destination. This creates a significant workflow gap: an agent cannot go from destination selection to a list of available properties.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Booking.com stays by destination and dates, and full property details, as structured JSON.
Manage hotels via the apaleo PMS API: reservations, folios, invoices, rates and availability.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Luxury hotel search, rate comparison, booking quotes, and secure checkout handoff.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mafedelahoz/mcp-cuddlynest'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
