CuddlyNest Search & Listings MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CUDDLYNEST_ACCESS_TOKEN | No | Optional anonymous JWT access token used to enable live pricing. This can be supplied as the CUDDLYNEST_ACCESS_TOKEN environment variable or via the --access-token argument. Without it, live room/pricing data is unavailable. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cuddlynest_searchA | Search CuddlyNest for a destination and the top hotels there. Returns place candidates (city/region + coordinates + total property count) and a list of hotels — name, listing URL, star + guest rating, and (when available) images, distance from the centre and key amenities. Pass a hotel's product_id from the results to cuddlynest_listing_details for live rooms and prices. The hotel list is top-matches scale (~10-60), not the full inventory. |
| cuddlynest_listing_detailsA | Get details for a specific CuddlyNest hotel: static basics (name, location, description, amenities, images) from the listing page, plus room options, prices, availability and cancellation policies read from the public listing page rendered in a headless browser. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools occupy completely separated stages of the workflow: search discovers destinations and top hotels, while listing_details drills into one hotel using a product_id. There is no overlap in purpose or output.
Both names share a cuddlynest_ prefix, making the server's brand clear, but one uses an imperative verb (search) while the other is a noun phrase (listing_details). This minor inconsistency prevents a perfect score.
Two tools is borderline for a typical MCP server, though the count fits the narrow search-and-details purpose. It feels slightly thin because there is no tool for direct lookups or other listing workflows.
The described lifecycle is complete: cuddlynest_search produces both destination candidates and hotels with product IDs, and cuddlynest_listing_details consumes those IDs to return live rooms, prices, and policy details. No obvious dead end exists in the intended flow.