We Opened Our Balloon Booking to AI Agents. Here Is How.

What WebMCP is, in plain language

Model Context Protocol, usually written MCP, is the convention that lets an AI assistant call tools somebody else wrote. WebMCP is the browser version. Instead of a server publishing tools somewhere out on the network, the web page publishes them to the agent running in the browser of the person reading that page.

The mechanics fit in a sentence. A page calls document.modelContext.registerTool() and passes a name, a description, a schema for the inputs and a function to run. From that moment an agent in that browser can see the tool and call it, on that page, for that visitor, and gets structured data back.

The reason this exists is that the alternatives are poor. An agent that wants something from a website today either reads the rendered text and infers, or drives the interface by clicking through it. The first produces confident answers built on a stale paragraph. The second breaks the week a button moves. A registered tool is the site saying out loud what it can answer and in what shape, which is a much smaller thing to get right.

The status matters as much as the mechanics. WebMCP is a draft report of the W3C Web Machine Learning Community Group, in a draft dated 26 August 2026, edited by engineers from Google and Microsoft. Chrome runs it as an origin trial across versions 149 to 156, meaning it is switched on for sites that register a token, for a limited run of releases, while the design is tested in public. A draft at this stage is not a promise, so we treated it as an experiment with a real deadline rather than a platform to build on.

Why a balloon operator, of all businesses

Two things about this product make it awkward for any agent that can only read pages. The first is that tomorrow's flight may not exist. Balloon flights are cancelled for wind, and the authority clears or grounds each sector on the morning itself, a few hours before sunrise. Nothing written on a page yesterday is authoritative about that, including anything written by us.

The second is that the price belongs to a date. A morning in January and a morning in late September are different products at different prices, set in a pricing table rather than on a page. A site that says "from 119 EUR" is telling the truth and answering the wrong question when the guest is asking about 10 September.

So the two questions guests actually ask, will it fly and what does my date cost, are precisely the two that static text answers badly. That is why they became the first two tools, before anything to do with booking.

The four tools

These are live rather than a demonstration. Testing in Chrome 151 with the WebMCP flag enabled on 2 September 2026, an agent asked for the price of 10 September 2026 and got 249 euro per person, which is what the booking page shows for that date, because both read the same pricing table rather than two copies of it.

Three of the four are marked read-only in their descriptor, which is the flag that lets an agent, or the person supervising it, tell looking apart from doing. Only the fourth changes anything on screen, and what it can change is narrow.

What we did not open

The fourth tool is where the real decision sits. prefill_booking_form fills the form in. It cannot submit it. There is no tool for taking a payment, and there is not going to be one.

The fields an agent may write are listed one by one in the code: full name, email, phone, country, pickup hotel, special requests, plus the date and the passenger count. Anything outside that list is rejected by name. We tested the obvious attack on ourselves on 2 September 2026: an agent instructed to put a card number into the form got back a rejection reading unknown_field. There is no card field in the allowlist, so there is nothing to negotiate at runtime.

Payment runs where it always has, through the guest's own bank with 3D Secure. The card number and the code the bank sends travel between the guest and the bank. An agent that can read the page cannot read those, because they were never part of the page's tool surface to begin with.

That boundary is not caution for its own sake. The reason a booking page can afford to be helpful to an agent at all is that the irreversible step still needs a person: someone reads the summary, sees the total, and approves the payment at their bank. Automating the last thirty seconds would remove the one checkpoint that catches a wrong date, and a wrong date in this business means a guest standing in a hotel lobby at 4am on the wrong morning.

How it is built

No new dependencies were added. The whole feature is one React hook, a file of pure functions holding the logic, and two mount points, one on the booking page and one on the flight status page. Nothing went into package.json, which for an API this young was the point.

Every access is feature-detected. The hook looks for document.modelContext, falls back to navigator.modelContext, and if neither is there it returns and the page renders as it always did. Registration itself is wrapped, so a change in the shape of the API cannot throw an error into the page. A visitor on Safari, or on a Chrome without the trial, gets a site byte for byte identical to last month's.

The defensiveness is not decoration. While this was being built the entry point had already moved twice, from window.agent to navigator.modelContext to document.modelContext. Something this young will move again. Keeping it in one file means the day it moves we edit one function and redeploy.

The logic behind the tools, the price lookup, the date listing and the field allowlist, sits in pure functions with unit tests, so the rules can be checked without opening a browser. It also means the rules that protect the form from an agent are the same rules for anything else that ever calls them.

What happens next

The origin trial runs from Chrome 149 to Chrome 156. A site opts in with a token tied to its origin and served as an HTTP header, which is what we do: our registration runs to the end of the trial in November 2026. When the trial ends, one of three things follows: the API ships, the API changes, or it goes away. If it goes away we delete a header and a hook, and no visitor notices anything.

The other half of this is the agent side, and it is the half we do not control. The tools exist and answer correctly when called. What is still moving is which assistants call them: Gemini in Chrome does not yet reach for third-party page tools on the stable channel. The gate right now is the agent, not the standard.

We are publishing this while it is unfinished rather than after it settles, for two reasons. The details of a working implementation are more useful to another operator than an announcement would be, and our guests are already asking their browsers about tomorrow morning whether or not the page is ready to answer. If you run a site where the correct answer changes every day, this is worth an afternoon of your time.

See the same data a tool returns

Frequently asked questions

What is WebMCP?

WebMCP lets a web page offer named tools to an AI agent running in the visitor's browser, instead of making the agent guess from the rendered text. A page registers each tool through document.modelContext with a name, a description and a schema for its inputs. It is a draft report of the W3C Web Machine Learning Community Group, in a draft dated 26 August 2026, edited by engineers from Google and Microsoft, and Chrome is running it as an origin trial across versions 149 to 156.

Which AI agents can use these tools?

Any agent that runs inside a browser implementing the API, while the visitor is on the page. In practice that means Chrome versions 149 to 156 through the origin trial, or any Chrome with the WebMCP testing flag enabled. Nothing is exposed to search crawlers, and the tools send no personal data anywhere: the flight status tool makes the same request the page already makes for itself, and setting the date or passenger count triggers the same page refresh a human choosing a date does. Nothing else leaves the browser.

Can an AI agent pay for my balloon flight?

No. The prefill tool fills visible form fields and cannot submit the form. There is no payment tool at all. Card details and the 3D Secure code pass between the guest and their own bank, and card fields are excluded from the agent allowlist in code, so an agent asking to write a card number gets a rejection rather than a field.

Does this change anything if I never use an AI assistant?

No. Every access to the API is feature-detected. A browser without it renders the site exactly as before, with no extra scripts, no dependencies and no change to the booking flow. The feature adds nothing to the page for a visitor who is not using an agent.

What does the flight status tool return?

The same official data our flight status page shows: the status of sectors A, B and C as published by the civil aviation authority, the time that status was issued, and the sunrise and sunset for the day. An agent gets it as structured data instead of reading it off the page.

Is any other balloon operator doing this?

As of 10 September 2026 we are not aware of another balloon operator, in Cappadocia or elsewhere, exposing WebMCP tools. The standard is a draft published in August 2026, so the field is small by definition, and we would rather be corrected than overstate it.

What happens to these tools when the Chrome origin trial ends?

One of three things: the API ships, the API changes, or it goes away. The trial runs from Chrome 149 to Chrome 156, and a site opts in with a token tied to its origin. If it goes away, we delete a header and a hook, and no visitor notices anything different.