The Missing Layer in AI-Mediated Hotel Distribution

Hotels are deploying Model Context Protocol (MCP) servers.  OTAs are building agent-ready platforms.  GDS providers are launching MCP servers alongside enhanced API capabilities. OpenAI has launched their own Travel App integrations (OTAs, Reviews, etc). Everyone is racing to be 'AI-ready.'

They are all building engines for roads that do not exist yet.

When I started examining MCP's implications for travel distribution, I expected to write about technology disruption and competitive repositioning.  What emerged instead was a more fundamental question about how AI agents actually discover and book accommodation.

AI agents are not browsing hotel lists; they query with precise requirements.  A human opens Booking.com and browses say 25 properties, comparing prices and reading reviews.  An agent receives different instructions, "boutique hotels in Barcelona's Gothic Quarter, quiet rooms with workspace, under €200, March 15-18."  The agent must discover which hotels match these criteria, verify which sources are reliable and compare across fragmented vocabularies - all programmatically, without human browsing.

This shifts the infrastructure challenge from curation for human browsing to discovery for programmatic querying.  MCP provides the protocol for agent-to-agent communication. However, in a permanently fragmented marketplace of millions of accommodation properties using diverse systems, protocol alone is not enough.

The assumption underpinning this analysis is that MCP becomes a widely adopted protocol enabling direct agent-to-property communication. While this outcome is not guaranteed, the momentum is clear. Hotels, PMS providers and distribution systems are implementing MCP servers and AI platforms are building agent capabilities. The coordination challenge explored here emerges if (and as) this adoption scales.

The question becomes who builds the coordination infrastructure that makes AI-mediated booking actually work?

The answer is not found in the MCP servers being deployed.  It is in the missing layer that few are discussing.

The Industry Response

The industry is responding to AI agents through two clearly observable adaptations.

First, direct MCP deployment. Hotels, independent properties, chains and their PMS providers are implementing MCP servers to enable agent access. The Agent Engine Optimisation (AEO) conversation is emerging - how to structure data, expose capabilities and position properties so AI agents discover and prefer them.

The technical implementation is straightforward. MCP provides standardised protocol. Properties can expose availability, rates and inventory through consistent interfaces. Cloud-native PMS platforms are building this as core functionality.

Second, OTA positioning. The direct-access model creates genuine disintermediation pressure on established intermediaries. OTAs and other consumer-facing intermediaries are responding: investing heavily in AI-ready infrastructure and securing partnerships with LLM providers. Rather than waiting to be discovered by external agents, they are embedding booking capabilities directly into ChatGPT, Claude, Gemini and Perplexity workflows - securing their relevance before external agents can bypass them entirely.

Both adaptations are rational responses to AI-mediated distribution. Both are visibly underway with announced products and implementations.

Direct public, globally accessible MCP deployment cannot scale without open coordination infrastructure. OTA partnerships already provide proprietary coordination. The gap, and the opportunity, lies in what emerges between these two models.

Why Agent-Mediated Booking Changes Everything

Traditional booking flows are human-driven. A traveller opens Booking.com, browses hotels, compares prices, reads reviews and makes a decision. The infrastructure, OTA platforms, search algorithms and APIs for hotel availability, rates, inventory (ARI) and booking, optimises for this human browsing pattern. Platforms curate options, rank by relevance and present information for human consumption.

AI agents operate differently. When an agent books accommodation on behalf of a user, it does not browse, it queries with specific requirements. The agent receives instructions and needs to:

• Discover which hotels match criteria across fragmented inventory sources

• Verify which sources consistently deliver accurate availability

• Compare across different vocabularies ("Corner Suite, Double-Glazed, Desk" vs "Executive Studio, Soundproof, Work Area")

This shifts infrastructure requirements in three ways.

• Traffic patterns. Unlike human browsing sessions that create burst traffic during evening hours, agents operate continuously - querying, monitoring and verifying across 24/7 cycles.

• Data architecture. Travellers maintain preferences in their personal agents rather than platforms accumulating behavioural data across browsing sessions. Agents query with requirements, not identity, until booking confirmation.

• Value delivery. The value proposition is not about switching from existing APIs, those continue serving human-mediated booking flows effectively. MCP enables AI agents to discover properties through semantic understanding and intent interpretation, capabilities traditional APIs were not designed to provide.

  
  

Agents' ability to discover across fragmented inventory sources requires something new.

The Missing Coordination Layer

An agent searching for "boutique hotels in Barcelona's Gothic Quarter" faces a discovery problem that MCP servers do not solve on their own.

Consider 50 independent boutique properties in that area have deployed MCP servers or available through MCP servers in the distribution chain.  Each server runs on different infrastructure - some via cloud PMS providers, others through channel managers, a few managed directly by hotels and others by a wholesaler.  Each uses different terminology for room types ("Superior Double" vs "Deluxe Queen" vs "Premium Room").  Each structures their data slightly differently within MCP's framework.

How does the agent find these MCP endpoints?  There is no registry.  No routing table.  No canonical mapping of "Barcelona Gothic Quarter boutique hotels" to the MCP server’s URLs. How does the agent understand their responses?  One property calls a top-tier room "Premium Suite."  Another uses "Executive Room."  A third lists "Superior King." Same room category, completely different vocabularies.

How does the agent verify reliability?  Which servers consistently deliver accurate availability?  Which have proven booking confirmation rates?  Which handle modifications smoothly versus creating operational nightmares?

These questions reveal the coordination infrastructure gap. OTA + LLM partnerships provide proprietary coordination - consumer AI agents query OTAs, OTAs expose their aggregated inventory.  The gap exists for direct discovery, enabling agents to find and query independent MCP endpoints without OTA intermediation.

Where Coordination Sits and The Five-Layer Architecture

Understanding where coordination fits helps clarify what's missing and why different solution paths address the gap differently.

Layer 1: Source Data, Pricing and Booking Mechanisms All existing deterministic travel APIs and datasets - PMS feeds, direct hotel inventory, GDS platforms, wholesalers, bedbanks, OTAs, channel managers. This is the established source of availability, rate and inventory data and the methods for securing bookings.

Layer 2: MCP Execution Interface The actual MCP servers deployed by all major players (hotels, chains, OTAs, wholesalers, etc). This technical wrapper exposes Layer 1's deterministic data through AI-native protocol.

Layer 3: Commercial Coordination Services (THE GAP) The missing coordination infrastructure where agents bring requirements and receive ranked recommendations of which MCP servers to query.

Agent requests are processed as follows:

• Semantic understanding: Translates the agent's request to a query it uses against metadata stored in the registry

• Metadata matching: Discovers which MCP servers represent matching properties - including individual hotel endpoints, wholesaler platforms aggregating multiple properties and OTA aggregation services

• Trust ranking: Orders results by reliability - proven servers first, newer registrations flagged as building reputation

Layer 3 response: Here are 12 matching MCP servers - including individual properties and wholesalers aggregating matching inventory, ranked by trust and coverage. Leading options have proven reliability. Newer registrations flagged as building reputation.

Without this coordination layer, each agent independently builds registry, semantic understanding and reputation tracking - impractical at scale.

This enables agents to query coordination once, receiving ranked MCP server recommendations before querying those servers directly for building their own responses and interactions on behalf of their traveller or the agent's calling system.

Layer 4: Aggregation & Intelligence OTAs, GDS providers and major wholesalers who maintain proprietary business logic. They differentiate by adding curation, content richness, loyalty programs and business rules on top of discovered inventory.

Layer 5: Fiduciary Advocacy & Agent Execution Where actual agent execution occurs and fiduciary advocacy happens - corporate booking tools, consumer AI assistants, specialised travel agents, agentic AI startups, generic LLM platforms (ChatGPT, Claude, Gemini, Perplexity) and OTAs operating through various models (direct, integrated into agent platforms or deploying their own agents). Agents may use Layer 4 for end-to-end booking or use Layer 3 directly for discovery and trust signals before querying Layer 2 MCP servers.

The architecture clarifies dependencies: Layer 4 and Layer 5 both depend on Layer 3 functioning before they can deliver their distinct value. However, Layer 3 remains the critical gap. Understanding the gap is one thing. Understanding what is at stake in how we fill it is another.

Multiple Possible Solutions (And Their Uncertainties)

In my past experiences, I have learned that architectural decisions create ripple effects far beyond their immediate scope. When organisations build infrastructure that everyone depends on they solve more than technical problems; they shape how entire ecosystems can evolve.

Two distinct coordination models could emerge, each with different implications for market structure.

Open Coordination: Properties accessible to any qualified agent through shared coordination infrastructure, driving competition on service quality and value.

Proprietary Coordination: Properties accessible primarily through Layer 4 coordination services, where coordination becomes a new control layer and revenue stream.

Both models will likely coexist, serving different market segments and use cases - just as direct booking and intermediary distribution coexist today.  The strategic question is not which model wins, but how market share distributes between them and what this means for competitive positioning.

Multiple paths could lead to either outcome. The following solution paths represent different approaches to building coordination infrastructure, each with distinct economics and strategic implications.

Each path addresses the coordination differently

Solution Path 1: Commercial B2B Provider Extension

Entity resolution services currently maintain canonical hotel identifiers across fragmented systems.  They map how Property X's code in a PMS corresponds to its IDs across Booking.com, Expedia, GDS platforms, wholesalers and dozens of other systems.  This is proven, profitable business.

The extension logic appears natural: The canonical hotel identifier now includes the property's MCP server URL.  When an agent queries "which MCP servers represent boutique hotels in Barcelona's Gothic Quarter?" the answer comes from the same commercial service that today answers "which industry standard codes represent these properties?"

Semantic mapping services already translate room types and amenity descriptions across platforms.  They maintain ontologies understanding that "Sea View Deluxe Suite" from one property equals "Ocean Facing Premium Room" from another.

However, pivoting from bilateral services to registry infrastructure requires different economics:

• Current revenue: licenses or subscription fees from platforms, API access based on query volumes

• Required pivot: registry inclusion fees, discovery API access, semantic enrichment services

• Uncertainty: Is this high-margin opportunity or low-margin utility service?

The companies have proven relationships and domain expertise.  Whether incentives align for this business model evolution remains unproven.

Solution Path 2: Proprietary Coordination Control

OTAs, GDS providers and major wholesalers could build proprietary coordination as a competitive moat.  They already maintain vast connected inventory and aggregation relationships, plus the technology infrastructure and capital reserves to extend into coordination services without prohibitive investment.

The strategic logic: Do not let coordination become shared infrastructure.  Build discovery, reputation systems and semantic intelligence as proprietary advantages that agents must access through your services.

The business model: Properties seeking agent discovery through this coordination layer would subscribe to participate or pay additional fees beyond standard commission structures - creating a new revenue stream from coordination access.

The tension: Properties deploy MCP to enable direct agent access, bypassing Layer 4 aggregation.  OTAs and other Layer 4 parties respond by building new intermediation at the coordination layer (Layer 3).  This reproduces the dependency structure that MCP was meant to disrupt, just at a different architectural level.

The economic question: Does controlling coordination create sustainable competitive advantage, or does it simply delay the inevitable shift toward more open discovery?

Solution Path 3: AI-Native Registry Startups

New entrants could build coordination infrastructure specifically for agentic workflows, unburdened by legacy system constraints or existing business model conflicts.

The opportunity: Optimise for the actual usage patterns of AI agents rather than retrofitting existing infrastructure.  Move fast without internal political resistance or technical debt.

The classic cold start problem: Need both supply (properties registering MCP endpoints) and demand (agents querying the registry) simultaneously.  Network effects favour first movers, but first movers need significant capital to reach critical mass before revenue materialises.

The strategic bet: Can a startup achieve critical mass before incumbents pivot or platforms consolidate?  History suggests infrastructure plays typically require either patient capital or rapid network effect acceleration.

Solution Path 4: Consortium/Standards Body

Industry collaboration could establish shared registry infrastructure, preventing monopoly and ensuring interoperability.

The theoretical appeal: No single player controls discovery.  Open standards enable competitive innovation at other layers while maintaining shared coordination infrastructure.

The practical reality: Travel industry's track record on standardisation is not encouraging.  Coordination problems solving coordination problems.  Competitive tensions blocking collective action.  Slow consensus processes unable to match market speed.

The open question: Could regulatory pressure or customer demand force collaboration that market dynamics alone wouldn't produce?

The Unresolved Questions

These solution paths exist in theory. What determines which path, or paths, actually emerge depends on questions that remain genuinely unresolved.

Trust Infrastructure Economics

Reputation systems, certification validation, fraud detection - these are expensive to build and maintain.  Every reputation system gets gamed. What prevents this from becoming another TripAdvisor manipulation problem at scale?

Who funds comprehensive trust infrastructure and how?  Registry inclusion fees might cover basic operations, but sophisticated fraud detection and reputation validation require ongoing investment. Whether this becomes profitable service or loss-leader infrastructure affects solution viability.

Registry Competition Dynamics

If multiple registries emerge, how do agents choose which to query? Do they query all of them, fragmenting the ecosystem?  Does network effect drive winner-takes-most consolidation?

Or does specialisation emerge? Registries might focus on specific domains - regional nodes (European properties, APAC inventory), property types (luxury chains, independent boutiques) or distribution models (direct properties, wholesaler aggregations).  This federated model could deliver better data quality through focused expertise, but may require some agents to query multiple specialised registries for comprehensive coverage.

Coordination layers typically benefit from network effects favouring consolidation, but competitive markets require multiple options. Specialisation offers a middle path but introduces new complexity around federation, cross-referencing and meta-registry coordination.

The Build vs Integrate Calculus

When does it make economic sense for platforms to integrate with coordination services versus building proprietary alternatives?  The decision depends on:

• Cost of building versus cost of integrating

• Strategic value of controlling coordination

• Speed requirements (build takes longer, integrate moves faster)

• Risk tolerance (proprietary = more control, shared = less exposure)

These calculations vary dramatically by organisation size, technical capability and strategic positioning.  No universal answer exists, only context-specific trade-offs.

The Honest Assessment

The coordination gap is real and immediate. MCP deployment is happening faster than discovery infrastructure, creating a temporary state of technical readiness without practical usability at scale.

However, MCP's value does not solely depend on external coordination.  The same protocol deployed for agent discovery can coordinate internal systems - automating work that currently requires manual integration across PMS platforms, channel managers and internal tools.  This internal automation delivers immediate operational ROI, justifying MCP investment even while external coordination architecture remains ambiguous.

What is clear is someone will build this coordination layer; the technical necessity is undeniable.

The two visible market adaptations - direct MCP deployment and OTA positioning - are rational responses to AI-mediated distribution. Both are underway with active implementations.

How coordination infrastructure develops will shape the evolution of travel distribution.

For executive leadership, the four solution paths described here represent plausible approaches. Some may already be underway quietly, others remain theoretical.  The question is not which path is "correct" but which path aligns with your organisation's capabilities, competitive position and tolerance for coordination dependencies.

Who builds the coordination layer, and on what terms, will determine market structure for the coming decade.