Why This Matters, Without the Technical Detail
Most independent hospitality operators do not need to know how the Model Context Protocol works at a technical level. They do, however, need to know that it exists, that it became available on a specific date, and that its arrival is the reason the El Dorado Report's central argument is now operationally true rather than merely directionally correct.
This spoke explains what MCP actually is, written for an operator running a vacation rental, a small hotel group, or a property management business — not for a software engineer. It explains why MCP matters specifically for hospitality, what concrete capabilities it makes available that did not exist before, what to look for in tools that claim to use it, and what the operator should expect over the next two to three years as the ecosystem matures.
The objective is not to make the operator technical. It is to give them enough of a frame of reference to evaluate tools and recognise the difference between real capability and marketing labels.
What MCP Is

The simplest way to think about MCP is as a common language between AI tools and the data sources an operator already uses. The official analogy used in the technical documentation is USB-C: a single standard plug that lets any device connect to any source, replacing the previous era when every device needed its own custom cable.
Before MCP
Every AI tool that wanted to access an operator's data — messages, calendar, reviews, payment records, anything else — needed a custom integration built specifically for that tool and that data source. If an operator wanted an AI assistant that could read their Airbnb messages, the tool needed a custom Airbnb integration. WhatsApp, separate. The PMS, separate. Each integration took engineering effort to build, broke when the underlying platform changed, and only worked between that specific tool and that specific data source.
The cost of building these integrations was the dominant reason that conversational data access was previously exclusive to operators with engineering teams or six-figure software budgets.
After MCP
MCP defines a standard way for AI tools and data sources to talk. A data source — Airbnb, a PMS, WhatsApp, anything else — exposes its data through an MCP server. An AI tool that supports MCP can then connect to any MCP server without needing a custom integration built for it specifically. The server-side work is done once; every AI tool that supports the protocol gets access automatically.
The cost of an AI tool gaining access to a new data source dropped from "weeks of engineering work per integration" to "seconds, if the MCP server already exists." The economics of conversational data access flipped.
What Changed on November 25, 2024
The Model Context Protocol was launched by Anthropic as an open standard on November 25, 2024. Open-sourced. Free for anyone to implement. Licensed in a way that lets any company build MCP servers for their data and any tool builder support MCP without permission or fee.
What turned the launch into a watershed moment was the speed of industry adoption. By March 2025, OpenAI had committed to MCP across its developer tools and ChatGPT desktop application. By April 2025, Google DeepMind confirmed MCP support in Gemini. By the end of 2025, Anthropic had donated MCP's stewardship to the Linux Foundation, which means the protocol is now governed neutrally by a recognised industry-standards body. Microsoft, AWS, and most major SaaS platforms shipped MCP support over the same period.
MCP is no longer an Anthropic project.
It is the de facto standard for how AI tools connect to data sources, with cross-vendor support strong enough that an operator choosing tools today does not need to bet on which AI vendor wins the next generation. The protocol itself is durable because no single company controls it.
The relevance for an independent hospitality operator is straightforward. The reason the El Dorado Report could be written in 2026 and could not have been written in November 2023 is that the underlying capability — conversational access to first-party data — went from a research-grade prototype to a working standard with industry-wide adoption inside a single eighteen-month window.
What This Means for Hospitality
The hospitality sector has a particular shape of fragmented data that MCP addresses well. Operators run on Airbnb, Booking.com, Vrbo, and one or more direct booking platforms. They communicate via WhatsApp, email, phone, and the platforms' native messaging. They use a PMS, a channel manager, sometimes a revenue management tool, sometimes a pricing tool, often spreadsheets.
Before MCP: a practical example
The analytical question "which property in my portfolio loses the most inquiries during evening hours, in which languages?" required combining data from at least four different systems, each of which exposed its data through a different mechanism, none of which talked to each other natively. Answering the question required either custom development or an entire afternoon of manual cross-platform review. The result was that operators rarely asked questions like that, because the cost of answering them exceeded the perceived value of the answer.
After MCP
The same question can be addressed by a single conversational interface that connects to the relevant MCP servers and reads across them in a single operation. The operator types the question; the tool retrieves the data; the answer arrives in a few seconds. The marginal cost of asking ten questions is essentially zero.
Capabilities now available to independent operators
- Guest message history across all platforms in a single view
- Pre-booking inquiry patterns paired with post-stay review themes
- Response-time gaps by time of day across actual inquiry timestamps
- Conversion pattern segmentation by guest origin language
- Recurring questions flagging listing copy failures
- Inquiry-to-booking ratio comparison across properties in a portfolio
- Review themes matched against pre-arrival communication content
None of these capabilities were operationally available to independent operators before late 2024 except by hiring custom development or running multi-week consulting engagements. All of them are now available through commercially-available tools that support the standard.
What to Look For in Tools
The arrival of MCP has produced a noticeable shift in the hospitality SaaS landscape. Vendors are using "AI" as a marketing label more loosely than before — sometimes meaning "we built on MCP" and sometimes meaning "we added a chat box to our existing dashboard." For an independent operator considering tools, the practical question is how to tell which tools are using the underlying capability shift to deliver real operational change.
Does it read your existing data, or only data inside its own system?
The capability shift MCP enables is reading across the operator's existing data sources — platform messages, WhatsApp, reviews, the PMS — without forcing the operator to migrate their workflow into the vendor's silo. Tools that claim AI capability but only operate inside their own platform are not delivering the underlying shift.
Does it support multiple data sources, or only one?
The analytical value of MCP-derived capability comes from cross-source pattern recognition. A tool that only reads one source is providing thinner value than a tool that reads several. A tool that connects to Airbnb but not WhatsApp, or to reviews but not messages, is a partial implementation.
Does it produce specific, evidence-grounded answers, or generic templated content?
An MCP-enabled tool reading the operator's actual data should produce answers specific to that operator: 'your conversion drops by X% on inquiries arriving between 8pm and midnight, particularly in German.' A tool producing generic answers is not actually reading the operator's data.
Does the vendor explain what they connect to, in plain language?
Vendors building real MCP-enabled capability typically can describe, in concrete terms, which data sources their tool reads and what operational questions it can answer. Vendors who use AI as a marketing label without underlying capability tend to default to abstract language about 'intelligence' and 'insights' without specifying the actual data flow.
Does the tool depend on lock-in, or does it travel with the operator?
MCP is an open standard. Tools built on MCP are, in principle, portable: an operator can switch from one MCP-enabled tool to another without losing the data integrations, because the integrations live in the MCP servers. Vendors building proprietary extensions that lock the operator in should be evaluated more cautiously.
What MCP Doesn't Do
The capability shift is real, but the marketing around it has begun to overstate what it changes. Several honest disclosures.
MCP does not eliminate the need for human judgement
The operator is still the person making decisions; the tools are surfacing information faster and more comprehensively, but the interpretation and the action are operator work. An operator who expects an MCP-enabled tool to make decisions for them will be disappointed in the same way an operator who expected dashboards to make decisions was disappointed in the previous era.
MCP does not magically clean up the operator's data
Bad data, fragmented record-keeping, missing message history, voicemails that were never logged — none of these are resolved by the protocol. MCP makes existing data more accessible to AI tools; it does not generate data that does not exist. Operators with weak data hygiene will find that MCP-enabled tools surface the gaps in their data more clearly, which is useful, but the underlying gaps are operator work to close.
MCP is not a guarantee of quality
The protocol is a standard for connection, not a standard for output quality. An MCP-enabled tool can still produce poor answers if the underlying AI model is weak, if the prompts are badly engineered, or if the data being read is incomplete. Operators evaluating tools should focus on the quality of the actual answers produced against their actual data, not on whether the tool ticks the MCP-compliance box.
MCP is not a privacy or security framework
Operators handing data access to tools — MCP-enabled or otherwise — should still evaluate the vendor's data handling practices, the residency of the data, the access controls, and the operator's ability to revoke access. The protocol is neutral on privacy; the vendor's implementation is what matters.
The Window
In 2026, MCP-derived capability is a meaningful operator advantage. By 2028, it will be normal practice. By 2030, it will be expected baseline. The trajectory follows the typical adoption curve of an industry-wide technology shift, accelerated by the unusually fast cross-vendor adoption pattern MCP has shown.
The operators using MCP-derived capability now compound their advantage during the window. The operators who arrive late will be working in a market where the practice has already become standard — and the differentiation has already flattened.
Most operators have not yet engaged with MCP-based tools. Most operators do not yet know what MCP is. The gap between "available to those who look" and "standard practice across the industry" is currently wide. The data has always been there. The cost of reading the data is what changed in late 2024.
An independent hospitality operator does not need to understand MCP at a technical level to act on it. They need to recognise that the standard exists, that its arrival in late 2024 is the reason previously-impossible capabilities are now operationally available, and that the tools they consider going forward should be evaluated against the practical checklist above — not against the marketing label of "AI."
