Chrome 146, MCP, and the Agentic Browser

Google Chrome 146 introduced native support for Model Context Protocol, which lets an AI agent work through the browser itself: read a page, fill a form, complete a transaction and take in structured data, without scraping the screen or depending on the fragile selectors that broke every time a site changed its layout. This article stays at that level of description. Capability details belong in Chrome's release notes and will change; the pattern will not.

The browser is the layer worth watching because it is where the human interface lives. Assistants have reached hotels in two ways so far: through structured back doors, meaning APIs and MCP servers, and through the front door, meaning a browser agent driving the same website a person would. The front door has been the brittle path. A browser that speaks MCP narrows the gap between the two, because a site can hand the agent structure directly instead of forcing it to infer structure from pixels.

Chrome is not alone. Over 2025 the major AI companies each shipped or previewed a browser or browser agent of their own, and a proposal for how websites should declare tools to in-browser agents is being incubated in the W3C's Web Machine Learning Community Group. For an operator the product names matter less than the direction: the browser is becoming agent-aware, and the most widely installed one now has MCP support built in.

Set the browser beside the other layers and the pattern is hard to miss. Each layer added a way for an agent to act as a user would, and each did so within the last two years.

Read down the right-hand column and one requirement repeats: structured, verified, machine-readable property data, owned by the hotel and served from its system of record. Every layer assumes it exists. Most independent hotels do not yet have it.

Start at the bottom. A neural processing unit is now a standard component of new consumer hardware, and the operating systems above it are being rebuilt to run assistants locally. Apple ships on-device models and a developer framework for calling them; Microsoft's Copilot+ PC specification sets a floor of 40 trillion operations per second for the NPU. The practical result is that a growing share of guest queries will be answered on the device, from whatever the assistant can reach, before a search engine is involved.

The OS layer is where tool use became a system feature. Apple's App Intents let an app declare the actions the system assistant may perform on the user's behalf. Microsoft announced at its 2025 developer conference that Windows would support MCP natively, with a registry of local servers and consent prompts around each action. The operator's takeaway is not to build for any one of them. It is that the assistant will be present by default on the guest's device, with the ability to act, and it will need something to act on.

The payment layer moved fastest in 2025 and 2026, because agent-initiated purchases cannot run on the assumption that a human is present at checkout. Google announced the Agent Payments Protocol (AP2) in September 2025 with payment-network partners; it records what the user authorized as a signed mandate that travels with the payment. The Universal Commerce Protocol (UCP), announced at NRF in January 2026, standardizes how an agent evaluates and purchases from a merchant; it is live in retail with a travel adaptation in development. The card networks announced their own agent-payment programs in 2025. x402 is an open, HTTP-native payment protocol for machine-to-machine settlement, with a growing set of infrastructure backers.

The alliance's protocol interfaces report tracks these four as a single stack, and its warning bears repeating: if the stack succeeds, MCP becomes the discovery layer and one company's protocols become the transaction layer. That concentrates power in the same place the search auction did. The response is not to refuse the rails. It is to make sure the data an agent reads and the endpoint it books through are the hotel's, so that any rail, Google's or another, carries the hotel's terms rather than an intermediary's. That is what the alliance means by programmable settlement: terms travel with the transaction and are enforced by protocol, not by trust in an intermediary.

The application layer is where hotels actually connect, and it moved in March 2026. Aven is embedding MCP across the SynXis central reservation system, which holds the availability, rates and inventory of 35,000+ hotels. Agentic Hospitality's TravelOS MCP Server bridges existing PMS and CRS systems to the assistants. Sabre has built MCP into its platform. Perplexity already books roughly 140,000 hotels through Selfbook. The alliance's own reference PMS at the Exchange Building publishes an MCP server, a REST API, a CLI and an agentic markdown file from one canonical data layer, across 200+ units and four revenue modes. MCP as the New Distribution Rail covers the architecture and the vendor choices.

The commerce layer is the least settled. OpenAI stepped back from in-chat travel checkout in March 2026 and kept the discovery role. Google is tiering AI Mode's booking by partnership, with in-chat checkout for named partners and a link out for everyone else. A2A specifies how a traveler's agent and a hotel's agent would negotiate rate, loyalty recognition and cancellation terms, and it is not yet deployed in hospitality. What is settled is the direction: the transaction is moving toward the supplier's own endpoint, and the contest is over who is present at discovery and on what terms.

The first risk is the strongest argument for publishing structure rather than relying on the browser to infer it. A site that exposes its rooms, rates and policies as data, and its booking as a tool, gives the agent a stable contract that survives a redesign. The second and third are not technology problems. They are the reason the alliance runs a Dispute Resolution Working Group with localized arbiters and a guest trust mechanism, and why The Consumer Trust Gap argues that trust infrastructure, not model quality, gates autonomous booking.

There is a fourth risk that belongs to the platforms rather than the hotels: concentration. A browser vendor that is also the search engine, the author of the shopping protocol and the payment orchestrator holds more of the stack than any OTA ever did. Open protocols with neutral governance, and hotel-owned endpoints, are the only structural check on that. The alliance's position toward every platform is the same as its position toward the OTAs: welcome the demand, refuse the gatekeeper terms.

None of this requires a new vendor to start. The steps below are ordered by cost, and the first three can be done by a general manager with a laptop and a PMS login.

1. 1

   See what the agent sees

   Fetch your own website as plain text and as structured data. If the rooms, rates, policies and address are not legible without the layout, an agent is guessing at them. Check that your robots and access policies do not block well-behaved agents by default.

2. 2

   Publish the structure

   Add Schema.org Hotel, HotelRoom and Offer markup and a /.well-known/hotel.md file generated from the PMS. This is the zero-infrastructure step, and it works with every layer in the table above.

3. 3

   Ask your PMS three questions

   Will you publish a native MCP server, and when? Is the hotel merchant of record on every booking it creates? Is there any per-booking fee? A vendor that answers no, no and yes is selling the commission model again.

4. 4

   Set an agent access policy

   Decide which agent platforms you allow, log agent-originated sessions and bookings, and require authorization on any write path. Consent and audit are cheaper to design in now than to retrofit.

5. 5

   Instrument the channel

   Tag assistant-referred sessions and bookings separately from search and OTA traffic. In a year those numbers will decide your OTA negotiation and your vendor renewals.

6. 6

   Join the standards work

   WG-003 (Rate & Inventory Protocol) is setting the tool schemas your PMS should implement; the PMS track is where vendors commit; the Dispute Resolution Working Group is building the accountability layer the browser will not.

The OTA adoption curve took roughly five years, from 1996 to 2001, and the alliance's own FAQ suggests mainstream agent booking may take three to five years because travelers have to learn to trust it. Both are probably right about consumers. Neither describes the infrastructure. Chrome ships a new major version about every four weeks, and has since 2021. A capability that is a preview in one release is a default a few releases later; the operating systems and payment networks are on annual cycles at most. The layers beneath a hotel's distribution will finish converting long before its guests finish deciding, and a property that waits for the consumer signal will find the stack already set around it.

That is why the window to adapt is measured in browser release cycles. It is not that bookings will move overnight. It is that the defaults are being written now, and defaults written without operators in the room will be written for platforms and vendors.

What ADAPT's working groups need from PMS vendors is specific. From the PMS track: a native MCP server in the core product, the hotel as merchant of record on every booking, infrastructure pricing with no per-booking cut, and a commitment to the common tool schemas so one integration serves every property. From vendors and operators together in WG-003: standardized ARI publishing, room-type and rate-plan structures, and restriction encoding that behaves identically across systems. From the Dispute Resolution Working Group and the guest identity work: the booking-source, terms-as-presented and trust-status fields that let an arbiter answer for the machine in between. The browser has done its part. The property system is the layer that is still ours to write.