WebMCP Tutorial: Build an Appointment Booking Flow

Start with the reservation journey

Open the appointment booking playground and select Start guided example. It searches the fixed demo calendar and prepares an introduction call for October 12, 2026 at 09:00 UTC. It stops at a visible review. Select Confirm demo appointment to create your first reservation.

You now have a reference such as DEMO-0001. The 09:00 slot is unavailable. Select Check reservation to read the confirmed record, then Review cancellation and Confirm demo cancellation. The record changes to cancelled and the time opens again.

This application runs locally in the page. Its guided example is a deterministic script, not an LLM. The native tool interface is a progressive enhancement when a supported browser exposes WebMCP. Chrome documents both that enhancement and its current setup in the WebMCP overview.

Define a small set of meaningful tools

The demo exposes six tools with JSON object inputs:

These names describe specific operations. Their handlers enforce the actual rules: known service and slot IDs, availability, the displayed calendar, and the current revision. A description or annotation alone cannot enforce those rules.

Keep the UI and agent on the same state

The page controls and local JSON runner call executeBookingTool. The WebMCP registration callback calls the same function through the same state reference. This prevents the inspector from showing one reservation while the visible page shows another.

Try changing the service to Portfolio review, then run get_booking_state. The result reflects the service selected in the page. A native callback updates that same calendar and is identified as Native WebMCP in the trace.

The imperative API documentation explains registration. In this project, a shared registration adapter owns each tool’s lifetime and aborts it when the React island is disposed. An unsupported browser can still use the ordinary controls.

Separate preparation from confirmation

prepare_appointment creates a review; it does not reserve a time. The user-facing confirmation control calls a separate domain function. That function rechecks the state revision and slot availability before adding a reservation. Confirmation is not exposed as another tool in this demo.

For a production app, choose an explicit authorization model appropriate to the action. UI confirmation in a local example does not establish production identity, payment consent or protection against another customer booking the same slot.

Test failures, not only the happy path

Try these deliberate errors in the inspector:

1. Prepare an 11:00 slot. It is unavailable in the fixture calendar.
2. Load an example for prepare_appointment, change the selected date, then run the old JSON. Its revision is stale.
3. Look up DEMO-9999. No such reference exists in this page session.
4. Confirm a reservation, then try preparing the same slot again. Availability has changed.
5. Load invalid input. Unknown properties and missing arguments fail before state changes.

After an error, run get_booking_state to inspect the unchanged reservation history. Use Load current example to refresh arguments after a state change. Cancellation returns the time to availability, while retaining the cancelled record for lookup.

Move from a local demo to a real service

The example intentionally uses a fixed, clearly labelled UTC calendar and in-memory reservations. A real provider integration needs a server that owns availability and bookings, authenticated access to reservation records, atomic inventory changes, idempotent confirmation, and explicit time-zone conversion. Notifications and payments are separate effects that should only run after an authorized successful booking.

Keep the browser’s tool contracts narrow and return only the data needed for the next step. Replace the local domain operation with an authenticated backend operation, then update the UI from that response. Test competing bookings and retry behavior against the backend before claiming production readiness.

Verify native execution separately

The local runner proves the application handler works. To test WebMCP integration, follow browser setup, confirm the page reports registered tools, and invoke a tool from a supported agent or inspector. Inspect the resulting native trace and visible state. An actual agent choosing a suitable tool is an additional test beyond manually invoking it.

Compare the same task with and without WebMCP

Open the comparison on the appointment playground. Each mode starts with the same fictional calendar and booking controls. Without WebMCP, use ordinary page interaction; with WebMCP, a compatible agent can also invoke the registered tools. Use a fresh agent context and copy the same task prompt for each run:

Find the earliest available portfolio-review appointment on October 14, 2026, before noon UTC. Prepare it for my review and stop before confirming. Wait for me to confirm using the page. After I confirm, look up the reservation and report its reference, date, time and status.

Select a mode to open its separate run page, then press Begin timed run. Let the agent prepare the booking, confirm it yourself, then let it look up the reservation. Native mode cannot begin until its tools are registered. Both modes use the ordinary booking controls and omit the guided example and JSON runner.

The comparison checks the requested confirmation and readback, and retains up to 20 attempts per comparison pair in your browser. Its results show page elapsed time, time with a review open and observed application actions separately. The stopwatch includes time switching to your agent and is not complete agent latency; time with a review open is not verified human deliberation time. Page actions do not include every browser read or interaction.

Use the same agent and model in both modes, alternate the order and repeat the task before drawing a performance conclusion. Native support and observed callbacks are separate from task completion: a successful run with no native calls is not evidence of native WebMCP use. Token and cost measurements require actual agent telemetry; this playground does not estimate them.

For a different set of domain rules, compare the e-commerce demo, where the shared state is a cart, or the travel demo, where dates and guest capacity determine a quote.