Add it to the page the guest already has open.
Think of the booking calendar on a hotel website. You pick your arrival and departure dates, click Book now, and the booking engine opens with those dates already filled in. Mews shows how a web agency can do this with a small piece of JavaScript.
I’d add Glass Lantern in much the same way. The agency adds a JavaScript component (a small, interactive part of the page) alongside the hotel’s existing booking button. Ask for a sea-view room and the component shows you the suite, its photo and the price for your dates, right there on the hotel’s website.
Ask about a birthday → see the room and cake → check the price → choose who pays.
Give the guest and their AI the same answers.
In Glass Lantern, the hotel publishes named actions such as quote_stay. WebMCP, documented by Google’s Chrome team, lets a compatible assistant use these actions in the open page. The results also update what the guest sees. For assistants that support a direct connection, the hotel offers the same actions through its own remote MCP server. An assistant needs a supported connection and permission; finding the website alone doesn’t grant either.
OpenAI’s Codex played the guest’s agent in the films. OpenAI powers Lantern’s chat. OpenAI Realtime carries the guest’s microphone conversation through the browser. Glass Lantern supplies the booking tools. No Google or OpenAI hotel reservation service sits in the middle. Read the public hotel tool guide.
Keep the public facts visible.
Put the room descriptions, accessibility details, package inclusions and image captions in the HTML that the server sends. A guest or search engine can read them before opening chat. Use the script for current quotes and private stay actions. That helps discovery; it can’t promise a ranking or recommendation. Google’s guide to JavaScript and search.
Connect the front desk before taking a live booking.
Behind the website, a server asks the hotel’s property management system or booking engine for the rate, inventory and terms for those dates. It checks again before booking, records the reservation and matches the verified payment to it. In Glass Lantern, once the hotel verifies the Stripe test payment, it uses SendGrid to email the guest their booking details and private stay link. The private link brings the guest back to the same reservation. For a hotel pilot, I’d connect the hotel’s verified sender and use the address the guest approved at checkout. If the PMS supports that whole journey, a second booking engine isn’t necessary. Otherwise, use the existing booking engine and carry the guest’s choices into it.
I’d check permissions with the hotel and the vendor first. Cloudbeds’ booking engine documentation and Mews’ Booking Engine API are starting points, not evidence that Glass Lantern is connected to either.
What I’d test with the first hotel
Can reception see exactly what the guest bought? If the last room sells while the guest is paying, can we recover without charging twice? If a car is confirmed, can the dispatcher see the flight and bag count? I’d test those with the front desk and transfer team, including a failed payment and a cancellation, before putting real inventory on sale. How Stripe verifies checkout completion.