WebMCP explained: how AI agents can book through hospitality websites

WebMCP is a proposed web standard that lets a website publish tools that an AI agent in the visitor's browser can call. Each tool is a function with a name, a plain-language description and a schema for its inputs. Instead of reading the page and clicking through it, an agent asked to book dinner could call a restaurant site's availability tool with a date and party size and get a structured answer back. For hospitality websites, WebMCP is a way to make booking pages usable by agents while the guest stays in their own browser session.

In October 2026 it is still experimental. The specification is a Draft Community Group Report from the W3C Web Machine Learning Community Group, which states that it is not a W3C Standard and is not on the W3C Standards Track. Chrome has offered WebMCP as an origin trial since Chrome 149, and at the end of September it approved an extension that runs the trial to Chrome 162.

How does WebMCP work?

A page registers tools with the browser. In the current specification and Chrome's documentation the entry point is document.modelContext, and a tool is added with document.modelContext.registerTool(). Each tool has a name, a description and an execute function that runs in the page and returns its result to the agent, and Chrome's documentation also asks for an input schema describing the parameters. Passing an AbortSignal when registering a tool lets the page remove it later. Early implementations exposed the API as navigator.modelContext, and some older examples online still use that name.

Tools can carry annotations that tell the agent how careful to be. readOnlyHint marks a tool that only reads data. consequentialHint marks an action that is significant or irreversible, so the agent or browser may ask the user to confirm. untrustedContentHint flags output that contains data the site doesn't control.

Chrome describes WebMCP tools as existing only while the page is open. That separates them from an MCP server, which runs on a back end and is available whether or not anyone has the site open.

What is the difference between the declarative and imperative APIs?

The imperative API is the JavaScript route above. The declarative API turns an existing HTML form into a tool using attributes: toolname and tooldescription on the form, and optionally toolparamdescription on individual fields. By default the browser fills in the form and focuses it, and the visitor still clicks submit. Adding toolautosubmit lets the agent's call submit the form, and the page can check SubmitEvent.agentInvoked to see whether an agent triggered the submission.

Chrome's origin trial covers both forms. The Community Group specification defines the imperative API, while its section on the declarative form is still a placeholder that points to a separate explainer.

Which browsers support WebMCP?

Because WebMCP is in an origin trial, a site has to register for the trial and serve its token before visitors' Chrome browsers expose the API. Developers can test locally by enabling chrome://flags/#enable-webmcp-testing, and Chrome 149 added experimental WebMCP debugging to the Application panel in DevTools. Microsoft lists a WebMCP origin trial for Edge as well. Chrome's documentation says WebMCP is under active discussion and subject to change, so treat anything built on it as an experiment that may need rework.

What could WebMCP mean for hospitality booking sites?

Booking is the obvious use. A restaurant, spa or hotel site could register a read-only tool that returns availability for a date and party size, and a second tool that starts a booking for the slot the guest picked. Because the tools run inside the page, they work with the visitor's existing session, and the page can show what is happening while the agent works.

Chrome's best-practice guidance is to give each tool one job, name it with a verb that says whether it acts immediately or starts a process, and return descriptive errors so the model can correct the call and retry. Every extra tool takes up part of the agent's context, so a short list of clearly separate tools works better than many overlapping ones.

Anything that spends money or commits the guest should carry consequentialHint and leave the final confirmation to the guest. A deposit or card guarantee is a payment step, and the guest should see it and approve it in the booking flow.

How could a venue site built on Tiquo expose booking tools?

A developer building a venue site with Tiquo's @tiquo/dom-package could register WebMCP tools around functions the package already has. A read-only list_services tool could wrap getFlowServices(). A read-only check_availability tool could call getFlowAvailability() for the requested dates and party size, which returns the services available on each date, up to seven venue-local dates at a time. A start_booking tool could call embedServiceBooking() to open the Tiquo booking flow for the chosen service, leaving payment and confirmation to the guest inside that flow.

That would be custom code on the venue's own site, written and maintained by its developer, and it would share WebMCP's experimental status. Server-side work belongs elsewhere: the Admin API's keys carry permissions and stay on the server, so keep them out of any page script that an agent can call. Our guide to choosing a booking widget or booking API explains the website options these tools would sit on.