What is MCP and why all of travel is building a server
There is an acronym that in 2026 shows up at every conference, every press release and every travel tech budget: MCP. Sabre has it. SiteMinder adopted it. Spanish direct-booking vendors offer it. And most of the people mentioning it in meetings could not explain what it is. This article explains it without the fog.
The problem it solves
Let's start with the hole, not the tool. When an AI assistant tries to answer something operational about a hotel — is there availability over the December long weekend? does the rate include breakfast? can I cancel free on Tuesday? — it finds that this information is on no web page. A Mirai analysis (2025) quantified it: a hotel's website typically exposes between 5% and 10% of its real operational information. The rest lives in the booking engine, the PMS, PDFs and internal systems no crawler can read.
Until now, connecting each assistant to each system required a custom integration — multiplied by every assistant-system pair. That doesn't scale. Computing's classic answer to such bottlenecks is a common standard. That is MCP.
What it is, without metaphors (and with the official one)
The Model Context Protocol is an open protocol, created by Anthropic, that standardises how an AI model connects to external data sources and systems: it can query live information (availability, prices, policies) and execute actions (a booking, a change) through an "MCP server" the business publishes. The metaphor that stuck in the industry is "the USB-C of AI": every device used to have its own plug; now there is a common one.
In 2026 it stopped being a promise: it is the technical foundation of third-party apps inside ChatGPT (Booking's and Expedia's among them), and it has been adopted by players as different as Sabre — which launched its agentic APIs and MCP server in September 2025 — Turkish Airlines, Kiwi, Apaleo and, in the Spanish market, Mirai; SiteMinder joined in April 2026. Complementary protocols exist for the commerce and payment layer, both open but governed by their creators: UCP (Google with Shopify, Walmart and Target) and ACP (OpenAI with Stripe). They are not moving at the same speed: UCP already works in retail and its lodging version is on a waitlist — just as Google has started closing hotel bookings inside AI Mode in the United States — while OpenAI stepped back from checkout inside ChatGPT in March 2026 and left ACP as a connection layer for third-party apps.
What it does for a travel business
For a hotel or an agency, an MCP server has three functions (a scheme formulated by Mirai — an interested vendor, but the reference framework):
- Give assistants reliable context. The assistant stops guessing and queries: the answer on availability or policies comes from your systems, not from a page indexed months ago. It is the third layer of visibility we covered in the three layers: the only one that answers with certainty.
- Enable agentic commerce under your rules. If an AI agent wants to book, it does so against your engine and your commercial conditions — not against a stale copy of your inventory.
- Publish apps in assistant marketplaces, the equivalent of having your own presence where the traveller already converses.
The small print almost nobody mentions
Three caveats before signing anything. First: autodiscovery doesn't exist yet — assistants don't automatically find MCP servers; each one must be connected, and that gap is being filled by intermediary aggregators the industry itself criticises as "another toll" (TecnoHotel, December 2025). Second: a hands-on test by Skift (July 2026) showed chatbots sometimes ignore connected apps and answer on their own — the full chain is not yet reliable. Third, and most important: a connector only serves what your systems contain. If your rates, policies and services are not structured and current, the MCP server will serve confusion in real time.
Hence the industry's most repeated — and most ignored — advice: data first, agents second. The temptation is to start with the chatbot because it is visible; the right order is to sort the database because it is what everything else consumes.
What I would do, by size
- Independent hotel or small agency: you don't need to build an MCP server this quarter. You do need your operational information to exist in structured, consistent form (starting with your website and structured data), because it is the prerequisite for everything coming. When your booking engine or channel manager offers MCP as a feature — and it will — switching it on will be trivial if the data is right, and useless if it isn't.
- Chain or tour operator with in-house systems: the time to evaluate is now, with one guiding question: which part of our live data do we want assistants to be able to query, with what limits and what traceability? That — governance — is the serious conversation; the protocol is the easy part.
MCP is neither magic nor fashion: it is plumbing. And like all plumbing, you don't notice it when done well — but it decides what reaches the tap when someone, or something, turns it asking about your business.
