Kyoto Booking Retry Proof

WebMCP stops a lost hotel-booking response from becoming a duplicate reservation.

Comment

Two attempts. One simulated booking. One confirmation number.

The ordinary problem

A traveler books a hotel while arriving in Japan. The request reaches the device, but unreliable airport Wi-Fi hides the success response. The page looks as if it failed. Retrying the whole form can create a second reservation, and cancelling it through an unfamiliar Japanese site is slow and stressful.

What this project does

This project turns that uncertainty into one safe question: Did this exact booking already go through?

The fictional Kyoto hotel demo exposes four narrow WebMCP capabilities. An assistant can check for the same booking, validate and prepare it, recover its status after a lost response, and preview cancellation terms without changing anything. The assistant cannot confirm, pay for, or cancel a booking. A visible human button is the only way to commit the simulated reservation.

The demonstrated retry ends with:

2 attempts 1 simulated booking 1 effect start 1 confirmation number

Why WebMCP is the right fit

Without WebMCP, an assistant must infer meaning from pixels, button labels, and a possibly stale page, or resend the form and hope. WebMCP lets the website publish small named operations with checked inputs and structured results. The assistant can ask the site for the existing state before repeating an action.

This is useful beyond hotels. The same pattern applies to payments, restaurant reservations, ticket purchases, form submissions, and any action where the request may have succeeded even though the response was lost.

Better for people and agents

The person gets a clear answer instead of guessing, translating a cancellation flow, or contacting support. The assistant gets a safe question it can ask without gaining authority to spend money or change a reservation. The website keeps the final confirmation decision with the person.

How it works

Hotel, plan, dates, adults, and rooms are normalized into one stable UUIDv5 booking identity. Display language does not affect that identity. IndexedDB places unique constraints on the booking details and confirmation number, so repeated clicks, two tabs, reload, and retry converge on one stored result.

Every state change receives a time-ordered UUIDv7 event and includes the SHA-256 digest of the previous event. The visible proof panel shows the booking identity, event history, effect-start count, and whether the chain is valid. A service worker restores the local fictional result after the first load even when the network disappears.

The implementation uses plain JavaScript, TypeScript tests, Vite, IndexedDB, and a Cloudflare-compatible ChatGPT Sites package. The same static client is also deployed on Vercel.

What changed during the submission period

This is an existing open-source specification repository. During the submission period, I added the fictional hotel duplicate-booking experience, four hotel-specific WebMCP capabilities, the human-only confirmation boundary, browser-local retry recovery, responsive and offline behavior, public ChatGPT Sites and Vercel deployments, machine-readable deployment evidence, and the 150-second narrated demo.

Try it in about 60 seconds

Open the public Vercel page with fresh browser storage and a supported Chrome WebMCP configuration. Use the named check and prepare capabilities for the fictional stay and confirm that the state becomes PREPARED. Select 2. Confirm booking — human action only. The simulated booking is stored while the success response is intentionally hidden. Use the native get_hotel_booking_status capability before retrying; it finds the existing result and its confirmation number. Select Retry the same booking and verify RETRY_RECOGNIZED, attempts 2, bookings 1, effect starts 1, and the same confirmation number.

Submitted website: https://kyoto-booking-retry-proof.anionix.chatgpt.site Current Vercel release: https://kyoto-booking-retry-proof.vercel.app Public source: https://github.com/Anionix/verifiable-offline-webmcp-agent-spec

No account, personal information, payment, real hotel, email, or external reservation is required.

Verification

The current Vercel production release is tied to source commit 2d5abd679893ec7dff36758925477999424c3cc7 and production deployment dpl_HWJVg4uCgFEaq9N2f5kvXwLjvK2E, which reached READY at 2026-08-31T10:31:51.086Z. The submitted ChatGPT Site is live as version 14 from source commit 2fbbf1b714ca660ef1681239b638205a9835f7c5. Both public evaluation files are anonymously readable and report the same four-tool contract and 194-test executable release evidence. The repository passes 194 Node tests, TypeScript checking, source-quality checks, repository schemas, build checks, and full validation.

A fresh managed browser run opened the canonical public HTTPS alias after READY. Native discovery through document.modelContext.getTools returned exactly these four capabilities: check_existing_hotel_booking, prepare_hotel_booking, get_hotel_booking_status, and preview_hotel_cancellation. Confirmation, payment, and cancellation capabilities were absent and never called. The run used document.modelContext.executeTool with valid JSON input, started from EMPTY at 2026-08-31T10:43:36.851Z, reached PREPARED at 2026-08-31T10:43:48.349Z, and the browser driver exercised only the visible human confirmation button once. Native get_hotel_booking_status found the existing result before the visible retry at 2026-08-31T10:44:34.734Z. After the visible retry, native get_hotel_booking_status returned RETRY_RECOGNIZED at 2026-08-31T10:45:05.366Z with two attempts, one simulated booking, one effect start, and the same confirmation number FKR-044FD54558. Final page observation was 2026-08-31T10:45:19.736Z with zero console errors and zero warnings.

The unique deployment alias was read from the Vercel deployment record but required a Vercel sign-in redirect in the isolated browser; execution therefore used the canonical public alias while the Vercel deployment ID and source commit were independently read back. The native result fields do not measure page network traffic, external requests, permission requests, or notifications.

The browser driver exercised the visible human confirmation button under explicit verification authorization to verify the human boundary; the proof does not present that driver action as a literal human touch. The recorded native-browser run and its machine-readable evidence are in the public source repository.

Media disclosure

The opening airport scenes are artificial-intelligence-generated dramatizations and are labeled as fictional. The remaining demonstration uses real captures of the public fictional-booking site. The narration uses a stock public voice, not a cloned voice or avatar.

Built With

Share this project:

Updates