MCP as the New Distribution Rail

A distribution rail is a message format, a network, and whoever sits in the middle translating. Hotels have had three.

In the GDS era, availability and bookings moved as EDIFACT-style structured messages over private networks. A hotel's reservation system did not speak to Sabre, Amadeus or Galileo directly; a switch company translated between them, and the terminal in a travel agency was the only screen a guest ever saw. The rail was reliable and expensive, and every party on it took a per-booking fee.

The OTA era, 2000–present, moved the rail onto the public internet. The OpenTravel Alliance's XML schemas, and later JSON over REST, standardized the messages; channel managers took over the switch's role, pushing availability, rates and inventory (ARI) to each OTA extranet and pulling reservations back. It worked well enough that 74% of US hotel bookings came to flow through this stack. It also meant a hotel's inventory existed as many copies, one per channel, each reconciled by hand when they drifted, and each channel setting its own terms for the copy it held.

The third rail reached production in March 2026. A hotel, or the CRS or PMS acting for it, publishes an MCP server; an assistant such as ChatGPT, Claude or Gemini queries it at the moment a traveler asks a question. There is no scrape of the hotel's website, no duplicated inventory in a platform database, and no intermediary markup between the published rate and the one the traveler sees. The March 2026 Inflection reconstructs how quickly it arrived; this article is about how it works and who should own it.

Model Context Protocol is an open specification, released by Anthropic in November 2024, for connecting an AI application to external tools and data. Its architecture has three roles. The host is the AI application the person is using: a chat assistant, a coding tool, a browser. The host runs one or more clients, each holding a single connection to a server. The server is the thing that exposes capabilities, and in our case it is the hotel's.

Messages travel as JSON-RPC 2.0 over a transport, either a local process pipe or HTTP for remote servers. On connection the two sides negotiate capabilities; after that the server can offer three kinds of thing.

• Tools: functions the model may call, each with a name, a description and a JSON schema for its arguments, such as search_availability or create_booking. The client lists them with tools/list and invokes them with tools/call.
• Resources: read-only data addressed by URI that the application can load as context, such as a property description, a room-type catalog or a cancellation policy.
• Prompts: reusable templates the user can select, such as a booking-assistant or concierge flow, which shape how the model uses the tools and resources.

The consequence for a hotel is that one server serves every compliant assistant. During 2025 OpenAI, Microsoft and Google adopted the protocol, and Anthropic moved its governance into a Linux Foundation project, which answered the single-vendor concern the alliance and others had raised. Authorization for remote servers uses an OAuth-based framework that is still maturing, and that immaturity is the main technical caveat in the sections that follow.

The listing is illustrative, but its shape is the point: the tool names and argument schemas are the contract. If every PMS vendor ships a different contract, an assistant needs a different integration per vendor and the fragmentation of the API era returns under a new name. That is why standard tool schemas are the first deliverable of the alliance's rate and inventory work.

Three properties of the new rail change the economics. They are worth stating precisely, because vendors will claim all three whether or not they deliver them.

No scraping. Assistants have been answering hotel questions for two years from whatever they could read on the open web, which in practice meant OTA listings and stale brand pages. An MCP server gives the assistant a verified answer from the system of record at the moment of the question. The hotel controls what is published, including the rate and the cancellation terms the traveler sees.

No duplication. In the channel-manager model the hotel's ARI is copied into every extranet and the copies drift. MCP is pull, not push: the data stays in the PMS or CRS and is read when needed. There is nothing to reconcile because there is no second copy.

No intermediary markup. When the traveler is routed to the hotel's own booking engine, or the booking is created through the hotel's own endpoint, the hotel is merchant of record. There is no commission in the path and no third party holding the guest's contact details. The guest relationship arrives with the booking rather than at check-in.

That is the limit of the rail. A wrong booking, a no-show, a chargeback filed 90 days later: MCP has nothing to say about any of it. The Dispute Resolution Working Group exists because the rail needs a trust layer beside it, and The Consumer Trust Gap explains why travelers will not delegate booking until one exists.

Three implementations went live in the same fortnight, and they illustrate three different places the server can sit.

Aven, the former Sabre hotel technology unit acquired by TPG for $1.1B, is embedding MCP across SynXis. Because SynXis is already the system of record for its 35,000+ hotels' availability, rates and inventory, the server answers from the source. For a property on SynXis the operative questions are which assistants are connected, whether member and negotiated rates are exposed, and what the connection costs.

Agentic Hospitality's TravelOS MCP Server, launched in early March from Louisville, Kentucky, is a bridge: it connects an existing CRS or PMS to the assistants without replacing it, without duplicating inventory and without a separate booking system. The company claims integrations with 700+ PMS and CRS providers, adds a Schema.org structured-data layer, and charges a flat license rather than a commission. It also reports the first MCP-originated booking, in September 2025, at a five-unit property in Dominica: a ChatGPT query for a full-house rental with air-conditioned bedrooms resolved to a direct booking with the property as merchant of record. The anecdote is the thesis in miniature. The smallest property answered a question the OTAs could not.

Lighthouse's Hotels Network app in ChatGPT, launched March 4, sits at the platform. Any hotel can join without a custom integration; the property connects over MCP, its verified data feeds the conversation, and the traveler is routed to the hotel's website to book. The model is a flat subscription with no commission on bookings. Minor Hotels, One&Only Resorts and Preferred Hotels were among the early participants. Sabre's SabreMosaic platform and GuestCentric's Melissa sales agent round out the month, one at GDS scale and one at the booking engine.

What they share is the important part: MCP as the rail, the hotel as merchant of record, and a fee that does not rise with ADR. What separates them is position. The CRS-embedded model and the platform app both leave the hotel dependent on a party at the protocol layer; the bridge does too, however good its terms. Only a server the PMS itself publishes leaves the hotel holding the endpoint. That is the design choice the alliance's own reference implementation made, and it is the one we recommend to vendors.

MCP is the rail with hotel adoption. Three other protocols are regularly named alongside it, and they do not compete with it so much as sit at other layers. The table records purpose, authorship, what moves and where a hotel plugs in, as of March 2026.

The layering is what operators should watch. MCP is the discovery and tool layer, and it is where hotels connect today. A2A describes the autonomous future in which a traveler's agent negotiates rate, loyalty recognition and cancellation terms with a hotel's agent; it is not deployed in hospitality. UCP and AP2 are Google's transaction and payment layer, and together with browser-native MCP support in Chrome 146 they form a full stack. Your Hotel Should Speak Every Language puts the risk plainly: if that stack succeeds, MCP becomes the discovery layer and one company's protocols become the transaction layer. The answer is not to avoid Google's rails. It is to keep the canonical data and the booking endpoint on the hotel's side of every one of them.

The right move depends on where a property's system of record lives and what its vendor is willing to ship. The matrix is the alliance's recommendation for the common cases.

The first movers are useful. They proved the rail works and forced the platforms to take hotel data seriously. The alliance's disagreement is narrow and structural: an MCP endpoint should be an open standard a PMS implements, not a proprietary layer a hotel rents. Concretely, ADAPT advocates five things.

1. An open MCP server specification for hotel PMS and CRS systems, published by the alliance and free to implement.
2. Standard tool schemas across vendors for search, book, cancel and modify, so an assistant integrates once.
3. The hotel as merchant of record in every MCP-mediated transaction.
4. No commission at the protocol layer: a flat infrastructure cost only, with total distribution cost under 8%.
5. Interoperability: any compliant hotel server works with any compliant assistant, with no exclusive lanes.

The principle underneath all five is that the hotel owns the canonical data layer. Rooms, rate plans, restrictions, policies, photos and guest history live in the PMS and are exposed through adapters. MCP is the adapter that matters in 2026; a REST API, a CLI and an agentic markdown file are adapters too, and whatever follows A2A will be another. A property that owns the layer adds an adapter when a protocol arrives. A property that rents the layer changes vendors. Your Hotel Should Speak Every Language develops this argument and the revenue math behind it.

For a PMS vendor, or an operator with engineering capacity, the path to a protocol-native integration is well understood. The alliance's reference implementation at the Exchange Building followed it, and the steps are ordered so that each is useful on its own.

1. 1

   Canonical data layer

   Give every room type, rate plan, restriction, policy and photo a stable identifier in the PMS. Publish Schema.org Hotel, HotelRoom and Offer markup and a /.well-known/hotel.md file from the same data. Assistants can use these today with no server at all.

2. 2

   Read-only MCP server

   Expose resources for property, room types and policies, and the search_availability and get_rates tools, over the HTTP transport. Log every call with the calling platform. This is the AI-enhanced search model, live.

3. 3

   Authorization and limits

   Adopt the specification's OAuth-based authorization for remote clients, per-platform scopes and rate limits, and an audit trail. Treat the authorization layer as immature and keep it isolated from the write path.

4. 4

   Write path

   Add create_booking, modify_booking and cancel_booking with idempotency keys, timed holds and explicit failure states. Settle through the existing gateway with the hotel as merchant of record, and shape the interface so programmable settlement can replace the gateway later without changing the tools.

5. 5

   Discovery and registries

   List the server in the platforms' app and connector directories and publish an agent card so agent frameworks can find it. Adopt the WG-003 tool schemas as they are ratified, so one integration serves every vendor's customers.

6. 6

   Trust hooks

   Tag every agent-sourced booking, reconcile it separately, and expose the fields the Dispute Resolution Working Group needs: booking source, terms as presented, guest trust status. This is what turns a rail into a market.

WG-003 (Rate & Inventory Protocol) carries this work: standardized ARI publishing for MCP servers, room-type and rate-plan structures, and restriction encoding. PMS vendors who would rather shape the tool set than inherit it should join through the PMS track. The history of the previous two rails is in the deep dive, and the lesson of both is the same: whoever owned the translation layer ended up owning the terms.