Your Hotel Should Speak Every Language

For the whole OTA era — 2000 to the present — the hotel technology stack has been organized around a layer the hotel did not own. The channel manager translated the PMS into whatever each platform wanted; the platform owned the listing, the guest record, and the terms. By 2020, roughly 74% of US hotel bookings flowed through that channel-manager stack. Hotels did not lose the argument about distribution. They lost control of the structured data layer between the room and the person who wanted it, and rented it back at 15–25%.

The agentic era is forming the same pattern one layer up. Proprietary MCP servers now sit between properties and AI platforms — a flat license instead of a commission, but still a vendor in the middle. If MCP wins and your MCP server is someone else's, you have traded one landlord for another. The strategic question is therefore not which protocol wins. It is who controls the structured data layer between your property and the agent that books it.

This article compares the three interfaces an agent can use to reach a hotel — a command-line interface, a REST or GraphQL API, and a Model Context Protocol server — not as competing standards but as parallel adapters over one canonical data layer the hotel owns. It then follows the money: the settlement rail, the fee arithmetic at Exchange Building scale, and what the current vendors do and do not address. It ends with a five-step playbook for independent operators.

CLI: the developer's tool

A command-line interface is the lightest interface a hotel can offer: a binary, no SDK, no authentication ceremony beyond an API key in an environment variable. It composes with pipes and scripts, runs inside CI pipelines and cron jobs, and works without a persistent connection. Its users are developer agents, automation scripts, infrastructure teams, and self-hosted assistants working in a terminal. Very few travelers will ever type building-os search. The agents that serve those travelers might reach for it first, because the developers building them already live there. Hotel adoption today is near zero — which is the opportunity, not the objection.

REST and GraphQL: the established rail

Every OTA, GDS, and PMS already speaks REST or GraphQL. The tooling is mature: OpenAPI specifications, OAuth 2.0, rate limiting, versioning, monitoring. Large language models call these APIs directly through function calling, so no special protocol is required to make a REST endpoint agent-usable. The weakness is fragmentation. Every property and platform has its own API shape, so an agent that wants to search ten properties needs ten integrations. That is the problem MCP was designed to solve.

MCP: the AI-native standard

Model Context Protocol, published by Anthropic in November 2024, gives an agent one standard way to discover and call tools, read resources, and use prompts. Build one MCP server and any MCP-compatible platform — ChatGPT, Claude, Gemini — can connect; discovery is built in, so the agent inspects what tools exist instead of reading documentation. OpenAI, Google, and Microsoft adopted it, and governance moved to a Linux Foundation project in 2025. Its limitations are those of a young protocol: the authentication story is still evolving, tool descriptions consume context, and much of what gets blamed on MCP is a harness problem in the calling software rather than the protocol itself. MCP as the New Distribution Rail covers the architecture in depth; here it is one adapter among three.

The three listings above return the same studio, at the same rate, from the same PMS. Nothing about the room changed between them. Only the adapter did.

No column wins the matrix, and that is the point. The CLI is best for the developer building the next agent; the API is best for every channel that already exists; MCP is best for the AI platforms where travelers now start their search. A hotel that can speak only one of them has chosen its customers by accident. The governance row deserves a second look: REST rides on decades of IETF and W3C process, while MCP's stewardship is barely a year old. That argues for treating MCP as an adapter you can swap, not a foundation you pour.

Google is assembling a full stack for agentic commerce, and hotels should read it as a set rather than as separate announcements. Agent2Agent (A2A, April 2025) lets agents negotiate with agents — a personal assistant working out availability, rate, loyalty recognition, and cancellation terms with a hotel's agent — and remains conceptual in hospitality. The Universal Commerce Protocol (UCP, announced January 2026 at the National Retail Federation conference) standardizes how an agent evaluates and buys; the report records it as live in retail and in development for travel, where fare rules, cancellation policies, and payment risk complicate the model. The Agent Payments Protocol (AP2, September 2025) is the payment layer. And Chrome 146's native MCP support puts an agent-capable client in the browser itself — see Chrome 146, MCP, and the Agentic Browser. On the other side of the market, OpenAI's Agentic Commerce Protocol with Stripe (September 2025) describes a parallel checkout path.

The report's warning is direct: if the Google stack succeeds, MCP becomes the discovery layer and Google's protocols become the transaction layer, which concentrates a great deal of power in one company. The operator's response is not to bet against Google, or for it. It is to keep the canonical data layer in-house so that A2A, UCP, AP2, or whatever follows them arrives as one more adapter over data you already own.

Discovery and booking are only two-thirds of the transaction. The agent also has to pay, and here the report introduces x402 — an open, HTTP-native payment protocol for machine-to-machine settlement, published in 2025. It revives the HTTP 402 “Payment Required” status code, dormant since the 1990s, as a native payment step. The flow is four lines long: the agent requests the booking; the server answers 402 with the amount and settlement instructions; the agent's payment client retries the request with a signed payment receipt in a header; the server verifies the receipt and confirms. Settlement completes in seconds, the protocol itself charges no fee, and the report puts the network cost at a fraction of a cent per transaction.

The obvious objection is that travelers do not hold a machine-to-machine payment instrument, and the report's answer is that they do not need to. The guest pays their agent by card, as they do today; the agent settles with the hotel over x402. Be precise about what that changes. The card cost does not vanish from the economy; it moves to the guest–agent relationship, where the agent platform prices it. What leaves the hotel's P&L is the merchant-side fee and the chargeback exposure — on the report's numbers, about $4 on a $129 night, and a 30- to 60-day wait when the booking came through an OTA.

Note what else leaves with the chargeback: the traveler's most familiar remedy. A rail with no chargebacks is good for a hotel's fraud losses and bad for a guest's confidence unless something replaces it. That is why ADAPT treats dispute resolution as a protocol-level requirement rather than a vendor add-on — the argument The Consumer Trust Gap makes at length.

The report's headline figure is $272,000 a year recaptured at Exchange Building scale. It is a worked illustration, not a measurement, and it should be read with its assumptions attached: a 200+ unit property, roughly 10,000 bookings a year, an average booking value of $129, every booking arriving through an OTA at an 18% commission and paid by card at 2.9% plus 30¢, and every one of those bookings moving to protocol-native direct distribution settled machine to machine.

That $272K is the size of the fee pool under those assumptions, not ADAPT's promised saving. ADAPT's own target is a total distribution cost under 8%, which on the same $1.29 million is roughly $103,000; the dispute framework proposes a 0.5–1.0% network fee inside that; and the local guide commission, where a property uses it, is an optional 2%. Nor is any real property 100% OTA. A more conservative reading — 60% of bookings OTA-sourced at 18%, moved to a channel costing 8% all-in — recaptures 10 points on 6,000 bookings, about $77,000 a year before card savings. The order of magnitude survives. The headline should not be quoted as a promise.

Where the money goes matters as much as how much. On a $100 night the report traces $18 to Amsterdam with Booking.com, $20 to Seattle with Expedia, a flat fee to Louisville with a proprietary MCP vendor, and, on a protocol-native direct booking, $97–100 staying with the property before ADAPT's own network fee and any local guide commission — money that goes to wages, local vendors, and capital improvements in a 1910 building. That is the BookLocal argument in one row. It is not an argument that OTAs do nothing for the money; they build demand and still deliver it, and most independents will run both channels for years. It is an argument about the terms, and about who sets them.

Three proprietary MCP vendors make up the current field, and all three are capable. Agentic Hospitality (Louisville, Kentucky) launched its TravelOS MCP Server in March 2026, connecting existing CRS and PMS systems to AI platforms on a flat, undisclosed license, and describes a Dominica short-term rental booked through ChatGPT on September 15, 2025 as the first MCP hotel booking. Cendyn's AI Connect, as the report describes it, is sold with a subscription and Cendyn's data-management platform and pushes availability, rates, and inventory on the hotel's behalf. 1stay.ai claims an index of 650,000 hotels reachable through a handful of MCP tools, on terms it has not disclosed. Each removes the commission. Each also places the vendor in control of the MCP layer — different branding, same dependency.

Five steps, in the order an independent operator should take them. The first is the prerequisite for all of the others.

1. 1

   Own your structured data

   Schema.org markup for the property and every room type, clean rates with taxes and fees disclosed, machine-readable policies, multilingual descriptions. If the data is not structured, the property is invisible to agents on every protocol — CLI, API, MCP, and whatever comes next.

2. 2

   Use a PMS that speaks multiple interfaces natively

   Not “we have an MCP integration through a partner.” The PMS itself should expose CLI, API, and MCP endpoints over the same canonical data. When a new protocol emerges, the PMS adds an adapter and the hotel does not change vendors.

3. 3

   Do not pay for protocol access

   MCP is an open protocol. If someone charges a fee to “put your hotel on MCP,” that is the OTA tax with different branding. A flat fee is better than a commission, but a vendor-controlled MCP layer is still a layer you do not own.

4. 4

   Demand dispute resolution at the protocol level

   Ask any vendor what happens when a guest disputes a charge made through their MCP server. If the answer is silence, that silence is your risk exposure — and it is what ADAPT's Dispute Resolution Working Group exists to fill.

5. 5

   Measure local economy retention

   Track the effective distribution cost of every channel, including card fees and settlement delay, and optimize for the channels that keep revenue in the property and the community. That is the number that matters, and it is the one no extranet reports.

ADAPT's position is that the hotel should own the canonical data layer and let protocols come and go on top of it. Concretely, that layer is: Schema.org markup for the property and its rooms; clean, unambiguous rates with taxes and fees disclosed; machine-readable policies — cancellation windows, deposits, minimum stays, house rules — encoded rather than described; and multilingual descriptions, so that an agent serving a traveler in Tashkent reads the same facts as one serving a traveler in Nashville. Over that layer the PMS exposes adapters: CLI, REST, MCP, a /.well-known/hotel.md file for agents that read markdown, and a settlement adapter for programmable settlement. When a new protocol arrives, the PMS adds an adapter. The hotel does not change vendors.

The work sits in three places. The proposed WG-003, Rate & Inventory Protocol, carries the standardized ARI schema — room type schemas, rate plan structures, restriction encoding — that turns “clean rates” from an aspiration into a specification. The Hospitality Operations Working Group carries the operations surface, the open folio CLI and MCP client speaking ADAPT-HOP, so the same data layer that serves agents also runs housekeeping, access, and settlement. And the PMS vendor guidance track on the working groups page exists so that any property management system, not one reference implementation, can become protocol-native. The pilot at the Exchange Building runs this design on Building OS, but nothing in the design depends on it. Protocols come and go. The data is the constant, and it should be yours.