The Role of Aggregators in the AI-Driven Travel Ecosystem
11 min read
Artificial intelligence is reshaping how travelers explore, plan, and book trips. The introduction of Model Context Protocol (MCP) promises a direct line for hotels to provide accurate pricing and availability to AI systems. There have been some optimistic claims that MCP could dramatically reduce hotels’ reliance on aggregators like OTAs. And there have been counter claims that the OTAs are poised to increase their dominance by becoming exclusive partners to the most popular AI companies.
We believe that even with MCP, the role of aggregators remains indispensable. This paper explains why aggregation is critical in ensuring scalability, efficiency, and trust in the AI-driven travel ecosystem while also noting that there’s an opening here for a new class of aggregator: one aligned with the hotels themselves.
The Shift Toward AI in Travel
Foundational AI models have transformed consumer behavior. Travelers increasingly rely on conversational queries rather than keyword searches, asking broad, open-ended questions such as:
“What’s the best neighborhood to stay in Paris for a family?”
“Which hotels in Tokyo have spas and allow loyalty redemptions?”
The stage where AI struggles the most is in helping travelers select exactly where to stay because they need real-time data: inventory, prices, and availability for specific dates. This dataset isn’t easily compressible or predictable, and it changes more than daily, so it doesn’t play to LLMs strengths. This data cannot be encoded in foundational AI models.
Model Context Protocol (MCP) is a new AI-native integration layer, an open standard that allows companies to provide structured information, like prices and availability, to foundational AIs. It enables AI systems to retrieve the most current, accurate, and comprehensive data, allowing them to craft the very best responses to queries, and so present a great answer to travelers.
In our first whitepaper we outlined the role of MCP and the clear benefits to suppliers. In our second whitepaper, we explored how MCP can be used to provide consumers tailored information about prices, property features, special offers, by keying off consumers’ unique travel criteria. This paper explores why the industry needs an MCP aggregator.
An MCP Aggregator model vs. Individual MCPs: the Look-to-Book problem
Just as every hotel today maintains its own website, it’s possible that each will eventually operate an individual MCP server, making it directly accessible to AIs. However, Foundational AIs relying on these individual hotel MCP servers will quickly encounter major scaling challenges, as will the hotels’ own MCP server or website.
Consider a typical traveler's request: “Find me a nice hotel in Berlin next weekend.” To be considered by the traveler (or by their agentic tool), every hotel in Berlin must provide real-time pricing and availability. If a hotel’s website or MCP server doesn’t respond, it’s immediately excluded from consideration. Yet of the roughly 800 hotels in Berlin, only one at most will actually be booked. In other words, for every 800 “looks,” there’s at most just one “book.”
The hospitality industry has struggled with the ratio between search queries and confirmed reservations; it is referred to as the “look-to-book” problem. While MCP introduces a standardized way to expose real-time rates and availability, the underlying systems remain the same as those that power hotel websites and reservation platforms. These systems were built to handle direct booking traffic, not the high-volume exploratory queries that drive discovery. Historically, online travel agencies (OTAs) and other aggregators absorbed that load with specialized infrastructure optimized for scale.
MCP doesn’t remove this challenge and without aggregation layers, hotels will face issues from high-volume exploratory queries.
Exploratory Overhead: A single traveler asking a broad question through AI could trigger queries to hundreds or thousands of MCP servers, all pulling data from fragile backend systems.
Low Intent Volume: Because the overwhelming set of these requests are exploratory they won’t lead to bookings.
Underlying System Constraints: Hotel Property Management Systems (PMS) and Central Reservation Systems (CRS) are designed for human interactions and completing confirmed bookings, not serving hundreds of speculative queries per second.
Wasted Load: Most of this information will never even reach the user, since many results are filtered or abandoned mid-conversation. Yet, each query still places load on the hotel’s infrastructure, which translates into cost.
Here’s one way to visualize the challenge using an idealized booking funnel: each circle in this diagram represents a traveler interested in a trip to Hawaii. At each step, they need accurate pricing information, even when they’re just exploring and have relatively low intent. Each of those circles represents a query from the traveler that needs to be satisfied. If it isn't, the hotel can’t make it to the next stage.
How Google, Booking, and Expedia Handle This Problem
Today’s largest travel platforms, such as Google Travel, Booking.com, and Expedia, do not query hotel systems live for every consumer search. Instead, the industry standardized on feeds: structured, machine-readable files delivered at high frequency to aggregators and OTAs and aggressively cached. Feeds dramatically reduce load on hotel systems, ensure freshness of data, and enable consistent traveler experiences.
Comprehensive inventory: Users want to see all hotels and OTAs provide that, or at least enough inventory that they are perceived to be complete.
Structured Data: Hotels and chains provide structured availability, rates, and inventory (ARI) feeds to these platforms.
Frequent Updates: Feeds are updated on a cadence ranging from minutes to hours, ensuring accuracy while avoiding constant load.
Massive Caches: Aggregators maintain large-scale, optimized caches of ARI data so they can respond instantly to consumer queries.
Real-time Queries: In situations where the cache is stale, some systems make “live” requests to show more accurate information.
This hybrid model ensures speed, accuracy, and scalability. Attempting to replicate the same functionality using live MCP requests or live crawling would dramatically increase the load on hotel systems, frequently querying for data that is never even shown to the end user.
Where OTAs Shine
With the tools described above, OTAs are able to provide great data to users. However, there is another, more subtle reason that they are so effective: they’re helpful to users at multiple stages of travel research.
Very few travelers work their way monotonically down the sales funnel. During their research and planning for a single trip they consider alternative rooms, hotels, cities, vacation types, sometimes even entirely new countries. This lateral exploration is difficult for any individual hotel, or even a global chain, to address. The breadth of inventory offered on OTAs allows travelers to explore in many directions, all of which lead to a possible transaction.
How OTAs Fall Short
To provide a great user experience, Foundational AI companies need access to structured, cached, real-time data to complete booking transactions. This explains why they have already started forging partnerships with Online Travel Agencies (OTAs) like Booking.com and Expedia. These OTAs are obvious initial partners as they have huge inventories and are technically savvy.
However, in addition to charging suppliers significant distribution commissions, OTAs fall short in a number of ways for suppliers, AI companies, and ultimately users:
They don’t have comprehensive inventory or prices
OTAs will require that any booking that comes from their data is purchased through them and OTAs will only show hotels, rooms, and rates that they receive commission on. This means that relying solely on OTA inventory will deprive the traveler of seeing if a better hotel, cheaper rate, or better room type is available through the direct channel. In fact, a common practice when a hotel is almost sold out, is to turn off their OTA channel. But rooms may still be available If you call, visit the website, or otherwise connect directly,
Bypassing the OTAs by using MCP maximizes the available hotels, rooms, and offers inventory to everyone using the AI engine.
OTAs bookings don’t provide or utilize loyalty points
An OTA will show a chain’s inventory, but they generally aren’t allowed to show member rates, or provide a mechanism to see or spend a traveler’s loyalty balance. Chains have no incentive to give that data away. MCP bridges the gap, allowing Foundational AI companies to deliver traveler-specific recommendations that are not only accurate, but personalized to the loyalty accounts.
OTAs have their own loyalty programs, but they are limited to price discounts. They leave other rich, customized, and interesting offers on the floor.
OTAs aren’t at the hotel and don’t have access to on-the-ground information
OTAs have done a phenomenal job at building a rich corpus of information about hotels. But they will always fall short compared to the hotel itself. As an example, consider the Ambassade Hotel in Amsterdam on Booking.com versus its own website. The latter covers its extensive art collection, its library of books written by its guests, its private tours of Amsterdam, the wellness spa next door, and its lecture and conversation series. This rich content is what can be accessed through an MCP integration directly in the Foundational AI. We talk about this in detail in our prior paper.
OTAs don’t connect to the hotel’s other facilities
While many OTAs are aware of the facilities available at a hotel – like a spa or an associated golf course – they only flatten that information into a list of amenities. What OTAs are unable to do is to enable a traveler to research that amenity, ask questions, and even get a reservation. All of these explorations require the traveler to contact the hotel directly, which OTAs seek to make difficult prior to the booking.
OTAs can surface a limited set of personalized offers
It would be incorrect to say that OTAs cannot create personalized offers. However, they have extremely limited breadth and are constrained by their understanding of what the hotel has to offer. To date, these personalizations have only been about bundling flights or rental cars with a hotel booking.
OTAs don’t let users book directly with the hotel
Most consumers want to book directly (1, 2, 3, 4, 5) with the hotel. They want this to gain access to loyalty points, the lowest rates, the best service, and – most importantly – peace of mind. This is at odds with the business model of OTAs.
Even though the ecosystem still needs aggregators in an AI-driven world, OTAs aren’t the right solution. Their high commissions, limited inventory, and lack of access to loyalty benefits or richer hotel content make them misaligned with both traveler and supplier interests.
The Case for Supplier-Aligned Aggregator MCP Servers
An alternative to OTAs is a supplier-aligned aggregator which works alongside hotels. Like OTAs, a supplier-aligned aggregator needs to cache data efficiently, normalize feeds, and respond to huge scale. In addition, it needs to qualify leads to prevent overwhelming reservation systems. Working with a supplier-aligned aggregator ensures travelers get fast, accurate, and loyalty-integrated results, while simultaneously allowing hotels to retain control of their inventory and guest relationship.
Caching and Feeds: Aggregator MCP servers ingest hotel feeds (availability, rates, and inventory, including member rates) into large, optimized caches, drastically reducing query load on hotels and reducing the look-to-book ratio.
Data Normalization: Data formats differ across hotels and chains; aggregators standardize schemas for seamless AI consumption.
Discovery & Routing: Aggregator MCP servers can route questions it can’t answer, or tools it doesn’t have, to the hotel’s own, specialized, MCP servers. OTAs are not incentivized to do this; they’re concerned about the traveler booking directly if there’s any communication directly with the hotel.
Comprehensive sourcing: Aggregator MCP servers can validate and source information broadly – suppliers public info, suppliers private data, review sites, and across the open web.
Comprehensive Inventory: An Aggregator MCP can provide a comprehensive set of hotels and offers – including specialized member pricing – for travelers to allow users to consider alternative offers, hotels, cities, even entirely different vacations.
Streamlined AI Performance: Foundational AI companies will choose a small number of comprehensive servers rather than making hundreds or thousands of requests to individual servers.
A more realistic – and chaotic – version of the booking process is shown below. Travelers jump into the funnel at various points. They go back into exploration mode when they hit dead ends. The hotel they book may not be one they even considered early in the process.
Supplier-aligned aggregator MCPs provide the connective tissue between fragmented hotel supply and traveler-facing AI systems on behalf of hotels. And they simultaneously support well known traveler research and booking behaviors.
And there’s another key benefit: MCP aggregators focus on helping suppliers scale and have no interest in interfering with the valuable, direct customer relationship that suppliers want and which OTAs undermine. What this also means is that supplier-aligned aggregators don’t need to provide services that are duplicative to those provided by hotels including customer service, facilitating payments, and handling personally identifiable information. Hotels already do an excellent job providing these services and have robust infrastructure and specialized tools to best serve their guests. This specialization allows supplier-aligned aggregators to be much, much cheaper than legacy OTAs.
Powering All Stages of Travel Research
As discussed in earlier, most travelers don’t go through a linear process. Instead, they skip back and forth between exploration, research, and often retreat on the verge of a transaction. OTAs have been attempting to support this non-linear user behavior for years. They fall short because they lack key information that users find valuable: member rates and concerns that only suppliers can answer.
Supplier-aligned Aggregator MCPs allow travelers to smoothly transition between top-of-funnel discovery, deeper research on specific properties with help from supplier information, and through to booking.
Exploratory Phase: When a traveler asks broad questions, aggregator MCPs handle queries at scale without overloading hotel infrastructure.
Research Phase: As intent sharpens, aggregator MCPs allow users to move seamlessly by connecting to brand-specific MCP servers to help with deep research about a specific hotel, back “up the funnel” to consider alternatives.
Transactional Phase: For booking, aggregator MCPs connect directly to hotel MCPs for personalized, loyalty-integrated offers.
Ecosystem Balance: Hotels avoid overload, travelers get comprehensive and accurate results, and foundational AIs minimize integration overhead.
Conclusion
Model Context Protocol enables real-time, standardized connections between hotels and AIs. But without aggregation, the system collapses under fragmented supply, redundant integrations, and unmanageable load.
DirectBooker was founded to connect travelers who want to book directly with hotels eager to delight them. Even with the changes enabled by AI, doing so requires an aggregator. The structure of the travel ecosystem makes it impossible for AI systems to query every hotel directly. A single exploratory question could trigger thousands of calls to fragile backend PMS and CRS systems. These systems were designed for confirming bookings, not speculative queries. Most of these queries won’t result in a reservation, yet they would still generate significant load and costs for hotels. By acting as a supplier-aligned, AI-native aggregator, DirectBooker absorbs this load and complexity, consolidating data efficiently so travelers get fast, accurate answers without overwhelming hotel infrastructure.
With all three major AI players supporting MCP, DirectBooker can build feeds, cache ARI data, and serve content at massive scale in formats AI systems can ingest seamlessly. Our deep experience in integrating data across hotel chains and technology partners positions us to provide the most complete inventory, from loyalty rates to room configurations and special offers. By aligning directly with hotels rather than competing with them, we reduce overhead, protect system stability, and deliver the most accurate and comprehensive availability to travelers at a dramatically lower cost. DirectBooker will be the default endpoint for AI travel search, making direct booking practical, sustainable, and transformative.
The window of opportunity is closing. Recent announcements have made clear that hotels need to move quickly to get in front of potential customers seeking accommodation information via a new set of tools, before the default behavior is to book with AI on dominant OTAs like Expedia and Booking.com.
Richard Holden, Steve Kaufer, Sanjay Vakil
Steve, Richard and Sanjay have combined over 50 years experience in the online travel, hotel search and travel planning as leaders from Tripadvisor, Google Travel and now, DirectBooker.
Our editorial process: DirectBooker curates insights from global hospitality experts and our network of industry insiders. Articles undergo rigorous fact-checking and quality review before publication, ensuring authentic, actionable advice for savvy travelers.
Featured articles
Read the other articles in our series.
