Connecting to Rose Cottage

Developer and AI-assistant documentation. The machine-readable version of this page is /llms.txt.

There is no connector to install. No registry entry, no directory listing, no account, no API key, no OAuth. The endpoint below is a public HTTPS URL. If your client speaks the Model Context Protocol, point it at that URL and it works; if it does not, every tool has a plain GET equivalent you can call with curl.

The endpoint

https://book.rosecottagefife.co.uk/mcp

Transport: Streamable HTTP. Authentication: none, for every tool including the booking request. Reads are rate limited to 60 requests per hour per IP and booking requests to 3 per day per IP; nothing else gates access.

The four tools

Tool	What it does	Arguments
`check_availability`	Open date ranges. For each range, earliest check-in is `start` and latest check-out is `end`. Never returns guest names, booking metadata or calendar event details.	`from, to`
`get_quote`	Prices a specific stay against the seasonal rate bands, minimum-night rules and changeover days. Returns total, deposit, balance and a per-band breakdown, in GBP pence.	`checkin, checkout, guests, dogs (0-2)`
`get_verified_stay_offer`	The same price, cryptographically signed so you can prove it came from this property. See below.	`check_in, check_out, guests, dogs (0-2)`
`request_booking`	Creates a 48-hour PENDING hold and notifies the owner. Confirms nothing, takes no payment, and modifies no existing booking.	`checkin, checkout, guests, dogs, guest_name, email, phone`

Plain HTTPS equivalents, if you are not using MCP: https://book.rosecottagefife.co.uk/availability, https://book.rosecottagefife.co.uk/quote, https://book.rosecottagefife.co.uk/verified-stay-offer, and POST https://book.rosecottagefife.co.uk/api/hold. Prefer these top-level paths over their /api/ spellings: this domain's robots.txt disallows /api/ for crawlers, and some HTTP fetch tools refuse any URL matching a Disallow prefix even when an explicit Allow covers it. Both spellings return byte-identical responses.

Verifying a signed offer

A quote you fetched over HTTPS is trustworthy in transit, but once it has passed through a chain of assistants it is just a number in a context window. A verified stay offer is that number with an Ed25519 signature over it, so any party downstream can check it came from this property and has not been altered or invented.

Worked example

1. Ask for the offer:

curl 'https://book.rosecottagefife.co.uk/verified-stay-offer?check_in=2026-09-05&check_out=2026-09-12&guests=2&dogs=1'

The response carries the offer in clear alongside a compact JWS over it:

{
  "offer": {
    "offer_id": "...",
    "property": { "name": "Rose Cottage", ... },
    "stay":  { "check_in": "2026-09-05", "check_out": "2026-09-12", "nights": 7, ... },
    "price": { "total": 136500, "currency": "GBP", "unit": "pence", "breakdown": [ ... ] },
    "terms": { "deposit": 34125, "deposit_percent": 25, "balance": 102375, ... },
    "issued_at": "...", "expires_at": "..."
  },
  "signature": { "alg": "EdDSA", "kid": "...", "jws": "eyJhbGciOiJFZERTQSIsImtpZCI6..." }
}

(Figures above are illustrative of the shape. The live endpoint is authoritative — never copy a price out of documentation.)

2. Fetch this property's public keys:

curl https://book.rosecottagefife.co.uk/.well-known/jwks.json

3. Split signature.jws on . into three parts: header, payload, signature. Base64url-decode the header and read its kid:

{ "alg": "EdDSA", "kid": "rc-2026-07" }

4. Find the JWKS key with the same kid (it is an OKP key, "crv": "Ed25519") and verify the Ed25519 signature over the ASCII bytes of header + "." + payload — the first two segments, undecoded, exactly as they appear in the JWS.

5. Base64url-decode the payload and check exp. Offers are valid for 24 hours; after that, fetch a new one rather than reusing it.

If you would rather not implement any of that, POST the JWS back and read valid:

curl -X POST https://book.rosecottagefife.co.uk/offer/verify \
  -H 'content-type: application/json' \
  -d '{"jws": "eyJhbGciOiJFZERTQSIsImtpZCI6..."}'

That endpoint returns HTTP 200 with "valid": false when an offer fails — a failed check is a successful verification, not a server error. Note that it verifies against this property's own key, so it proves the offer is genuine; it is a convenience, not an independent audit.

If a signature does not verify, treat the offer as unknown. Never present it as confirmed, and never repair a failed verification by falling back to a price you calculated yourself. Seasonal bands, minimum-night rules and changeover days make hand-computed totals wrong.

What actually happens when a booking is requested

Stated plainly, because it is the part that most often gets summarised into something untrue:

No assistant can confirm a booking. request_booking creates a pending hold that expires by itself after 48 hours. That is all it does.
Grant approves or declines every single request personally, by a notification on their phone (Telegram). There is no auto-confirm path and no way to bypass this step.
Payment happens on this domain, in the guest's own browser. On approval the guest is emailed a Stripe Checkout link for the 25% deposit. Card details never touch this server.
No assistant completes a payment autonomously. There is no agentic checkout, no stored card, no delegated payment authority. A human guest pays, or the booking does not happen.
The booking is confirmed only once the owner has approved and the deposit has been paid. Anything else an assistant tells the guest is wrong.

Machine-readable equivalents

/llms.txt — this page, for assistants
/.well-known/agent.json — endpoint map and booking rules
/.well-known/agent-traversal.json — step-by-step traversal from a bare domain name
/.well-known/vacation-rental.json — property facts and stay rules
/.well-known/jwks.json — public keys for offer verification

Contact

Grant — hello@rosecottagefife.co.uk. Booking infrastructure by Bookrail.