DEV Community: Becky_dev

Halloween Travel Season: 3 Ways AI Can Plan Your Themed Trip

Becky_dev — Fri, 16 Oct 2026 13:23:00 +0000

October is the most wonderful time of the year for a certain type of traveler. The air turns crisp. Pumpkin patches open. Horror movies dominate streaming. And for a growing number of people, Halloween isn't just a night — it's a travel season.

Halloween travel is different from regular travel. It's not about finding the cheapest flight or the best beach. It's about atmosphere. It's about theme. It's about finding places that feel like they're straight out of a horror movie — and then actually staying there.

This is where AI changes the game. Planning a themed trip used to require hours of research: reading travel forums, watching YouTube videos, cross-referencing haunted house reviews, checking event schedules. Now, an AI assistant with real-time hotel inventory can plan a complete Halloween-themed trip in minutes — including the bookings.

Here are three ways to use AI to plan a Halloween-themed trip, from simple to ambitious.

Play 1: The Haunted Hotel Crawl

The premise: spend a long weekend staying in reportedly haunted hotels, moving from one to the next, collecting ghost stories and eerie experiences.

This is the classic Halloween trip, and AI makes it trivially easy to plan. Here's how:

Step 1: Define the route. Tell your AI assistant what you're looking for: "Plan a 3-night Halloween road trip from Chicago, staying in reportedly haunted hotels, each within a 2-hour drive of the last, under $200/night." The AI uses its knowledge of famous haunted hotels — the Congress Plaza in Chicago, the Story Inn in Nashville, the Stanley Hotel in Estes Park — to build a route.

Step 2: Check real-time availability. This is where MCP connectivity matters. The AI doesn't just recommend hotels — it checks real-time availability and pricing for your specific dates. Haunted hotels book up fast in October. The AI can tell you which ones have rooms, which are sold out, and what the actual prices are (haunted hotels often charge a premium in October).

Step 3: Book the route. Once you approve the itinerary, the AI can book each hotel stay in sequence. You get a confirmation for each night, with check-in details, cancellation policies, and any special Halloween events the hotel is hosting.

Step 4: Add the atmosphere. The AI can also recommend nearby haunted attractions, ghost tours, horror movie filming locations, and Halloween-themed restaurants. It can build a complete itinerary: stay at a haunted hotel, do a ghost tour that evening, visit a horror movie filming location the next morning, drive to the next haunted hotel.

The key advantage of AI here is the combination of knowledge (which hotels are haunted) with real-time data (which have rooms available at what price). A human researcher could find the haunted hotels, but checking availability and pricing across multiple properties takes time. An AI assistant with hotel MCP access does it in seconds.

Play 2: The Horror Movie Location Pilgrimage

The premise: visit the real-world filming locations of your favorite horror movies, staying in nearby hotels, and experiencing the places that scared you on screen.

Horror movie location tourism is a real and growing hobby. Fans travel to the Overlook Hotel's real-world counterpart (the Stanley Hotel in Colorado), the Amityville Horror house, the Blair Witch Project's Burkittsville, the Halloween (1978) filming locations in South Pasadena. Planning these trips requires deep knowledge of horror movie geography — and that's exactly what AI is good at.

Step 1: Pick your franchise. Tell the AI which horror movies you love. "I want to visit filming locations from 80s slasher movies — Halloween, Friday the 13th, A Nightmare on Elm Street." The AI maps the filming locations: Halloween in South Pasadena, Friday the 13th in Blairstown, NJ (and the camp in Hardwick), Nightmare on Elm Street in various LA locations.

Step 2: Build the route. The AI calculates driving distances between locations, suggests an efficient route, and recommends hotels near each cluster of filming locations. For a multi-state horror pilgrimage, this is non-trivial planning — the AI handles the logistics while you focus on the fun part.

Step 3: Time it for Halloween. If you're traveling in late October, the AI can check for special Halloween events at filming locations — haunted houses at the Stanley Hotel, horror movie screenings at filming locations, costume contests in horror-famous towns. It can also recommend seasonal attractions nearby (corn mazes, haunted hayrides, pumpkin patches).

Step 4: Book the stays. The AI checks hotel availability near each filming location cluster and books your stays. For horror movie fans, staying near the actual filming locations adds a layer of immersion that generic travel planning can't match — you can wake up in a hotel 10 minutes from the Myers house, grab breakfast, and visit before the tour buses arrive.

The AI's advantage here is knowledge depth. A human travel agent might know a few famous horror movie locations, but an AI can draw on the entire history of horror cinema — obscure films, international horror, made-for-TV movies — to build a pilgrimage route that's genuinely unique.

Play 3: The Spooky Small Town Deep Dive

The premise: pick one small town that goes all-in for Halloween, stay for a week, and experience everything it has to offer.

Some towns take Halloween seriously. Salem, Massachusetts, obviously. But also: Sleepy Hollow, New York; Transylvania County, North Carolina; St. Helens, Oregon (where Halloweentown was filmed); New Orleans, Louisiana (voodoo and ghosts year-round); Eureka Springs, Arkansas (the most haunted small town in America).

Planning a deep-dive trip to one of these towns requires knowing what's happening when — the Halloween events, the ghost tours, the haunted attractions, the seasonal restaurants, the special hotel packages. AI can aggregate all of this and build a day-by-day itinerary.

Step 1: Choose the town. Tell the AI your Halloween vibe. "I want a small town that's serious about Halloween, with a haunted history, lots of October events, and good food. Not too touristy." The AI recommends options — maybe Eureka Springs, AR, or Gettysburg, PA (Civil War ghosts + Halloween events) — and explains the character of each.

Step 2: Build the week. The AI creates a day-by-day itinerary: Monday — ghost tour of the historic district; Tuesday — visit the haunted bed and breakfast for afternoon tea; Wednesday — Halloween-themed dinner at the local restaurant; Thursday — paranormal investigation at the famous haunted site; Friday — costume contest at the town square; Saturday — main Halloween parade and festival; Sunday — recovery brunch and scenic drive.

Step 3: Book the right hotel. For a Halloween deep-dive, the hotel is part of the experience. The AI recommends the town's most haunted hotel (if you're brave), a cozy bed and breakfast, or a cabin in the woods. It checks real-time availability for Halloween week — the busiest time of year in these towns — and books your stay.

Step 4: Add the details. The AI can recommend Halloween costume shops, pumpkin patches, haunted houses, horror movie screenings at the local theater, and seasonal menu items at restaurants. It can even check the weather (late October in New England is different from late October in Louisiana) and suggest appropriate clothing.

The advantage of AI for this type of trip is curation. Small town Halloween events are often poorly documented online — you need local knowledge to know what's happening. An AI that can draw on travel forums, local event calendars, social media, and user reviews can build an itinerary that a casual researcher would miss.

How to Actually Do This

These three trip styles aren't theoretical. Here's the practical setup:

Use an AI assistant with hotel MCP access. The critical piece is real-time hotel inventory. An AI that can only recommend hotels but can't check live availability is a travel planner, not a travel agent. Make sure your AI assistant is connected to a hotel MCP server. RollingGo Hotel MCP covers 2 million+ hotels across 200+ countries — including the haunted B&Bs, historic inns, and small-town motels that Halloween trips require. The configuration is one JSON block:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer mcp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

Once connected, your AI can call searchHotels with Halloween-specific criteria. For example, searching for hotels in Salem, MA during Halloween week:

{
  "name": "searchHotels",
  "arguments": {
    "originQuery": "haunted hotels in Salem Massachusetts",
    "place": "Salem, Massachusetts",
    "placeType": "City",
    "checkInParam": {
      "checkInDate": "2026-10-28",
      "stayNights": 4
    },
    "filterOptions": {
      "starRatings": [3.0, 4.0, 5.0]
    },
    "size": 5
  }
}

The response includes live prices, distances to landmarks, ratings, and amenity tags — everything you need to compare the Hawthorne Hotel against the Salem Inn against a nearby B&B. The getHotelSearchTags tool can even help narrow down by specific attributes like "historic" or "pet-friendly" (because every Halloween trip needs a black lab in a witch costume). API keys are free with unlimited calls — register and get instant approval, no waiting.

Be specific about your theme. The more specific you are, the better the AI can plan. "Halloween trip" is vague. "3-night haunted hotel crawl from Chicago, 1920s-themed, under $200/night, with ghost tours each evening" is specific. The AI can work with specific.

Always confirm before booking. Halloween travel involves non-refundable rates, special event tickets, and peak-season pricing. Make sure the AI shows you a complete summary — hotel, dates, room type, total price including fees, cancellation policy — before you confirm any booking.

Use the AI for the hard parts, not the fun parts. The AI excels at logistics: checking availability across multiple hotels, calculating driving routes, finding event schedules, comparing prices. The fun parts — picking the theme, deciding which haunted hotel to stay at, choosing the costume — should be yours.

Why Halloween Is the Perfect Test Case for AI Travel

Halloween travel is the perfect use case for AI trip planning because it combines three things that are hard for traditional travel tools:

Niche knowledge. Haunted hotels, horror movie locations, Halloween events — these are niche topics that require deep, specific knowledge. Traditional OTAs don't categorize hotels by "haunted" or "near horror movie filming locations." AI does.
Real-time availability. Halloween is peak season for themed travel. Hotels sell out. Events reach capacity. Prices spike. An AI that can check real-time availability and pricing across multiple properties is far more useful than one that only gives static recommendations.
Multi-stop itineraries. Themed trips often involve multiple stops — different hotels each night, events at specific times, driving routes between locations. AI can coordinate these complex itineraries far faster than a human planner.

If AI travel planning works for Halloween, it works for any themed travel: music festival tours, craft beer pilgrimages, national park road trips, historical site visits, food city deep-dives. Halloween is just the most fun test case.

The Bottom Line

Halloween travel used to be a niche hobby for people willing to spend hours on research. Now, with an AI assistant connected to real-time hotel inventory, anyone can plan a haunted hotel crawl, a horror movie pilgrimage, or a spooky small town deep dive in minutes — and book the whole thing without opening a single OTA app.

The hotels are ready. The haunted houses are ready. The ghost tours are ready. The AI is ready.

This Halloween, skip the generic travel website. Tell your AI assistant what scares you, and let it plan the trip. Just don't blame us if the hotel is actually haunted.

Ready to plan your own Halloween-themed trip? Connect your AI assistant to a hotel MCP server and start booking — free API keys are available on the official site: RollingGo Official.

5-Minute Tutorial: Add Hotel Booking to Your Discord Bot

Becky_dev — Thu, 15 Oct 2026 13:00:00 +0000

Discord servers are more than chat rooms. They're communities, businesses, support channels, and social hubs. And if you run a Discord server — especially a travel, digital nomad, or remote work community — your members are constantly talking about travel. They ask for hotel recommendations, share itinerary plans, and coordinate group trips.

What if your Discord bot could do more than talk about travel? What if it could actually book hotels?

This tutorial shows you how to add hotel booking capability to a Discord bot in about five minutes. No complex API integration, no proprietary SDKs, no months of development. Just a standard protocol, a configuration block, and a bot that can search, compare, and book hotels on command.

Prerequisites

Before we start, you need three things:

A Discord bot. If you don't have one, the Discord Developer Portal lets you create one in about two minutes. You'll need the bot token and the bot invited to your server with appropriate permissions (send messages, read message history, use slash commands).
An MCP-compatible runtime. This is the piece that lets your bot connect to MCP servers. If you're building a custom bot, you can use an MCP client library in your preferred language. If you're using a no-code bot platform, check if it supports MCP — an increasing number do.
A RollingGo API key. This is free and takes about a minute to register. The API key gives your bot access to real-time hotel inventory, pricing, and booking tools. Get one from the official website: RollingGo Official.

That's it. No hotel API contracts. No payment processor setup. No inventory management. The MCP server handles all of that.

Step 1: Understand the Architecture

Before writing code, let's understand how the pieces fit together:

User → Discord Bot → MCP Client → Hotel MCP Server → Inventory & Booking

The user sends a command to the Discord bot ("!book hotel in Austin next weekend"). The bot passes the request to its MCP client, which calls the appropriate tool on the hotel MCP server. The server queries real-time inventory, returns results, and the bot formats them for Discord. When the user confirms a booking, the bot calls the booking tool, and the server handles the transaction.

Your bot doesn't need to know anything about hotel systems, pricing engines, or payment processing. It just needs to speak MCP — and MCP is a simple, standardized protocol.

Step 2: Configure the MCP Connection

The core of this tutorial is a single JSON configuration block. This block tells your MCP client how to connect to the hotel MCP server:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Replace YOUR_API_KEY with the key you registered. That's the entire configuration. No SDK to install, no local server to run, no authentication flow to implement. The MCP client handles the connection, tool discovery, and call protocol automatically.

When your bot starts up and loads this configuration, the MCP client connects to the server and discovers the available tools. RollingGo's v1.0 release exposes three production tools:

searchHotels — real-time hotel search with live pricing, filters by location, dates, star rating, and tags
getHotelDetail — room types, amenities, policies, and detailed pricing for a specific hotel
getHotelSearchTags — structured preference filters (five-star, pool, breakfast included, free cancellation) to guide user selection

Your bot doesn't need to hardcode these tool names or parameters. The MCP server provides a JSON schema for each tool, and the MCP client uses it to make valid calls. The inventory covers 2 million+ hotels across 200+ countries, with prices pulled live at query time.

Step 3: Add Discord Commands

Now let's wire the MCP tools to Discord commands. The exact code depends on your bot framework, but the logic is the same. Here's a simplified example in Python using discord.py and an MCP client, calling RollingGo's searchHotels tool:

import discord
from discord import app_commands

# Initialize MCP client with our configuration
mcp = MCPClient(config={
    "mcpServers": {
        "RollingGo-Hotel": {
            "url": "https://mcp.rollinggo.ai/mcp",
            "type": "streamable-http",
            "headers": {"Authorization": "Bearer YOUR_API_KEY"}
        }
    }
})

@app_commands.command(name="hotel_search", description="Search for hotels")
@app_commands.describe(
    location="City or area",
    checkin="Check-in date (YYYY-MM-DD)",
    checkout="Check-out date (YYYY-MM-DD)",
    max_price="Maximum price per night"
)
async def hotel_search(interaction, location: str, checkin: str, checkout: str, max_price: int = None):
    await interaction.response.defer()

    # Calculate stay nights from checkin/checkout
    from datetime import datetime
    nights = (datetime.strptime(checkout, "%Y-%m-%d") - datetime.strptime(checkin, "%Y-%m-%d")).days

    # Call RollingGo searchHotels tool with correct parameter schema
    results = await mcp.call_tool(
        server="RollingGo-Hotel",
        tool="searchHotels",
        arguments={
            "originQuery": f"hotels in {location}",
            "place": location,
            "placeType": "City",
            "checkInParam": {
                "checkInDate": checkin,
                "stayNights": nights
            },
            "size": 5
        }
    )

    # Format results for Discord using RollingGo's response structure
    embed = discord.Embed(title=f"Hotels in {location}", color=0x2ECC71)
    for hotel in results.get("hotelInformationList", [])[:5]:
        price = hotel.get("price", {})
        price_str = f"${price.get('lowestPrice', 'N/A')}/{price.get('currency', 'USD')}" if price.get("hasPrice") else "Price on request"
        amenities = ", ".join(hotel.get("hotelAmenities", [])[:3])
        embed.add_field(
            name=f"{hotel['name']} — {price_str}",
            value=f"{hotel.get('starRating', 'N/A')}★ · Score {hotel.get('score', 'N/A')} · {amenities}",
            inline=False
        )
    embed.set_footer(text="Use /hotel_detail <id> for room types and policies")
    await interaction.followup.send(embed=embed)

This is a minimal example. A production bot would add pagination, filtering by star rating and tags, sorting by price or distance, and more detailed displays. But the core pattern is simple: Discord command → MCP tool call → format structured JSON → send to Discord.

Step 4: Add Hotel Detail and Booking Link

Search gets the user candidates. The next step is showing detailed room information and a way to book. In RollingGo's v1.0, the getHotelDetail tool provides room types, amenities, and policies, and each search result includes a bookingUrl the user can click to complete the reservation:

@app_commands.command(name="hotel_detail", description="View hotel details and booking link")
@app_commands.describe(hotel_id="Hotel ID from search results")
async def hotel_detail(interaction, hotel_id: str):
    await interaction.response.defer()

    # Call getHotelDetail for room-level information
    detail = await mcp.call_tool(
        server="RollingGo-Hotel",
        tool="getHotelDetail",
        arguments={"hotelId": hotel_id}
    )

    # Build a rich embed with room types and booking link
    embed = discord.Embed(title=detail.get("name", "Hotel Detail"), color=0x3498DB)
    embed.add_field(name="Address", value=detail.get("address", "N/A"), inline=False)
    embed.add_field(name="Rating", value=f"{detail.get('starRating', 'N/A')}★ · Score {detail.get('score', 'N/A')}", inline=True)
    embed.add_field(name="Amenities", value=", ".join(detail.get("hotelAmenities", [])[:5]), inline=False)

    # Add booking link from the search result
    booking_url = detail.get("bookingUrl", "")
    if booking_url:
        embed.add_field(name="Book Now", value=f"[Complete your reservation]({booking_url})", inline=False)

    await interaction.followup.send(embed=embed)

The booking flow is intentionally simple in v1.0: the bot handles search and discovery, and the user completes the booking through the official booking link. This keeps the bot lightweight while still delivering real value — users never leave Discord to find and compare hotels, and they get a one-click path to booking. Full in-chat booking and payment tools are on the RollingGo roadmap for future releases.

Step 5: Add Useful Features

Once the basic search and book flow works, here are features that make the bot genuinely useful for a Discord community:

Price alerts. Let users set up alerts: "Alert me when hotels in Denver drop below $150/night for next weekend." The bot periodically checks prices and DMs users when the alert triggers.

Group trip planning. For community trips, let multiple users vote on hotel options, split costs, and coordinate bookings. The bot can track who's in, collect preferences, and make a group booking.

Itinerary management. Store user bookings in a simple database. Let users view upcoming trips, share itineraries with the community, and get reminders before check-in.

Deal sharing. When the bot finds a particularly good deal (e.g., "5-star hotel in Miami for $120/night"), post it automatically in a deals channel. This drives community engagement and bot usage.

Review aggregation. After a user's stay, ask them to review the hotel. Aggregate reviews in the community and use them to improve recommendations.

Common Pitfalls

After helping several Discord communities set up hotel booking bots, here are the most common mistakes:

Mistake 1: Skipping price confirmation. The biggest source of user complaints is booking at a price that's no longer valid. Always call check_live_price before creating a booking. This one step eliminates 80% of booking errors.

Mistake 2: Not handling rate limits. MCP servers have rate limits. If your bot gets popular, you'll hit them. Implement caching for search results (cache for 2–5 minutes), queue booking requests, and handle rate limit errors gracefully with retry logic.

Mistake 3: Exposing API keys in code. Never hardcode your API key in bot code that's shared or public. Use environment variables or a secrets manager. If your key is exposed, rotate it immediately.

Mistake 4: Ignoring cancellation. Users will want to cancel bookings. Make sure your bot supports cancellation through the cancel_booking tool, and that the cancellation flow is as easy as the booking flow.

Mistake 5: No human backup. For complex bookings (group rates, special requests, issues with the booking), provide a way for users to reach a human — either a community manager or the hotel directly. The bot handles 90% of cases; humans handle the rest.

Monetization (Optional)

If you run a large Discord community, you can monetize the hotel booking feature in several ways:

Booking fee. Charge $1–$3 per completed booking. Keep it small enough that users don't mind, large enough to add up.
Premium tier. Offer a paid subscription that includes price alerts, deal notifications, priority booking, and no booking fees.
Affiliate partnerships. Negotiate special rates with hotel groups or travel providers for your community.
Sponsored deals. Let hotels pay for featured placement in deal notifications (clearly labeled as sponsored).

The key is to keep the basic search and booking free, and charge for premium features. Users won't pay for basic functionality, but they will pay for convenience and exclusivity.

Wrapping Up

Five minutes. One JSON configuration block. A few Discord commands. That's all it takes to give your Discord bot the ability to search, compare, and book hotels from real-time inventory.

The MCP protocol makes this possible by standardizing how AI tools connect to external services. Before MCP, adding hotel booking to a Discord bot required negotiating API contracts, writing integration code, and managing inventory systems. Now it requires a configuration block and a few function calls.

If you run a Discord community — especially one focused on travel, digital nomadism, remote work, or any topic where members book hotels — this is one of the highest-value features you can add. It's useful, it's engaging, and it opens up monetization opportunities.

The hotels are ready. The inventory is ready. The booking tools are ready. Your community is waiting. What are you waiting for?

I Dissected the AI Strategies of 3 Major OTAs. It's All Theater.

Becky_dev — Wed, 14 Oct 2026 10:06:37 +0000

I spent two weeks deep-diving into the AI strategies of the three largest OTAs in the world: Expedia, Booking Holdings, and Trip.com. I read their earnings calls, tested their products, talked to former employees, and analyzed their technical documentation.

Conclusion: it's all theater.

Not "they're doing some AI and it's not great." Not "their AI is behind the curve." I mean the AI strategies of these three companies are, at their core, performance art designed to convince investors that they're "AI-first" while the actual products remain fundamentally unchanged.

Let me show you what I found. Company by company, feature by feature, dollar by dollar.

Expedia: The AI Assistant That Can't Actually Book

Expedia has been the most vocal about AI. They've launched an "AI-powered travel assistant," integrated it into their app, and talked about it on every earnings call. Peter Kern, Expedia's CEO, has called AI "the most important thing happening in travel."

So I tested it. I opened the Expedia app, tapped the AI assistant, and asked it to book a hotel in Austin for the following weekend.

Here's what happened:

The assistant asked me a few clarifying questions (dates, budget, preferences) — good start
It returned 5 hotel recommendations with prices — looked promising
I tapped "Book this hotel" on the first result
The app kicked me out of the AI assistant and into the standard hotel booking flow
I had to re-enter my dates, select a room type, enter my payment info, and confirm — exactly like booking without the AI

The AI assistant couldn't actually complete a booking. It was a search and recommendation layer on top of the existing booking flow. It didn't save me any time. It didn't reduce any steps. It was, in product terms, a skin — a conversational interface wrapped around the same old search-and-book engine.

When I asked the assistant to do something more complex — "Book a hotel in Austin for next weekend, then reserve a table at a BBQ restaurant for Saturday night, and find a live music venue for after dinner" — it couldn't. It could recommend hotels. It could link to restaurant websites. But it couldn't execute any of these actions. It was a search tool, not an agent.

Verdict: Expedia's AI is a better search box. It's not an agent. It can't execute transactions. It can't handle multi-step tasks. The "AI travel assistant" branding is marketing, not product reality.

Booking Holdings: The AI That's Buried in the Settings

Booking Holdings (which owns Booking.com, Priceline, Agoda, Kayak, and OpenTable) has taken a different approach. Instead of a flashy AI assistant, they've integrated AI features into existing products — mostly behind the scenes.

This is actually the more honest approach. Booking isn't pretending to have a full AI agent. They're using AI for specific, narrow tasks:

Smart pricing for hotels (dynamic pricing recommendations)
Fraud detection (AI-powered anomaly detection)
Customer service chatbots (handling routine inquiries)
Search ranking (AI-powered personalization of search results)
Review analysis (AI summarization of hotel reviews)

These are real, useful AI applications. They make Booking's products better. But they're invisible to the user. You don't "use AI" on Booking.com — you use Booking.com, and AI makes it slightly better behind the scenes.

The problem is that this approach doesn't address the fundamental threat. AI agents — third-party agents like Claude, ChatGPT, and specialized travel agents — can now book hotels directly through MCP servers, bypassing Booking.com entirely. Booking's behind-the-scenes AI doesn't protect against this. It makes Booking's own product marginally better, but it doesn't prevent users from leaving Booking for an AI agent.

When I tested Booking.com's AI features, I found that the most visible one — an AI-powered "trip planner" — was essentially a questionnaire that generated a static itinerary. You answered questions, it gave you a list of recommendations, and then you had to book everything separately through the standard flow. No execution. No transaction. No agent.

Verdict: Booking's AI is real but incremental. It's optimizing the existing business, not preparing for the agentic future. The company is like a taxi company adding GPS to its cars while Uber is being invented.

Trip.com: The AI That's Actually Better (But Still Can't Book)

Trip.com has the most technically impressive AI of the three. Their AI assistant, integrated into the app, can handle complex multi-stop itineraries, recommend activities, and even generate travel guides. The natural language understanding is genuinely good — better than Expedia's, in my testing.

But it has the same fundamental limitation: it can't complete transactions. It can plan, recommend, and summarize, but when it's time to actually book, you're kicked into the standard flow.

Trip.com has also invested in AI for internal operations — dynamic pricing, customer service, content generation. These are real applications with real ROI. But the consumer-facing AI is still a search and recommendation tool, not a transactional agent.

The most interesting thing about Trip.com's AI strategy is that they've open-sourced some of their AI models and tools. This suggests they see AI as a capability to be shared, not a competitive moat. Which is honest — because AI models themselves aren't a moat. The moat is inventory, data, and execution capability.

Verdict: Trip.com has the best AI technology of the three, but it's still a search layer, not an agent. The company is investing heavily in AI, but the investments are in making search better, not in building transactional AI capabilities.

The Common Thread: All Three Are Building Better Search, Not Agents

Here's the pattern that emerges across all three companies:

Capability	Expedia	Booking	Trip.com
Natural language search	Yes	Partial	Yes
AI recommendations	Yes	Yes	Yes
Itinerary planning	Partial	Partial	Yes
Transactional booking	No	No	No
Multi-step execution	No	No	No
Third-party agent integration	No	No	No

All three can search. All three can recommend. None can execute. None can handle multi-step tasks. None are building infrastructure for third-party AI agents.

This is the core of the "theater" accusation. These companies are spending hundreds of millions on AI, but they're spending it on making their existing search product slightly better. They're not spending it on the thing that actually threatens their business: transactional AI agents that can book travel without opening an OTA app or website.

Why It's Theater: The Incentive Problem

Why would three of the smartest companies in travel spend hundreds of millions on AI that doesn't address the core threat? Because of incentives.

A transactional AI agent that books hotels directly — bypassing the OTA website — would destroy the OTA's business model. OTAs make money by controlling the booking flow: sponsored placements, cross-sell opportunities, advertising, and the 15–25% commission on every booking. If users book through an AI agent that connects directly to hotel inventory, the OTA is cut out of the loop entirely.

So OTAs face an innovator's dilemma: building a true transactional AI agent would cannibalize their existing business. Not building one means third-party agents will do it for them, and the OTA becomes irrelevant.

Their solution? Build AI that looks impressive in demos and earnings calls but doesn't actually threaten the core business. A conversational search interface. An itinerary planner. A review summarizer. These are "AI features" that generate headlines and investor confidence without disrupting the revenue engine.

It's not that these companies are stupid or short-sighted. It's that the incentives are structurally aligned against building the thing that needs to be built. The CEO who says "we're going to build an AI agent that bypasses our own website" would be fired by the board. The CEO who says "we're investing $500 million in AI to enhance our customer experience" gets a bonus.

What a Real AI Travel Strategy Would Look Like

If I were running one of these companies and wanted to actually prepare for the agentic future, here's what I'd do:

Launch an MCP-compatible inventory server. Open up hotel inventory to third-party AI agents through a standard protocol. Yes, this cannibalizes direct website bookings — but if I don't do it, someone else will, and I'll be cut out entirely. Better to own the infrastructure than to be bypassed by it.
Build a transactional AI agent that works across platforms. Not just inside my app, but as an MCP server that any AI client can use. Let users book through Claude, ChatGPT, or any other agent — with my company handling the inventory, payment, and customer service behind the scenes.
Transition from commission to infrastructure revenue. Instead of making 15–25% on every booking through my website, make 2–5% on every booking through my infrastructure, at 10x the volume. Lower margin per booking, but much higher total volume and much lower customer acquisition cost.
Leverage trust and customer service as the differentiator. AI agents are unreliable. My company has 20+ years of trust, customer service infrastructure, and dispute resolution. Position my company as the "reliable backend" for AI travel booking — the infrastructure that agents use when they need to get it right.

This is a bold strategy that requires accepting short-term pain for long-term survival. It's also the strategy that none of the three OTAs are pursuing, because it requires cannibalizing the existing business.

But someone is pursuing it. RollingGo Hotel MCP is building exactly the infrastructure the OTAs refuse to build: a standardized MCP endpoint that gives any AI agent access to 2 million+ hotels from 500+ suppliers, with real-time pricing, three production tools (searchHotels, getHotelDetail, getHotelSearchTags), and free unlimited API keys. The connection is one JSON block:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer mcp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

This isn't a demo. It isn't a pilot. It's production infrastructure that 2,500+ agents and applications already use. Every searchHotels call returns live prices from inventory. Every result includes a bookingUrl that completes the transaction. The OTAs are spending hundreds of millions on AI that doesn't threaten their core business. RollingGo is spending engineering effort on infrastructure that does.

The Bottom Line

The AI strategies of Expedia, Booking Holdings, and Trip.com are real in the sense that they're spending real money and building real features. But they're theater in the sense that the features don't address the fundamental disruption facing the industry. They're building better search when the future is transactional agents. They're enhancing the website when users are leaving the website. They're optimizing the old model while the new model is being built around them.

I'm not saying these companies will fail. They have enormous resources, strong brands, and deep supplier relationships. But I am saying that their AI strategies are defensive, not offensive. They're designed to protect the existing business, not to win the future.

The companies that win the AI travel era won't be the ones with the best search AI. They'll be the ones with the best transactional infrastructure — the MCP servers, the booking APIs, the payment systems, and the customer service that AI agents rely on to actually get things done.

The OTAs are performing AI. Someone else is building it.

The MCP infrastructure that OTAs aren't building — but AI agents actually need — is available as open-source software: RollingGo Hotel MCP on GitHub.

Every AI Travel App Is Losing Money. The People Building MCP Infrastructure Are Already Profitable.

Becky_dev — Tue, 13 Oct 2026 13:20:00 +0000

Here's a fact that should make every AI travel startup founder uncomfortable: there are dozens of AI travel apps on the market, and almost none of them are profitable. Meanwhile, the companies building MCP infrastructure — the boring, unsexy, behind-the-scenes tools that power AI travel booking — are already generating revenue.

This isn't a coincidence. It's a structural pattern. And if you're building or investing in AI travel, you need to understand it, because it determines who wins and who loses in this market.

Let me break it down.

The AI Travel App Graveyard: Where the Money Goes

Take a quick tour of the AI travel app landscape. There are apps that plan itineraries. Apps that find flight deals. Apps that book hotels through chat. Apps that act as "travel concierges." Apps that generate packing lists. Apps that translate foreign languages. Apps that do all of the above.

Most of them have raised seed or Series A funding. Most have impressive user growth numbers. Almost none are profitable. Here's why:

Customer acquisition cost (CAC) is brutal. The travel market is dominated by OTAs that spend billions on marketing. Booking.com alone spent over $5 billion on marketing in 2024. An AI travel startup trying to acquire users is competing with companies that can outspend them 100-to-1. The average CAC for a travel app user is $30–$80. For a user who might book one $200 hotel room per year, generating $20 in commission, the math doesn't work.

Retention is terrible. People don't travel every day. They book a trip, use the app for a week, and then don't open it again for 6–12 months. By the time they travel again, they've forgotten the app exists, or they've seen an ad for a competitor. Monthly active users (MAU) spike around booking periods and crash in between.

Monetization is indirect. Most AI travel apps make money through affiliate commissions — they send users to OTAs and get a cut of the booking. This means they're not really a travel business; they're a marketing channel for OTAs. And OTAs know it — they can change commission rates, reduce cookie windows, or launch competing products at any time. The app's revenue is entirely dependent on the goodwill of companies that see them as either customers or threats.

The AI isn't defensible. Every AI travel app uses the same underlying models (GPT, Claude, Gemini) and the same inventory sources (OTA APIs). The "AI" in "AI travel app" is a thin layer on top of commoditized infrastructure. There's no moat. A competitor can build the same app in a weekend.

Put it all together: high CAC, low retention, indirect monetization, no moat. This is a recipe for burning investor money until the funding runs out. And that's exactly what's happening.

The MCP Money Machine: Where the Profit Is

Now look at the other side of the market: MCP infrastructure. These are the companies building the servers, protocols, and tools that let AI agents connect to real-world services like hotel booking. They're not building consumer apps. They're building the pipes.

And they're making money. Here's why:

Customers are developers and businesses, not consumers. MCP infrastructure companies sell to developers who build AI agents, and to businesses that want their services accessible through AI. These customers have budgets, make purchasing decisions rationally, and don't require Super Bowl ads to acquire. CAC is a fraction of consumer app CAC.

Revenue is recurring and transaction-based. MCP servers charge either a monthly subscription, a per-transaction fee, or a freemium model with paid tiers. Every time an AI agent books a hotel through the MCP server, the server generates revenue. This is direct monetization — no affiliate links, no cookie windows, no dependence on OTA goodwill.

Retention is structural. Once a developer integrates an MCP server into their AI agent, switching costs are high. The agent is built around the MCP server's tools, data formats, and APIs. Moving to a competitor requires rewriting integration code, retesting, and risking breakage. Developers stay. Businesses stay. Revenue compounds.

The infrastructure is the moat. A hotel MCP server that has real-time inventory from 2 million+ hotels, reliable pricing APIs, and customer support is not something a competitor can build in a weekend. It requires supplier relationships, technical infrastructure, compliance certifications, and operational scale. This is a real moat.

RollingGo is the case study. It aggregates 2 million+ hotels from 500+ suppliers across 200+ countries, including 110,000+ directly contracted properties. Its v1.0 exposes three tools (searchHotels, getHotelDetail, getHotelSearchTags) through a single MCP endpoint. The business model is deliberately counterintuitive: API keys are free, calls are unlimited, approval is instant. No credit card required. No rate limits. No per-query fees.

How does that make money? Four identity tiers capture value at different levels:

Personal — free, for individual AI tool users (builds ecosystem adoption)
Developer — free, with Partner Center access for traffic analytics (locks in integration)
KOL/Affiliate — free, with tracked bookingUrl links that earn commission on every completed booking (revenue share without infrastructure cost)
Enterprise — paid, with team management, budget controls, audit trails, and volume pricing (the real revenue engine)

The free tier isn't a charity — it's a distribution strategy. Every developer who connects RollingGo to their agent is another distribution channel. Every KOL who uses the affiliate link is another salesperson. The enterprise tier captures the value when those channels scale. This is the AWS playbook: give away the infrastructure to developers, then monetize the enterprise demand that follows.

The connection takes five minutes:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer mcp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

The result: MCP infrastructure companies have low CAC, high retention, direct monetization, and real moats. They're profitable or on a clear path to profitability. Meanwhile, AI travel apps burn cash chasing consumers who don't come back.

The Numbers: A Side-by-Side Comparison

Let me make this concrete with a hypothetical but realistic comparison:

Metric	AI Travel App	MCP Infrastructure
Customer type	Consumer traveler	Developer / business
CAC	$40	$200 (but 1 customer = 1000s of end users)
Retention (12-month)	15%	85%
Revenue per customer	$20/year (affiliate)	$1,200/year (subscription + transactions)
LTV:CAC	0.75:1 (losing money)	5:1 (profitable)
Time to profitability	36+ months (if ever)	12–18 months
Moat	None	Inventory + relationships + scale

The AI travel app spends $40 to acquire a user who generates $20 in lifetime revenue. It loses $20 per user. The MCP infrastructure company spends $200 to acquire a developer who generates $1,200 in annual recurring revenue. It makes $1,000 per customer per year, and that customer stays for years.

This isn't a close call. The infrastructure business is fundamentally better.

Why This Pattern Keeps Repeating

This isn't the first time we've seen this pattern. In every major technology shift, the companies that make money are the ones that build infrastructure, not the ones that build consumer applications on top of it:

Gold rush: Levi Strauss sold jeans to prospectors. The prospectors mostly went broke. Levi Strauss became wealthy.
Internet boom: Cisco sold routers. Akamai sold CDN. AWS sold cloud computing. The consumer apps built on top of them (Pets.com, Webvan) went bankrupt. The infrastructure companies thrived.
Mobile boom: Apple sold iPhones. Google sold Android. App developers made pennies. The platform owners made billions.
AI boom: NVIDIA sells GPUs. OpenAI sells models. MCP servers sell infrastructure. The AI apps built on top are fighting for scraps.

The pattern is clear and consistent: in a technology gold rush, sell picks and shovels. Don't dig for gold.

In AI travel, the "picks and shovels" are MCP infrastructure — the servers, protocols, and tools that let AI agents connect to real travel inventory and complete bookings. The "gold" is the consumer travel booking, which everyone is chasing and almost no one is capturing profitably.

What This Means for Founders and Investors

If you're a founder building an AI travel app, you have three options:

Option 1: Keep building the app and hope for the best. Maybe you'll be the one consumer app that breaks through. The odds are against you, but it's possible. You'll need a huge marketing budget, a viral growth loop, or a unique value proposition that no one can copy. Most apps don't have any of these.

Option 2: Pivot to infrastructure. Stop building a consumer app and start building the infrastructure that powers AI travel. This is harder technically but easier commercially. You'll sell to developers and businesses, not consumers. You'll have recurring revenue, high retention, and a real moat. This is the path that's already generating profit.

Option 3: Hybrid model. Build a consumer app that's powered by your own MCP infrastructure. The app is a demonstration of the infrastructure's capabilities (and a source of direct booking revenue), while the infrastructure is sold to other developers and businesses. This is the AWS model — Amazon built AWS to power its own retail business, then sold it to everyone else.

If you're an investor, the math is simple: infrastructure investments have better risk-adjusted returns than consumer app investments. You're not betting on a single app's viral growth. You're betting on a structural shift in how AI agents connect to real-world services. That shift is happening regardless of which consumer app wins.

The Counterargument: "But Someone Has to Build the Apps!"

I know what you're thinking. "If everyone builds infrastructure and no one builds apps, there's no demand for the infrastructure." And you're right — there needs to be a healthy ecosystem of AI travel apps to drive demand for MCP infrastructure.

But here's the thing: the apps will be built. They'll be built by thousands of developers, small teams, and niche players. They won't be giant, venture-backed consumer apps. They'll be specialized agents — a ski trip planner, a business travel optimizer, a family vacation coordinator — each serving a specific niche. These apps will be profitable at small scale because they have low CAC (niche targeting) and high retention (serving a specific use case).

The infrastructure providers will serve all of them. That's the beauty of the infrastructure model: you don't need to bet on which app wins. You win regardless, because every app needs your infrastructure.

The Bottom Line

The AI travel market is undergoing a massive shift. Consumer-facing AI travel apps are burning investor money with no clear path to profitability. MCP infrastructure companies are generating real revenue with strong unit economics. The pattern is as old as technology shifts: infrastructure wins, applications fight for scraps.

If you're building in this space, ask yourself: am I selling picks and shovels, or am I digging for gold? The answer determines whether you'll be profitable in 18 months or out of business in 36.

The gold rush is on. Everyone's chasing the consumer. The smart money is building the rails.

The hotel MCP infrastructure that's powering the next generation of AI travel apps is open-source and free to start using: RollingGo Hotel MCP on GitHub.

The AI Era of Hotel Direct Sales: Bypassing OTAs and Letting Agents Find You Directly

Becky_dev — Mon, 12 Oct 2026 13:23:00 +0000

For the past two decades, hotel distribution has followed one rule: if you want bookings, you need OTAs. Booking.com, Expedia, Airbnb — these platforms control the funnel. Travelers go to them, search there, and book there. Hotels pay 15–25% commission for every booking, plus additional fees for premium placement, sponsored listings, and promotional campaigns.

The math is brutal. A $200 hotel room nets the hotel $150–$170 after OTA commissions. For a hotel with 70% OTA dependency, that's millions in annual commission payments. Hotels have tried to fight back — loyalty programs, direct booking discounts, website optimization — but the OTAs keep winning because they control the discovery channel. Travelers don't go to hotel websites; they go to OTAs.

AI agents change this. When a traveler books through an AI assistant, the OTA website may never be opened. The agent searches inventory, compares options, and completes the booking — all within a conversation. The question for hotels is no longer "how do we rank higher on OTA search results?" It's "how do we make sure AI agents find us and book us?"

The Distribution Shift, Explained

To understand why this is different from previous "OTA killer" hype cycles, you need to understand how AI agents discover hotels.

In the OTA model, discovery is visual and algorithmic. The traveler sees a list of hotels with photos, ratings, prices, and "sponsored" tags. They scroll, compare, and select. The OTA controls the ranking algorithm, the display format, and the booking flow. Hotels pay for visibility.

In the AI agent model, discovery is conversational and data-driven. The traveler describes what they want ("a quiet hotel in downtown Austin with a gym, under $180"). The agent queries inventory sources, filters results, and presents a small number of recommendations — often just 2–3 options, not 50. The ranking is based on relevance to the user's criteria, availability, and price accuracy. There are no sponsored placements. There are no visual ads. There's no scrollable list to optimize for.

This is a fundamentally different discovery mechanism. In the OTA model, visibility is purchased. In the AI model, visibility is determined by data quality and accessibility. A hotel with accurate, real-time inventory data that's connected to the agent's inventory source will be recommended. A hotel with stale data, incomplete descriptions, or inventory locked behind proprietary APIs may not appear at all.

The implication is profound: hotels can't buy their way into AI agent recommendations. They have to earn their way in by making their inventory accessible, accurate, and complete.

Why Direct Beats OTA in the AI Era

Hotels that connect their inventory directly to AI agent infrastructure — through MCP servers or similar standardized interfaces — gain three advantages over hotels that rely on OTAs:

First, lower distribution costs. A direct MCP connection eliminates the 15–25% OTA commission. Instead, the hotel pays a flat fee or transaction fee to the MCP infrastructure provider, which is typically a fraction of the OTA commission. On a $200 room, that's $30–$50 in savings per booking. For a hotel doing 10,000 bookings/year through AI agents, that's $300,000–$500,000 in annual savings.

Second, better data quality. When a hotel connects directly, it controls the data — room descriptions, photos, amenities, policies, pricing. There's no OTA middleman modifying descriptions, cropping photos, or displaying outdated information. The agent sees exactly what the hotel wants it to see. This leads to more accurate recommendations, fewer booking errors, and higher guest satisfaction.

Third, customer relationship ownership. OTA bookings are OTA customers — the OTA owns the guest data, the communication, and the loyalty relationship. Direct AI bookings are the hotel's customers. The hotel has the guest's contact information, booking history, and preferences. This enables personalized marketing, loyalty program enrollment, and direct communication — all of which drive repeat bookings and reduce future distribution costs.

The Practical Path to AI Direct Sales

Getting direct AI bookings isn't complicated, but it requires a specific set of actions. Here's the step-by-step path:

Step 1: Audit your inventory data. Before connecting to anything, make sure your data is clean. Are room descriptions accurate and complete? Are photos high-quality and current? Are amenity lists up to date? Are cancellation policies clearly stated? AI agents rely on this data to make recommendations. Incomplete data means incomplete recommendations — and fewer bookings.

Step 2: Connect to an MCP server. A hotel MCP server acts as the bridge between your inventory system and AI agents. It exposes your real-time availability, pricing, and booking capability through standardized tools that any AI agent can call. The connection is typically through your property management system (PMS) or channel manager, with the MCP server handling the protocol translation.

Step 3: Ensure real-time pricing and availability. This is critical. AI agents reject stale data. If your MCP connection shows a room as available when it's actually sold out, the agent will recommend it, the booking will fail, and the agent will learn not to recommend your hotel. Real-time inventory sync is non-negotiable.

Step 4: Optimize for agent discovery. AI agents don't read marketing copy. They read structured data. Make sure your hotel's structured data — location, star rating, amenity tags, room types, price ranges — is accurate and complete. The agent uses this data to match hotels to user criteria. A hotel tagged "pet-friendly" and "has gym" will be recommended for users searching for those attributes. A hotel with incomplete tags won't.

Step 5: Offer competitive direct pricing. If your direct AI price is higher than the OTA price, agents will recommend the OTA option. Price parity is important — but you can offer direct-only perks (free breakfast, room upgrades, late checkout) that make the direct booking more attractive without lowering the headline price.

Step 6: Track and optimize. Monitor which AI agents are booking your hotel, what criteria they're using, and what your conversion rate looks like. Use this data to optimize your listing — if agents consistently filter you out for "no pool," and you do have a pool, fix the data. If you're getting lots of searches but few bookings, check your price competitiveness.

The Role of MCP Servers in Direct Sales

MCP servers are the infrastructure that makes AI direct sales possible. A hotel MCP server aggregates inventory from multiple sources — PMS systems, channel managers, central reservation systems — and exposes it through standardized tools that AI agents can call. The hotel doesn't need to build its own AI integration. It connects to the MCP server, and the server handles the rest.

RollingGo is a concrete example of this model at scale. It operates 110,000+ directly contracted hotels alongside 2 million+ total properties from 500+ global suppliers, all exposed through a single MCP endpoint. For directly contracted hotels, the connection goes straight to the property's reservation system — no OTA middleman, no commission markup. The hotel sets its own rates, controls its own inventory, and owns the customer relationship.

For any AI agent, the connection is identical — one JSON block, one endpoint:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer mcp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

The agent gets three tools: searchHotels (real-time pricing across the full inventory), getHotelDetail (room types, amenities, policies), and getHotelSearchTags (structured filters). Every price comes from a live query — direct-contract hotels return the hotel's own rates, not OTA-marked-up prices. The bookingUrl in each result points to the hotel's booking page, not an OTA.

For hotel groups and chains, this model provides a centralized way to manage AI distribution across all properties. Instead of each property managing its own AI integrations, the group connects its central reservation system through the MCP server, and all properties become available to AI agents simultaneously. This is the AI equivalent of a channel manager — but instead of distributing to OTAs, it distributes to AI agents. And because direct-contract inventory bypasses the OTA commission layer, the hotel keeps 100% of the revenue on direct bookings.

The economics are compelling. A typical MCP server charges either a flat monthly fee, a per-booking transaction fee (often 1–3%, compared to 15–25% for OTAs), or a freemium model with free basic access and paid enterprise features. Even at the high end, MCP distribution costs are a fraction of OTA costs.

What This Means for Different Hotel Types

Independent hotels. This is the biggest opportunity. Independent hotels have always struggled with OTA dependency — they lack the brand recognition to drive direct traffic, so they're forced to pay OTA commissions. AI direct sales levels the playing field: an independent hotel with good data and a direct MCP connection can be recommended by AI agents just as easily as a chain hotel. The discovery mechanism is data-driven, not brand-driven.

Boutique and lifestyle hotels. These hotels thrive on personality and unique experiences — attributes that don't always translate well to OTA search filters. AI agents can understand nuanced preferences ("a hotel with character, near live music venues") and match them to boutique hotel descriptions. A well-curated MCP listing with rich, accurate descriptions can outperform generic chain hotels in agent recommendations.

Chain hotels. Chains have the advantage of scale and brand recognition, but they also have the most to lose from OTA dependency. A chain that connects its entire portfolio to an MCP server can offer AI agents consistent, accurate inventory across thousands of properties — a value proposition that's hard for independent hotels to match. Chains should treat AI direct sales as a strategic priority, not an experiment.

Hostels and budget properties. Price-sensitive travelers are early adopters of AI booking — they want the cheapest option, and AI agents excel at price comparison. Budget properties with competitive pricing and real-time availability will capture a disproportionate share of AI bookings.

The Timeline: When This Matters

AI direct hotel bookings are still a small percentage of total bookings today. But the growth rate is significant, and the trajectory is clear. Here's a realistic timeline:

2026 Q4–2027 Q1: Early adopter phase. Tech-savvy travelers and business users book through AI agents. Hotels that connect early capture the first wave of AI direct bookings with minimal competition. This is the window where early movers establish their presence in agent recommendation systems.

2027 Q2–Q4: Growth phase. AI booking becomes mainstream as consumer AI assistants add booking capabilities. Hotel groups begin connecting portfolios to MCP servers. OTA commission rates start feeling pressure as direct AI bookings grow.

2028+: Mainstream phase. AI agents handle a significant share of hotel bookings — potentially 20–30% of all online bookings. Hotels without direct AI connections find themselves invisible to a major booking channel. OTA market share declines as direct AI sales grow.

The hotels that start now will be well-positioned when AI booking becomes mainstream. The hotels that wait will be playing catch-up, trying to optimize their MCP listings while competitors have already built relationships with agent systems and captured market share.

The Bottom Line

Hotel distribution is undergoing its biggest shift since OTAs displaced travel agencies. The shift this time isn't from one intermediary to another — it's from intermediaries to direct, AI-mediated connections. Hotels that make their inventory accessible, accurate, and available through standardized interfaces will be discovered and booked by AI agents. Hotels that rely on OTA visibility will find themselves increasingly invisible to the fastest-growing booking channel.

The cost of entry is low. The potential savings are significant. The timeline is short. The question for every hotel operator isn't whether AI direct sales will matter — it's whether they'll be ready when it does.

Your inventory is your product. In the AI era, accessibility is your shelf space. Make sure you're on the shelf.

Hotels ready to connect their inventory to AI agents can start with a free API key and setup guide on the official site: RollingGo Official.

The Indie Developer's Q4 Playbook: Build a Money-Making MCP Side Project

Becky_dev — Sun, 11 Oct 2026 13:00:00 +0000

Q4 is the most important quarter for indie developers. It's the last chance to hit revenue goals before the year ends. It's when enterprise buyers finalize next year's budgets. It's when consumer spending peaks and usage patterns shift. And for developers building AI tools, it's the window to turn a side project from "interesting experiment" into "real revenue."

MCP changes the economics of building an AI side project. Before MCP, building an AI tool that could book hotels, query databases, or manage calendars required months of API integration work. Now it takes a configuration block. The barrier to entry has collapsed. But the barrier to making money hasn't — and that's where most indie developers fail.

This is a practical Q4 playbook for building an MCP-based side project that generates real revenue before December 31. No fluff, no hype, just what works.

Why Q4 Is the Right Time

Three reasons Q4 is the best quarter to launch an MCP side project:

Enterprise budget cycles. Companies that haven't spent their annual AI/tooling budget by Q4 are looking for places to spend it. A well-timed launch with a clear value proposition can capture end-of-year budget that would otherwise expire. Even a $50/month SaaS subscription looks attractive to a team manager with $5,000 left in the budget and two weeks to spend it.

Holiday usage spikes. Consumer AI usage spikes during the holidays — people travel more, plan more, and have more time to experiment with new tools. A travel-focused MCP project launched in mid-October captures the Thanksgiving and Christmas travel booking waves.

New year planning. December is when people and companies plan for the next year. A tool that saves time or makes money gets added to next year's stack. Launching in Q4 means you're top-of-mind when budgets are being set for January.

Step 1: Pick the Right MCP Project

Not every MCP project can make money. The ones that do share three characteristics: they solve a painful problem, they handle transactions (not just queries), and they target a market with budget.

Here's a framework for evaluating MCP project ideas:

Does it handle money? Projects that process payments, bookings, or transactions have a clear revenue model — take a percentage of each transaction. Projects that only provide information struggle to monetize because users expect information to be free. A hotel booking MCP agent can charge a booking fee. A hotel search MCP agent can't.

Is the problem frequent? A tool that's used once a month is harder to monetize than one used weekly or daily. Travel booking is frequent for business travelers. Restaurant reservations are frequent for urban professionals. Calendar management is daily. Pick a problem users encounter regularly.

Is there a budget? Consumers will pay for convenience, but businesses will pay more. A tool that saves a business $500/month is worth $100/month. A tool that saves a consumer $10/month is worth $2/month. Target business users if you want meaningful revenue.

Can you build it in a week? If it takes longer than a week to build an MVP, it's too complex for a Q4 side project. MCP's power is that you can assemble powerful tools quickly — use that advantage.

Using this framework, here are three MCP side project ideas that can generate revenue in Q4:

Idea 1: AI Travel Booking Agent for Small Businesses. Build a Slack or Discord bot that lets employees book hotels and flights through natural language, with built-in policy compliance (budget limits, preferred vendors, approval workflows). Charge $15/user/month. The hotel and flight inventory comes from an MCP server; you build the Slack interface, policy engine, and approval workflow.

Idea 2: AI Meeting Scheduler with Booking Integration. Build a tool that schedules meetings AND books nearby hotels for out-of-town attendees. When someone accepts a meeting in another city, the agent automatically searches for hotels near the meeting location, presents options, and books if approved. Charge $29/month per company. Calendar and hotel MCP servers handle the data; you build the orchestration logic.

Idea 3: AI Expense Reconciliation Agent. Build an agent that automatically matches hotel and flight bookings to expense reports, extracts receipts, and flags policy violations. Connect to hotel MCP servers for booking data and accounting software for expense data. Charge $49/month per company. This is a pure orchestration play — the MCP servers provide the data, you provide the reconciliation logic.

All three ideas can be built in under a week using MCP servers for the heavy lifting. All three target business users with budget. All three handle transactions or financial data, which makes monetization straightforward.

Step 2: Build the MVP in Seven Days

Day 1–2: Connect the MCP servers and verify tool access. For a travel booking agent, this means connecting a hotel MCP server and a flight MCP server, testing search and booking tools, and understanding the data formats. Don't build anything yet — just understand what the tools can do.

Day 3: Build the core interaction loop. This is the conversation flow: user describes what they want → agent searches → presents options → user selects → agent confirms details → completes action. For a booking agent, this is search → select → confirm price → collect details → book → confirm. Get this loop working end-to-end before adding features.

Day 4: Add the monetization hook. This is the feature that makes users willing to pay. For a business travel agent, it's policy compliance — automatic budget checks, preferred vendor filtering, approval workflows. For a meeting scheduler, it's the automatic hotel booking. For an expense agent, it's the automatic reconciliation. Build only the monetization hook — nothing else.

Day 5: Add the platform integration. If it's a Slack bot, build the Slack integration. If it's a web app, build the login and dashboard. Keep it minimal — users need to sign up, connect their MCP configuration, and use the core loop. That's it.

Day 6: Test with 5 real users. Not friends, not family — real potential users. Find them in developer communities, Slack groups, Discord servers, LinkedIn. Give them free access for a week. Watch how they use it. Ask what they'd pay for. Fix the top 3 bugs.

Day 7: Launch. Write a launch post, publish it, and start collecting paying users. Don't wait for perfection — launch with the core loop working and the monetization hook in place. Everything else can be added after launch.

Step 3: Monetize from Day One

The biggest mistake indie developers make is waiting to monetize. They build, they launch, they get users, and then they try to figure out how to make money. By then, users expect the product to be free.

Monetize from day one. Here's how:

Freemium with a clear paid tier. Free tier: 5 bookings/month, basic search. Paid tier: unlimited bookings, policy compliance, team management, priority support. Price it at $15–$49/month depending on the target market. The free tier builds usage; the paid tier captures revenue.

Transaction fees and affiliate commissions. For booking-focused projects, you don't need to build your own payment system. RollingGo Hotel MCP offers a KOL (Affiliate) identity that gives you a tracked affiliate link for every hotel in its 2 million+ inventory. Register as a KOL, get your API key instantly (free, unlimited calls), and every hotel your agent recommends carries your affiliate tracking. When a user books through your link, you earn commission — no payment processing, no merchant account, no fraud handling on your end.

Here's the configuration that gets you started:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer mcp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

The searchHotels tool returns a bookingUrl field for every result — that's your affiliate link. Your agent presents the hotel, the user clicks through, and the commission is tracked automatically in the RollingGo Partner Center. You can view earnings, traffic logs, and conversion rates in real time. This is the fastest path from "I built an agent" to "I'm making money" — zero payment infrastructure, zero merchant fees, zero compliance overhead.

Annual plans at a discount. Offer a 20% discount for annual payment. This improves cash flow and increases user commitment. A $29/month plan becomes $278/year — that's real revenue per customer.

Enterprise tier. Once you have 20–30 paying customers, offer an enterprise tier with SSO, custom integrations, dedicated support, and volume pricing. Target companies with 50+ employees. Price it at $500–$2,000/month. One enterprise customer can equal 50 individual customers in revenue.

Step 4: Get Your First 100 Users

Distribution is the hardest part of any side project. MCP projects have a built-in distribution advantage: they can be discovered through MCP directories and integrated into existing AI clients. Here's how to leverage that:

List in every MCP directory. There are growing directories of MCP servers and agents. List your project in all of them. These directories are early, so competition is low and visibility is high.

Write about the build process. Developer communities love behind-the-scenes content. Write a post about how you built the project in a week using MCP servers. Include code snippets, architecture diagrams, and lessons learned. This drives traffic from developers, some of whom become users.

Target specific communities. Don't post in general "AI" communities — post in communities for your target users. If you built a business travel agent, post in startup communities, remote work groups, and small business forums. If you built a meeting scheduler, post in product management and operations communities.

Offer a launch discount. 50% off for the first 100 customers. This creates urgency and gives you a base of paying users to learn from. Once you hit 100, raise the price.

Leverage the MCP ecosystem. If your project uses a popular MCP server, reach out to the server's developers. They often feature projects built on their infrastructure. A mention from a well-known MCP server can drive hundreds of sign-ups.

Step 5: Scale Revenue in Q4

Once you have paying users, Q4 is about scaling revenue. Three tactics:

Usage-based upsells. Monitor how users use the product. If a free-tier user is hitting the 5-booking limit every month, send them a personalized upgrade offer. If a paid user is booking for their entire team, pitch them the team plan. Data-driven upsells convert at 5–10%.

Holiday promotions. Black Friday, Cyber Monday, and end-of-year promotions work for B2B SaaS too. Offer 30–40% off annual plans during the last week of November and the last week of December. This captures budget-conscious buyers and annual-plan upgraders.

Referral program. Give existing users a free month for each referral that becomes a paying customer. This turns your happiest users into a sales force. For a $29/month product, a free month ($29 value) is a cheap acquisition cost.

The Reality Check

Let me be honest about what this takes. Building an MCP side project that generates real revenue in Q4 is doable, but it's not passive income. It requires focused execution: one week to build, one week to launch, and ongoing iteration based on user feedback. The MCP infrastructure handles the hard parts — inventory, booking, payments — but you still need to build the product, find users, and iterate.

The developers who succeed in Q4 won't be the ones with the best technology. They'll be the ones who pick a painful problem, build the minimum viable solution, charge money from day one, and talk to users constantly. MCP removes the technical barrier. It doesn't remove the execution barrier.

But here's the thing: the execution barrier is lower than it's ever been. A year ago, building a hotel booking agent required months of API integration. Today it requires a JSON configuration block and a week of development. The indie developers who recognize this shift and act on it in Q4 will be the ones reporting revenue in January.

The clock is ticking. Q4 started. What are you building?

The hotel booking MCP server used in these project ideas is open-source — study the architecture, fork it, or build on top of it: RollingGo Hotel MCP on GitHub.

MCP's Next Battlefield: From Tool Connection to Identity and Permissions

Becky_dev — Sat, 10 Oct 2026 13:00:00 +0000

MCP solved a hard problem: how do AI agents discover, connect to, and call external tools? Before MCP, every agent needed custom integration code for every tool. After MCP, a single configuration block connects an agent to any compatible server. The connection problem is largely solved.

But solving connection exposed the next problem, and it's a bigger one: when an AI agent calls a tool, whose identity is it using? And what is it allowed to do?

This is the identity and permission problem, and it's the next major battlefield in the MCP ecosystem. Get it right, and MCP becomes enterprise-ready infrastructure. Get it wrong, and MCP remains a developer toy — useful for personal projects, too risky for business-critical systems.

Why Identity Matters More Than You Think

Let's start with a concrete scenario. You're an employee at a mid-sized company. You connect your company's internal AI assistant to three MCP servers: a hotel booking server for travel, a calendar server for scheduling, and a database server for analytics. The assistant can now book hotels, schedule meetings, and query company data.

Whose identity does it use when it does these things?

If it uses a shared service account — one API key for all users — then every employee's bookings, calendar events, and database queries happen under the same identity. There's no audit trail showing who did what. There's no way to enforce per-user permissions. There's no way to know whether that hotel booking was made by Alice from marketing or Bob from engineering.

If it uses your identity — your personal API key, your user account — then the assistant acts as you. It can book hotels with your travel budget, schedule meetings on your calendar, query databases you have access to. This is more secure and auditable, but it requires the MCP server to understand and respect your identity. And it raises the next question: what if the assistant tries to do something you're not allowed to do?

The Permission Problem

Identity answers "who is acting." Permissions answer "what are they allowed to do." In the MCP context, this breaks down into several layers:

Tool-level permissions. Can this user call this tool at all? A junior employee might be allowed to search hotels but not book them. A contractor might be allowed to query the analytics database but not modify it. Tool-level permissions control which tools are available to which users.

Parameter-level permissions. Even within a single tool, different users might have different parameter constraints. A sales employee might be allowed to book hotels up to $300/night; an engineer might be limited to $200/night. A manager might be allowed to book for any date; a new hire might need approval for bookings more than 30 days out. Parameter-level permissions constrain the inputs to each tool call.

Data-level permissions. When a tool returns data, different users might see different results. A hotel booking tool might return all available rooms to a travel coordinator but only rooms within the user's budget to a regular employee. A database query tool might return full records to an admin but masked records to a regular user. Data-level permissions control what the tool returns based on who's asking.

Rate and budget permissions. How many times can this user call this tool per day? How much can they spend? A hotel booking tool might have a monthly budget per user. A database query tool might have a daily call limit. These permissions prevent abuse and control costs.

Most MCP servers today handle none of this. They use a single API key for all access, with no user identity, no per-user permissions, and no audit trail. This is fine for personal projects and developer experimentation. It's completely inadequate for enterprise deployment.

The Current State: Three Approaches (None Perfect)

MCP server developers are tackling identity and permissions in three ways, each with trade-offs:

Approach 1: Shared API keys with server-side rules. The server issues one API key per organization, and all users in that organization share it. The server enforces some rules — rate limits, budget caps — but can't distinguish between users. This is the simplest approach and the most common today. It's also the least secure: no per-user audit trail, no per-user permissions, no way to revoke access for a single employee without rotating the shared key.

Approach 2: User-specific API keys. Each user gets their own API key, which they configure in their AI client. The MCP server can identify the user from the key and enforce per-user permissions. This is more secure but creates a management burden: users must manually configure their key in every client, administrators must provision and revoke keys, and keys can be shared or leaked. It also doesn't work well for web-based AI clients that can't securely store per-user secrets.

Approach 3: Token exchange and identity propagation. The AI client obtains an identity token for the current user (through OAuth, SSO, or another auth mechanism) and passes it to the MCP server with each tool call. The server validates the token, identifies the user, and enforces permissions. This is the most secure and scalable approach, but it's also the most complex. It requires the AI client to support token passing, the MCP server to validate tokens, and an identity provider that both trust.

The industry is moving toward Approach 3, but we're not there yet. Most MCP clients don't support identity token passing. Most MCP servers don't validate user identities. The protocol specification doesn't yet mandate a standard identity mechanism. This gap is the next major area of protocol evolution.

Real-World Example: How RollingGo Handles Identity Today

RollingGo Hotel MCP shows how a production MCP server approaches identity in the current protocol landscape. Instead of waiting for a standard identity layer, it uses four distinct registration identities, each with different permissions and backend capabilities:

Identity	Who It's For	Key Capabilities	Backend Access
Developer	Building agents or travel programs	Full MCP tools, unlimited calls	Partner Center: markup rates, traffic logs, orders
Enterprise	Company-wide travel integration	Full MCP tools, team management	Partner Center: employee budgets, audit trails, invoicing
Personal	Using AI tools for personal travel	Full MCP tools, no backend needed	Install instructions only — no admin account
KOL (Affiliate)	Content creators with distribution	Full MCP tools + affiliate links	Partner Center: earnings dashboard, H5/mini-program links

Registration is instant — no manual review, no waiting period. Each identity receives a 32-character API key (format: mcp_xxxxx...) that serves as both authentication and identity marker. The key goes in the standard MCP authorization header:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer mcp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

This approach isn't perfect — it's essentially Approach 2 (user-specific API keys) with structured identity tiers. But it solves real problems today: enterprises get audit trails and budget controls through the Partner Center, developers get traffic analytics, affiliates get earnings tracking. And it does it all within the current MCP protocol, without waiting for a standard identity layer.

The lesson for the MCP ecosystem is that identity doesn't have to be all-or-nothing. Structured API key tiers, scoped permissions, and backend dashboards can deliver 80% of the value of a full OAuth identity system, today. The remaining 20% — true SSO integration, real-time token exchange, cross-server identity propagation — will come as the protocol evolves.

Why Enterprises Care About This

For enterprises, identity and permissions aren't nice-to-haves — they're deployment blockers. A company can't deploy an AI assistant that books hotels using a shared service account, because:

Compliance requires audit trails. Many industries are required to know who made what booking, when, and for what purpose. A shared account makes this impossible.
Budget controls require per-user limits. Companies have per-employee travel budgets. A shared account can't enforce them.
Security requires least privilege. An AI assistant that can query any database, book any hotel, and schedule any meeting is a security risk. Per-user permissions limit the blast radius of a compromised agent.
Privacy requires data segregation. Employees shouldn't see each other's bookings, calendar events, or query results. Identity-based data permissions enforce this.

Until MCP solves identity and permissions, enterprise adoption will be limited to low-risk use cases — personal productivity, information lookup, non-transactional tasks. The high-value use cases — automated booking, financial transactions, data modification — will remain off-limits.

What a Good Identity System Looks Like

The MCP ecosystem doesn't need to reinvent identity. The building blocks exist. What's needed is a standard way to combine them:

OAuth 2.0 for authorization. The AI client obtains an access token from an identity provider (the company's SSO system, or a dedicated MCP auth service). This token represents the user's identity and contains scopes that define what the user is allowed to do.

Token passing in MCP requests. The client includes the access token in each tool call, either as a header or as a standard protocol field. The MCP server validates the token before processing the request.

Scope-based tool permissions. Each MCP tool declares required scopes (e.g., hotel:search, hotel:book, hotel:cancel). The server checks that the user's token contains the required scope before allowing the tool call. This gives administrators fine-grained control over which users can use which tools.

User context in tool calls. The server extracts the user's identity from the token and uses it to filter data, enforce budget limits, and write audit logs. The agent doesn't need to know the user's identity — the server handles it automatically.

Audit logging. Every tool call is logged with the user's identity, the tool called, the parameters passed, and the result. This creates a complete audit trail for compliance and security analysis.

This architecture is well-understood in the API world — it's how most modern SaaS platforms handle authentication and authorization. The challenge is standardizing it for MCP so that any client can work with any server, without custom integration code.

The Roadmap for MCP Identity

The MCP specification is evolving, and identity is on the roadmap. Here's what I expect to see over the next 12–18 months:

Phase 1: Standardized auth headers. The MCP spec defines a standard way to pass authentication tokens in requests. This is a small change but an important one — it gives clients and servers a common mechanism rather than each server inventing its own.

Phase 2: Scope declarations. MCP servers can declare required scopes for each tool in their tool descriptions. Clients can display these scopes to users before connecting, similar to how OAuth apps request permissions. Users can make informed decisions about what they're granting access to.

Phase 3: Identity-aware servers. MCP servers begin validating user identities and enforcing per-user permissions. This requires server developers to build auth systems, but the protocol provides the standard interface.

Phase 4: Enterprise identity integration. MCP servers integrate with enterprise identity providers (Okta, Azure AD, Google Workspace) through SAML and OIDC. This allows companies to use their existing identity systems to control MCP access, without managing separate API keys.

Phase 5: Zero-trust agent architecture. AI agents operate under strict identity and permission constraints, with every action auditable and revocable. This is the end state — MCP as enterprise-grade infrastructure, with security baked in from the start.

What Developers Should Do Now

If you're building an MCP server today, don't wait for the protocol to solve identity. Start building identity-aware features now:

Support multiple API keys per organization. Even if you can't distinguish individual users yet, allowing organizations to create multiple keys (e.g., one per team) is a step toward granular access control.
Add audit logging. Log every tool call with the API key used, timestamp, tool name, and parameters. Even without user identity, this provides a basic audit trail.
Implement rate limits and budget controls. Per-key rate limits and spending caps prevent abuse and give organizations basic cost control.
Design for token-based auth. Even if you're using API keys today, structure your code so that switching to token-based authentication later is a configuration change, not a rewrite.
Document your security model. Tell users exactly how authentication works, what data is logged, and what permissions are enforced. Transparency builds trust.

If you're building an AI client, prioritize identity support:

Support per-user API key configuration. Let users enter their own API keys for each MCP server, rather than using a shared key.
Display tool permissions before connecting. When a user adds an MCP server, show them what tools the server provides and what actions those tools can perform.
Add confirmation steps for transactional tools. Before the agent calls a tool that modifies data (booking, payment, deletion), show the user what the agent is about to do and ask for confirmation.
Support OAuth token passing. As the MCP spec standardizes token-based auth, add support for it in your client. This will be a key differentiator for enterprise users.

The Bottom Line

MCP won the connection battle. The next battle is identity — and it's a harder fight. Connection is a technical problem; identity is a technical problem wrapped in a security problem wrapped in an organizational problem. It requires protocol changes, server development, client support, and enterprise adoption.

But the stakes are high. MCP with identity is enterprise infrastructure — the kind of thing companies build business-critical systems on. MCP without identity is a developer tool — useful, interesting, but limited to personal projects and low-risk use cases.

The servers and clients that solve identity first will own the enterprise market. The ones that don't will be left in the developer ghetto, watching from the outside as the real money gets made elsewhere.

The connection problem is solved. The identity problem is next. Who's building it?

If you're building an MCP server and want to get identity and permissions right from the start, the official quick-start guide covers the basics in five minutes: RollingGo MCP Quick Start.

I Had 5 AI Assistants Book the Same Hotel. The Prices Differed by $300.

Becky_dev — Fri, 09 Oct 2026 08:00:47 +0000

Here's the setup: one hotel, one set of dates, one room type. Five different AI assistants, each connected to the same hotel inventory source. Each assistant searches for the hotel, presents options, and attempts to complete a booking. The only variable is the AI assistant itself.

The result? A price spread of nearly $300 between the cheapest and most expensive quote. For the exact same room, on the exact same dates.

This isn't a story about AI hallucination (though that played a role). It's a story about how different AI agents handle the same tool calls, interpret the same data, and arrive at wildly different outcomes. And it reveals something important about the current state of AI travel assistants: the infrastructure is standardized, but the agent behavior is not.

The Test Setup

I selected a mid-range business hotel in a major US city — nothing exotic, nothing that would stress the inventory system. Check-in on a Tuesday, check-out on a Thursday, two nights, one king room, two guests. Standard business travel parameters.

I connected five AI assistants to the same hotel MCP server, ensuring that all five had access to identical inventory data, pricing, and booking tools. The five assistants were:

A mainstream coding assistant with MCP support
A general-purpose conversational AI with tool-calling capability
A specialized travel-focused AI agent
An open-source agent framework running locally
A platform-based assistant with custom MCP configuration

Each assistant was given the same prompt: "Find and book a king room at [hotel name] for Tuesday and Wednesday night next week, two guests. Show me the total price including taxes and fees."

I ran each assistant independently, recorded its search process, the price it quoted, and whether it could complete the booking. No coaching, no corrections — just the prompt and the tools.

The Results, Ranked by Price

Assistant 3 (specialized travel agent): $342 total. This was the cheapest and most accurate. It searched the hotel, found the king room, correctly calculated taxes and fees, and presented a clear breakdown: $139/night × 2 nights = $278, plus $42 in taxes and $22 in resort fees, totaling $342. It completed the booking in three tool calls and confirmed the reservation.

Assistant 1 (coding assistant): $368 total. Close to the correct price but missed the resort fee. It calculated $278 room + $42 tax = $320, then added a vague "additional fees may apply" note rather than the actual $22 resort fee. When I asked it to confirm the total, it re-queried and corrected itself to $342. It could complete the booking but required a follow-up question to get the price right.

Assistant 5 (platform-based): $415 total. This one found the correct room but applied a different tax rate — it used the city's general sales tax rather than the hotel occupancy tax, resulting in $65 in taxes instead of $42. It also added a $35 "booking service fee" that wasn't part of the actual pricing. It couldn't complete the booking because the price mismatch caused the booking tool to reject the transaction.

Assistant 2 (general conversational AI): $489 total. This assistant didn't use the hotel search tool correctly. Instead of querying the specific hotel, it did a general search for "hotels in [city]" and picked a different, more expensive property that it thought was the one I asked for. The $489 quote was for a different hotel entirely. When I pointed out the mismatch, it apologized and re-searched, eventually finding the correct hotel at $342 — but it took four rounds of correction.

Assistant 4 (open-source framework): $637 total. The worst result by far. This assistant found the correct hotel but selected a suite instead of a king room, applied the wrong tax rate, added two separate "service fees," and quoted a total that bore no resemblance to reality. It also attempted to create a booking without confirming the price with me first. When the booking tool rejected the mismatched price, it retried three times with different incorrect prices before giving up.

What Went Wrong (and Right)

The spread between $342 and $637 is $295 — for the same hotel, same dates, same room type. Here's what the test revealed about each failure mode:

Tool selection errors. Assistants 2 and 4 both struggled with selecting the right tool for the job. Assistant 2 used a general search tool when a specific hotel lookup was needed. Assistant 4 called the booking tool before confirming availability and pricing. The tools were available and well-documented, but the agents didn't always choose the right one at the right time.

Parameter handling. Assistant 5 passed the wrong tax rate to the pricing tool. The tool accepted the parameter (it was a valid number) but produced an incorrect result. This is a subtle failure: the tool call succeeded, the response was well-formed, but the input was wrong. No error message, no warning — just a wrong price.

Fee comprehension. Resort fees, occupancy taxes, cleaning fees, and destination charges are the bane of hotel pricing. Only Assistant 3 correctly identified and included all fees. Assistants 1 and 5 missed or misapplied fees. This isn't an AI capability problem — it's a domain knowledge problem. The specialized travel agent had been trained or prompted to look for these fees; the general assistants hadn't.

Booking completion. Only two of the five assistants could complete a booking without human intervention. The others failed at various stages: wrong hotel, wrong price, wrong room type, or tool rejection. The booking tool's validation logic caught most of these errors, but the user experience was poor — multiple rounds of correction, confusion about pricing, and in one case, repeated failed booking attempts.

The Infrastructure Is Solid. The Agents Are Not.

Here's the most important takeaway from this experiment: the MCP infrastructure worked perfectly. Every assistant could connect to the server, discover the tools, and make tool calls. The inventory data was identical across all five. The pricing engine returned consistent results when given correct inputs. The booking tool validated transactions and rejected invalid ones.

The failures were all at the agent layer — tool selection, parameter passing, domain knowledge, and multi-step reasoning. This is the current bottleneck in AI travel assistants. It's not the tools. It's not the data. It's the agent's ability to use the tools correctly, consistently, and without human correction.

This is actually encouraging news for developers. It means the hard part — building reliable inventory and booking infrastructure — is solved. The remaining work is in agent design: better tool selection logic, more robust parameter validation, domain-specific prompting for fee and tax handling, and clearer confirmation steps before transactional actions.

What This Means for Users

If you're using an AI travel assistant today, here's what the test suggests:

Always verify the total price. Don't trust the first quote. Ask for a breakdown including all taxes and fees. The difference between a correct and incorrect quote can be hundreds of dollars.
Confirm the hotel identity. AI assistants sometimes book the wrong hotel, especially in cities with multiple properties from the same chain. Verify the address and hotel name before confirming.
Use specialized agents for bookings. A travel-focused agent is more likely to handle fees, taxes, and booking logistics correctly than a general-purpose assistant.
Don't enable autonomous booking yet. With only 2 of 5 assistants completing bookings correctly, autonomous booking — where the agent books without human confirmation — is still risky. Keep human-in-the-loop confirmation for now.
Check for hidden fees. If the quote seems too good to be true, it probably is missing fees. Ask explicitly: "Does this include all taxes, resort fees, and charges?"

What This Means for Developers

If you're building an AI travel assistant, the test points to specific improvements:

Implement price confirmation as a mandatory step. Before creating a booking, re-query the exact room and rate plan to get the current live price. Present this confirmed price to the user before proceeding. This catches both AI errors and real-time price changes.

Add fee-awareness to your prompting. Explicitly instruct the agent to look for resort fees, occupancy taxes, cleaning fees, and destination charges. Provide a checklist of common fee types that the agent should verify before quoting a total.

Validate tool inputs, not just outputs. The pricing tool accepted a wrong tax rate without complaint. Add client-side validation: if the tax rate seems unusual (too high or too low for the jurisdiction), flag it for confirmation.

Build domain-specific tool wrappers. Instead of exposing raw inventory tools, build higher-level tools that handle the full booking workflow — search → select → confirm price → collect details → book → confirm. This reduces the number of decisions the agent has to make and increases consistency.

Test with real scenarios. Run your agent through standardized booking tests — different cities, different hotel types, different fee structures — and measure accuracy. The 5-assistant test I ran should be a standard QA benchmark for any AI travel product.

The Bottom Line

A $300 price spread for the same hotel room isn't a failure of AI. It's a snapshot of where the technology is right now: the infrastructure is ready, the tools are standardized, the data is accessible — but the agent layer still needs work. The assistants that got it right followed a clear process: search correctly, confirm the property, include all fees, verify the price, and book with confirmation. The ones that got it wrong skipped steps, misapplied parameters, and lacked domain knowledge.

The good news is that these are solvable problems. They don't require better models or more data. They require better agent design — more robust tool selection, mandatory confirmation steps, domain-specific prompting, and rigorous testing. The hotels are ready. The inventory is ready. The booking tools are ready. The agents just need to catch up.

And when they do? Booking a hotel through an AI assistant will be faster, cheaper, and less error-prone than any OTA website. We're not there yet. But the gap is closing, one corrected price quote at a time.

All five assistants in this test used the same hotel MCP infrastructure. You can try it yourself — free API keys and setup instructions are on the official site: RollingGo Official.

How to Give Your AI Agent Payment Capabilities: The Last Mile from "Can Recommend" to "Can Book"

Becky_dev — Thu, 08 Oct 2026 09:22:21 +0000

If you've built or used an AI travel assistant, you've probably noticed the same pattern: it's brilliant at planning. Tell it "I want a long weekend in Lisbon, under $150 a night, near the Alfama district," and it will produce a gorgeous itinerary with restaurant recommendations, transit tips, and a curated list of hotels. It will even tell you which hotel has the best rooftop bar.

But then you say, "Great, book it."

And nothing happens.

The assistant stalls. It might generate a link to an OTA website. It might say "I can't complete bookings." It might, if you're unlucky, hallucinate a confirmation number. The gap between "can recommend" and "can book" is the single biggest unsolved problem in AI travel right now — and it's not a model capability problem. It's an infrastructure problem.

Why Most AI Travel Agents Stop at the Recommendation Stage

Let's be honest about why this happens. Building an AI that can search and recommend hotels is relatively straightforward. You need a language model, some retrieval logic, and access to hotel data. The model handles the natural language part; the data handles the factual part. Even a solo developer can put together a decent recommendation engine in a weekend.

Booking is different. Booking is a transaction. Transactions require consistency, security, idempotency, and failure recovery. When a recommendation is wrong, the user sees a bad suggestion and moves on. When a booking is wrong, someone's credit card gets charged for a hotel room they can't check into.

The technical gap between recommendation and booking breaks down into six distinct stages, each with its own failure modes:

1. Intent recognition — understanding that the user wants to book, not just browse
2. Inventory query **— finding available rooms with real-time pricing
**3. Price confirmation — locking in the price before the user commits
4. Order creation — generating a booking record with traveler details
5. Payment authorization — securely charging the user's payment method
6. Confirmation callback — receiving and delivering the booking confirmation
Most AI agents never get past stage two. They query inventory, display results, and stop. The stages after that — price locking, order creation, payment — require infrastructure that most AI developers don't have access to and don't know how to build.

The Full Transaction Stack, Disassembled

Let's walk through each stage and understand what's actually required. This isn't theoretical — these are the exact components you need if you want an AI agent that can genuinely complete a hotel booking.

Stage 1: Intent Recognition

This is the only stage where the language model does most of the heavy lifting. The agent needs to distinguish between "show me hotels in Barcelona" (search intent) and "book the second one" (booking intent). It also needs to capture required parameters: check-in date, check-out date, number of guests, room type preferences.

The challenge here is that booking intent is often implicit. A user might say "that one looks good" after seeing search results, and the agent needs to understand that this is a booking request, not a compliment. Multi-round context matters — the agent has to remember what "that one" refers to.

Best practice: use a dedicated booking-intent classifier rather than relying on the model's general understanding. This can be a simple prompt-based classification or a fine-tuned model, but it should explicitly output a structured booking intent object with all required fields.

Stage 2: Inventory Query

This is where real-time data becomes non-negotiable. Hotel inventory is dynamic — prices change by the minute, rooms sell out, cancellation policies vary by rate plan. If your AI agent is using cached data or scraped prices, it will inevitably recommend rooms that aren't actually available at the stated price.

The solution is a direct connection to live inventory through a standardized interface. This is exactly what a hotel MCP server provides: a set of tools that query real-time hotel availability, pricing, and room details on demand. The model calls the tool, gets fresh data, and presents it to the user. No caching, no scraping, no staleness.

A typical inventory query returns structured data including:

Hotel name and location
Available room types with descriptions
Nightly rates and total price
Cancellation policies
Amenities and guest ratings

The key design principle: the model should never generate hotel data. It should only present data returned from the tool call. This eliminates hallucination at the inventory stage.

Stage 3: Price Confirmation

Here's where things get tricky. Between the time the user sees a price and the time they decide to book, that price may have changed. A room that was $129 when displayed might be $149 thirty seconds later during a peak booking window.

A robust system implements a price-confirmation step: before asking the user to confirm the booking, the agent re-queries the exact room and rate plan to get the current live price. This re-queried price is what the user sees on the confirmation screen, and it's the price that gets locked for the order.

This step adds one extra tool call, but it prevents the single most common complaint about AI booking: "it quoted me one price and charged me another."

Stage 4: Order Creation

Once the user confirms the price, the agent creates an order. This involves collecting traveler details (names, contact info, special requests), selecting a rate plan, and submitting the booking request to the inventory system.

The order creation step must be idempotent. If the user clicks "confirm" twice, or if the network drops and the agent retries, the system must not create duplicate bookings. This is handled through idempotency keys — unique identifiers attached to each booking request that the server uses to detect and reject duplicates.

Order creation is also where business rules get enforced: minimum stay requirements, blackout dates, age restrictions, corporate rate eligibility. These rules live in the inventory system, not in the AI model, which means the model doesn't need to know about them — it just submits the request and handles the response (success or specific error).

Stage 5: Payment Authorization

This is the highest-stakes stage. Payment requires handling sensitive financial data, which means PCI compliance, tokenization, and secure transmission. The AI agent should never see or handle raw credit card numbers.

The standard approach is tokenized payment: the user enters their card details in a secure payment form (hosted by the payment processor), the processor returns a payment token, and the agent passes that token to the booking system. The token is useless outside the specific transaction context, so even if it's intercepted, it can't be used for fraudulent charges.

For AI agents, payment authorization is typically triggered through a tool call: the agent calls a "create payment" tool with the order ID and payment token, the tool communicates with the payment processor and the booking system, and returns a success or failure response. The agent never touches the financial details.

Stage 6: Confirmation Callback

After payment is authorized and the booking is confirmed, the system needs to deliver a confirmation to the user. This includes a booking reference number, hotel confirmation details, cancellation policy, and a receipt.

In an AI agent context, this confirmation can be delivered conversationally ("Your booking is confirmed! Reference number is HTL-2026-78451. Check-in is October 12 at 3 PM.") alongside a structured confirmation document (email or in-app receipt).

The confirmation callback is also where error handling matters most. If payment succeeds but the booking confirmation fails (a rare but possible scenario), the system needs a reconciliation process to either complete the booking or reverse the payment. This is why asynchronous confirmation callbacks with retry logic are essential.

How MCP Simplifies the Entire Stack

Now here's the good news: you don't need to build all six stages from scratch. A well-designed hotel MCP server encapsulates stages 2 through 6 into a set of standardized tools that any AI agent can call. The model doesn't need to know how inventory systems work, how payment processing works, or how to handle idempotency — it just needs to know which tool to call and what parameters to pass.

Here's what the tool flow looks like with an MCP-based hotel booking system:

User expresses booking intent → model calls search_hotels tool
User selects a hotel → model calls get_room_details tool
User confirms selection → model calls check_live_price tool (price confirmation)
User provides traveler details → model calls create_booking tool (with idempotency key)
User authorizes payment → model calls process_payment tool (with payment token)
System returns confirmation → model presents it to the user

Each tool call is a standard MCP invocation. The model discovers the tools automatically when the MCP server is connected. The developer doesn't write API integration code, doesn't handle authentication for each endpoint, and doesn't maintain separate SDKs for different inventory providers.

Connecting a hotel MCP server to your agent is a configuration change, not a development project. Here's what the configuration looks like:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Add this block to your MCP-compatible client's configuration, restart, and the hotel booking tools become available. No SDK to install, no local server to run, no API documentation to parse. The tools are self-describing — the model reads their JSON schemas and understands how to call them.

If you're building a custom agent rather than using an off-the-shelf client, the same configuration works with any MCP-compatible runtime. The protocol handles tool discovery, invocation, and response parsing, so you can focus on your agent's conversational logic rather than infrastructure plumbing. For a step-by-step setup guide that takes about five minutes, the official quick-start documentation covers every major client: https://global.rollinggo.store/docs/mcp-docs/quick-start/.

Designing for Trust: The Human-in-the-Loop Question

One question comes up every time I talk about AI booking: should the agent be able to complete a booking without explicit human confirmation?

My answer, based on talking to dozens of developers and users, is that it depends on the transaction value and the user's trust level. For a $150 hotel booking, most users want a confirmation step — they want to see the final price, the cancellation policy, and the booking details before authorizing payment. For a $15 airport shuttle, many users are comfortable with fully autonomous booking.

The key is that the agent should always make the transaction state visible. Even in autonomous mode, the agent should report what it's doing: "I found a room for $150, confirming the price now... price confirmed at $150, creating booking... booking created, processing payment... payment confirmed, reference HTL-2026-78451." This transparency builds trust and allows the user to interrupt if something looks wrong.

For higher-value transactions, implement a multi-factor confirmation: the agent presents the booking summary, the user explicitly approves, and then the agent proceeds with payment. This is the pattern used by most successful AI commerce products, and it strikes the right balance between convenience and control.

The Economics of Closing the Last Mile

Here's a number worth thinking about: the average conversion rate from hotel search to booking on traditional OTAs is about 3–5%. That means 95% of people who search for hotels don't book — and a significant portion of that drop-off happens because the booking process is too many steps, too many page loads, too many form fields.

An AI agent that can complete a booking in a single conversation has the potential to dramatically improve that conversion rate. Instead of search → filter → compare → select → enter details → payment → confirmation (seven steps), the user has one conversation: "I want to stay in Lisbon next weekend, near the water, under $150." The agent searches, presents options, confirms the selection, collects details, and processes payment — all in the same thread.

This isn't speculative. Agents connected to hotel MCP servers are already handling real bookings. The infrastructure exists. The tools are standardized. The remaining work is product design: making the conversation flow natural, making the confirmation step reassuring, and making the error handling graceful.

What to Build Next

If you're an AI developer who wants to close the booking gap, here's a practical starting point:
1. Connect a hotel MCP server to your agent. This takes minutes and gives you real-time inventory, pricing, and booking tools.
2. Implement the six-stage flow. Start with search and price confirmation, then add order creation, then payment. Don't try to build everything at once.
3. Add idempotency from day one. Duplicate bookings are the fastest way to lose user trust.
4. Design the confirmation experience. The booking isn't complete until the user has a reference number and a clear understanding of what they booked.
5. Test with real users. Watch where they hesitate, where they ask for clarification, and where they abandon. Those are your product opportunities.

The gap between "can recommend" and "can book" is the most valuable real estate in AI travel right now. The agents that close it won't just be better travel assistants — they'll be the first generation of AI products that genuinely handle money and responsibility on behalf of their users. That's not a small incremental improvement. That's a fundamentally different category of software.

And it starts with one configuration block.

KAYAK and Amex GBT Are Building MCPs—Corporate Travel Booking Is About to Change

Becky_dev — Wed, 07 Oct 2026 08:30:00 +0000

If you still think "AI booking corporate travel" is a PowerPoint concept, look at this list of names from 2026: KAYAK launched an Agent-to-Agent connector, Amex GBT (one of the world's largest TMCs) integrated Claude, and Hellō launched its ride-hailing as an MCP.

Corporate travel—supposedly the most traditional, process-heavy enterprise service—is being rebuilt from the roots by MCP. This isn't a few vendors' product moves; it's an industry-level paradigm shift—from "humans operate on the system" to "AI completes bookings on behalf of humans."

This article breaks down the giants' playbook logic and what the shift means for you.

1. What the Giants Are Doing: Three Samples

KAYAK: Agent-to-Agent connector. As a top global travel search engine, KAYAK is moving most aggressively—it's not just providing an MCP Server for AI to query and compare prices, but building inter-Agent connections: your AI assistant and KAYAK's AI Agent talk directly, with search, comparison, and recommendation completed end-to-end Agent-to-Agent. The user sees results; the multi-turn interaction in between is entirely swallowed by Agents.

Amex GBT: integrated with Claude. The TMC giant's logic is different—its core assets are corporate negotiated rates, compliance rules, and settlement systems. After integrating Claude, corporate employees can complete "policy-compliant" flight and hotel bookings directly in conversation: AI automatically validates budget standards, matches negotiated hotels, and generates compliant itineraries. Compliance can finally be moved to the instant of booking, instead of being discovered when an expense report comes back over limit.

Hellō ride-hailing: launched as an MCP. A sample from the Chinese market: they turned ride-hailing search and ordering into an MCP Server callable by any Agent. Mobility capability shifts from "an app's proprietary feature" to "a protocol-layer public capability."

All three samples point to the same conclusion: every link in the corporate travel chain is being MCP-ified, and it starts with the giants.

2. Why Corporate Travel Is the Perfect MCP Scenario

Corporate travel booking is almost a textbook MCP scenario—all four conditions hold:

High-frequency necessity: travel is a continuous need of enterprise operations, not a one-off action;
Strong rules: travel policy, budget standards, approval flows—all structured rules that AI can execute strictly, even more thoroughly than humans (humans bend, rule engines don't);
Standardized data: flights, hotels, itineraries—clear parameters, stable structure;
Transaction loop: search → book → pay → ticket, the whole chain can be automated.

"Strong rules" especially deserves a deeper look: travel is one of the few scenarios where the rules themselves are the product. Under the traditional model, rules are enforced by "post-hoc audit"—employees book over-limit, finance rejects, they rebook, and both sides are drained by the round trip. Under the AI Agent model, rules are pre-positioned—over-policy options never show up in recommendations. What's saved isn't just headcount, it's the entire rework loop.

3. From "Human Operation" to "AI Autonomous Booking": The Transitional Forms

Fully autonomous travel AI still needs time, but transitional forms are already running. A typical chain:

Employee: Business trip to Hangzhou next Monday, please arrange it
  ↓
Agent: Reads travel policy → searches negotiated hotels → matches budget standards
  ↓
Agent: Presents 3 policy-compliant options (with price, distance, cancellation policy)
  ↓
Employee: Pick #2
  ↓
Agent: Calls hotel MCP to place order → pays (corporate payment rail) → itinerary auto-synced

Giants' moves covered—now look at a player already at the table. Let's read its hand.

Positioning first. RollingGo is a dual hotel+flight MCP Server: it packages global hotel inventory and flight capabilities into a standard MCP-tool "travel data layer"—2M+ global hotels, 110k direct-contracted hotels with real-time inventory, aggregating availability and rates from 500+ suppliers. When a model calls it, what it gets back isn't a pile of web pages needing secondary scraping, but structured, bookable results. The key is free with no call-volume limits—something uniquely rare in China's MCP ecosystem.

In this chain, human involvement is compressed to the instant of "choosing." And the infrastructure is already in place—take the hotel link: a hotel+flight dual MCP like RollingGo already covers 2M+ global hotels (110k direct-contracted, real-time inventory), 500+ suppliers, works with 40+ mainstream AI clients, and a single Server has been integrated by 2,000+ Agents, with thousands of developers requesting keys to embed in their own travel, cultural-tourism, and assistant products. Want to build your own? Request a free key: https://global.rollinggo.store/.

How to connect. Streamable-HTTP direct—no dependencies, no local process. Just add a JSON block to your client's MCP config (using RollingGo-Hotel as the example):

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Swap YOUR_API_KEY for a free key from the official site, save and restart, and your model's tool list now includes the full suite of hotel search, pricing, details, and booking—from query to reservation, zero glue code.

Where it plugs in. The universality of this configuration is MCP's universality: Claude Code, Cursor, Windsurf, GitHub Copilot, Antigravity, Kiro, Codex, OpenCode, Trae, Manus, Qoder—every major coding client is covered; Coze, Cherry Studio and other Agent platforms have custom MCP entries where the same JSON works. Same Server, same JSON, same set of tools wherever you run it.

Traction. The open-source MCP implementation and accompanying travel skill on GitHub are approaching 300 stars; the ModelScope-hosted version has logged 1.6M cumulative calls and hit #7 on the trending list.

4. After the Shift: Who Loses, Who Wins

Losers are easy to guess:

Middlemen surviving on information asymmetry—pure reseller agencies, service providers whose "value-add" is manual price comparison; their value goes to zero when AI cuts them out;
Closed old systems—data can't get out, interfaces aren't standard; AI can't help even if it wants to.

Winners:

Platforms that hold supply—the KAYAKs, hotel aggregators; every Agent is a new distribution channel, and channel count goes from "a few OTAs" to an unbounded number of Agents;
Enterprises themselves—lower travel management cost, higher compliance, better employee experience (nobody likes filling expense forms);
Developers—the startup barrier in the vertical of corporate travel has been smashed: one person + a ready-made MCP stack can build an enterprise travel tool that used to require a whole team.

5. Action Advice for Enterprises

Don't rush to cut the travel management team; first inventory your rules: travel policy, negotiated rates, approval flows—can these rules be structured? If yes, you have the fuel for AI-ification;
Start with "compliance pre-positioning": have AI filter over-limit options at the recommendation stage—this step shows results fastest without restructuring your process;
Keep channels open: prioritize suppliers with MCP capability—one more protocol-layer interface today means one less supplier hostage tomorrow.

Corporate travel booking's "paradigm shift" isn't a question of if—it's a question of how fast. The giants have already drawn the blueprint; all that's left is diffusion speed.

Appendix: 18-Month Timeline Forecast for Corporate Travel MCP-ification

Extrapolating from current trends, the evolution cadence in corporate travel is likely:

H2 2026: Query-Side Full MCP-ification

Real-time availability, pricing, and policy queries become standard capabilities of travel systems, and Agent price-comparison becomes a standard procurement move. Early adopters begin piloting "compliance pre-positioned" recommendation filtering.

H1 2027: Corporate Payment Rails Light Up

AI ordering shifts from "individual pays then gets reimbursed" to "direct corporate payment," and voucher automation lands at top TMCs—expense flows start moving from "after the fact" to "in the moment."

H2 2027: Inter-Agent Protocol Layer Emerges

Supplier Agents and enterprise Agents talk directly to match negotiated rates and run approval flows; the KAYAK-style Agent-to-Agent model moves from experiment to commercial.

There's a simple litmus test for whether these forecasts hold: watch whether interface-open speed outpaces business-negotiation speed. If the former wins, the trend materializes; if the latter wins, the timeline slips by a year.

Is your company's corporate travel still on manual approval? Which step in the process makes you cringe the most? Share in the comments—I'll see where the most pain is.

A Step-by-Step Framework: Should Your Product Build an MCP?

Becky_dev — Tue, 06 Oct 2026 08:30:00 +0000

By 2026, almost every SaaS product team has been asked the same question: "Should we build an MCP?"

The boss saw MCP in tech news, the investor saw MCP in the BP, the competitor's website has a "MCP-ready" badge. So the tech lead pulls an all-nighter to evaluate, and it usually ends one of two ways: either they rush out a Server nobody uses, or they miss the channel dividend they should have pocketed.

This article gives a decision framework you can copy directly, with a self-check checklist at the end.

First, Be Clear: What Is MCP-ification, at Its Core?

Don't be intimidated by the protocol's complexity. Product MCP-ification, at its core, is one sentence: turn your product's capabilities into "functions AI can call directly."

Whether this is valuable depends on a plain condition: does your capability have a scenario where "AI calling it" makes sense? If yes, MCP is your new distribution channel—suddenly your product is live in every AI client overnight. If no, MCP is an expensive business card.

So the framework revolves around three questions.

Question 1: Is Your Capability a "High-Frequency Query"?

MCP's sweet spot is high-frequency, read-only or light-write query-type capabilities: check inventory, check prices, check status, check data.

The litmus: how many times a week does your user open your product just to "look up a number"? If the answer is "a lot," those queries should be MCP-ified—letting the user get the result in one sentence in an AI chat is 10× better UX than opening your app and tapping through five layers of menu.

Counterexample: a once-a-year heavy configuration flow (like annual audit settings) makes no sense to MCP-ify—the cost of one AI call is higher than a human click.

Look at the real-world proof: the hotel industry is one of the most aggressive MCP-ification verticals, because "checking availability and prices" is a natural high-frequency query—a single hotel MCP has been integrated by 2,000+ Agents, with local cultural tourism bureaus, AI earbuds, AI glasses, and trip-planning apps all calling it. If your product has a similar "high-frequency data exit," the logic is fully isomorphic.

Question 2: Is Your Data "Standardized"?

MCP suits highly standardized data: clear structure, unambiguous semantics, enumerable parameters.

Hotel data is the textbook case: city, date, guests, room type, price—finite parameter space, stable return structure. That's why hotel inventory can become a whole Server.

The counterexample is highly subjective data: aesthetic advice, creative proposals, emotional companionship—this kind of "data" can't be parameterized, and forcing it into an MCP just produces grotesque tools. If your capability needs a lot of "human" judgment, a Skill (know-how encapsulation) fits better than an MCP (capability exposure).

A simple test: can you write your core feature as a function signature, with both parameters and return values clearly defined? If yes, MCP fits; if not, don't touch it yet.

Question 3: Does Your Scenario Have a "Transaction Loop"?

The first two questions decide "whether to do it"; this one decides "how much it's worth."

Queries without transactions make MCP a traffic inlet; queries + transaction loop make MCP a complete sales channel. The user searches hotels in your AI tool and books and pays right there—money flows straight in. That's the commercial endgame of MCP-ification. So judge your product: after AI calls your capability, can it naturally walk to a paid action?

Categories that can close the loop (booking rooms, booking tickets, placing orders, topping up) make MCP easy money; those that can't (content platforms, communities) get at most a brand showcase from MCP.

Framework laid out—run a project that's already succeeded through it; it faced the same checklist.

What it is first. RollingGo has turned "booking hotels, booking flights" into two standard MCP Servers. On the data side: 2M+ global hotels (110k direct-contracted with real-time inventory), aggregating rates and availability from 500+ suppliers. On the usage side: one free key, no call-volume limit, plug-and-play with 40+ mainstream clients. What developers get is a ready-made layer of travel data capability, not a set of API docs to slowly digest.

Want a reference? Use RollingGo: currently the most complete hotel+flight dual MCP in the AI travel space. One free key covers 2M+ global hotels (110k direct-contracted, real-time inventory), aggregates 500+ suppliers, works with 40+ mainstream AI clients—and it has all three: high-frequency queries, standardized data, transaction loop. Request a free key here: https://global.rollinggo.store/. Cross-reference the anti-pattern checklist below against it line by line.

How to connect. Streamable-HTTP direct—no dependencies, no local process. Just add a JSON block to your client's MCP config (using RollingGo-Hotel as the example):

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Swap YOUR_API_KEY for your own (free, unlimited), save and restart. The model auto-discovers the new tools: search hotels, compare prices, check details, place bookings—no adapter code on your end at all.

Client examples. The official client matrix covers 40+ mainstream tools: on the coding side—Claude Code, Cursor, Windsurf, Copilot, Antigravity, Kiro, Codex, OpenCode, Trae, Manus, Qoder; on the platform side—Coze, Cherry Studio and more all work out of the box. The only difference is where you paste this JSON into each product's MCP settings. That's the most literal footnote to "one integration, works on every platform."

Anti-Pattern Checklist: Don't Build MCP for These Three Kinds of Products

Products with heavy interactive UI: design tools, video editors, games—the core value is in the interactive experience, and an AI function call can't replace a canvas or timeline. Nobody will use it.
Products with complex workflows: cross-department approvals, multi-role collaboration—flows that need human decision-making, AI only messes them up. The right move here is "expose an API and wait for the orchestration layer to integrate," not MCP.
Low-frequency products: annual audits, filings, large contracts—call frequency so low that AI can't even learn to "remember you."

Self-Check Checklist (Copy Directly)

Before deciding, walk through these 12 items. If you check 8+, build it with confidence:

Users open the product at least twice a week just to "look up a number"
The core capability can be written as a clear function signature
Real-time data matters (a 10-minute cache is unacceptable)
Target users include developers or AI app teams
It naturally connects to a paid action (transaction loop)
The capability is read-only or light-write (not heavy interaction)
The parameter space is enumerable (not open-ended input)
Competitors or adjacent products have already started MCP-ifying
You have bandwidth to maintain (docs, error handling, updates)
You expect new customers from AI channels (not just serving existing ones)
The data source is stable (no frequent schema changes)
Per-call cost is controllable (can be metered per call or free)

Can't clear 8? Spend your energy on the product itself; MCP can wait for the next wave.

If you want a reference: look at what a validated MCP Server looks like—like RollingGo in hotel aggregation, which has all three: high-frequency queries, standardized data, transaction loop. Walk the checklist above against it and your product side by side, and the judgment gets much clearer.

Appendix: Turn the Checklist into a Scorecard

A checklist used only for ticking boxes tends to overestimate yourself. The advanced use is weighted scoring:

High-frequency query (weight ×3): this is the trunk of MCP-ification upside; one item counts as three;
Transaction loop (weight ×3): decides whether you're building an "inlet" or a "business card";
Data standardization (weight ×2): decides development cost; capabilities that can't be parameterized make MCP a self-inflicted headache;
The remaining seven items (weight ×1): tiebreakers—they decide priority, not feasibility.

Compute your weighted score: 24+—schedule it immediately; 15–24—build a weekend-scale MVP to validate the core scenario; under 15—archive this evaluation and revisit when the business shifts. Note "archive," not "give up"—a product's MCP fit changes with business shape, and reviewing once a year is a low-cost habit.

One more reverse suggestion: if the score is high but you keep stalling, the problem probably isn't technical—it's that nobody owns this "new channel." MCP-ification is essentially channel building, not feature development. Put it in channel/growth OKRs, not the product iteration list, and the pace changes completely.

An Easy-to-Miscalculate Time Factor

There's a hidden variable in the scorecard worth pulling out separately: the entry window. The MCP ecosystem is currently in an "early standardization dividend period"—the protocol is unified but competitive structure isn't settled. Teams that enter early enjoy cross-platform traffic pilots; teams that enter late fight for position against mature players. This isn't "hurry-up anxiety" marketing copy—it's the universal pattern of platform shifts: in the app wave, launching in 2010 vs. 2015 meant an order of magnitude difference in customer acquisition cost. So teams in the 15–24 score range should compress MVP validation into two weeks—scores change, windows change, and only validation is an irreversible asset.

Does your product fit MCP? Tell us which item you're stuck on in the comments—I'll help you judge.

After 10,000 MCP Servers: Ecosystem Boom or Fragmentation?

Becky_dev — Mon, 05 Oct 2026 08:30:00 +0000

10,000 MCP Servers: Is the Ecosystem Heading Toward Prosperity or Fragmentation?

In early 2026, the MCP ecosystem crossed a landmark: active MCP Servers topped 10,000, with monthly SDK downloads reaching 97 million.

A year ago that number was still in the three digits. From "a protocol open-sourced by Anthropic" to "a 10,000-strong ecosystem" took roughly a year and a half.

But the flip side of numerical prosperity is what every developer who's actually used the MCP marketplace feels: good Servers are drowning in a sea of garbage. Search "hotel" and you get 40 Servers—half are demo-grade, some are reskinned wrappers, and a few have machine-translated descriptions.

So the question is: after 10,000 Servers, is the MCP ecosystem heading toward prosperity or fragmentation? This piece breaks it down from data, problems, and mechanisms, and talks about where the developer window of opportunity is.

1. Ecosystem Data: The Prosperity Is Real

First, the good side—three trends are genuinely solid:

Quantity metric: 10,000+ active Servers covering databases, search, payments, travel, office, ops—nearly every category;
Consumption metric: 97M monthly SDK downloads—this isn't signups, it's actual usage, meaning "using MCP" has become a default developer action, not a novelty;
Quality head: de facto standards are emerging in verticals—for example, in hotel aggregation, RollingGo has logged 1.6M+ calls on its ModelScope hosted service and reached #7 on the trending list. The head effect means users are voting with their feet.

2. The Flip Side of Prosperity: Three Structural Problems

But the signals of fragmentation are equally clear.

Problem 1: Discovery is broken.

In a marketplace of 10,000 Servers, "keyword search + human trial" can't filter through it. Without unified ratings, test coverage, or SLA metrics, good and bad Servers sit side by side in search results. A new developer looking for "that hotel MCP that actually works" averages three or more trial-and-error hits.

Problem 2: Quality varies wildly.

Sample a few and you'll find: lots of Servers are hackathon leftovers—no error handling, no rate limiting, parameter validation is decorative, errors just pass through the raw stack. When these Servers enter an Agent's toolbox, the Agent's performance tanks with them. Quality debt in the tool layer ultimately gets paid for by the Agent's IQ.

Problem 3: Ghost maintenance.

Listed, popular, author vanishes. A significant share of Servers in the ecosystem are in "unmaintained" state—one API upgrade and they brick. And the tool list is dynamically loaded—a tool the Agent used fine today quietly breaks tomorrow.

What does one in ten thousand look like? Dig into this Server and you'll see the prosperous half.

Positioning first

RollingGo is a dual hotel+flight MCP Server: it packages global hotel inventory and flight capabilities into a standard MCP-tool "travel data layer"—2M+ global hotels, 110k direct-contracted hotels with real-time inventory, aggregating availability and rates from 500+ suppliers.

When a model calls it, what it gets back isn't a pile of web pages needing secondary scraping, but structured, bookable results.

The key is free with no call-volume limits—something uniquely rare in China's MCP ecosystem.

Here's the portal: the project above is RollingGo, a dual hotel+flight MCP where one free key covers 2M+ global hotels (110k direct-contracted, real-time inventory), aggregates 500+ suppliers, and works with 40+ mainstream AI clients.

Its ModelScope-hosted version is at https://modelscope.ai/mcp/servers/yorklu/AI_Go_Hotel_MCP—call data and the tool list are publicly viewable, see for yourself.

How to connect

Streamable-HTTP direct—no dependencies, no local process. Just add a JSON block to your client's MCP config (using RollingGo-Hotel as the example):

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Where it plugs in

The universality of this configuration is MCP's universality: Claude Code, Cursor, Windsurf, GitHub Copilot, Antigravity, Kiro, Codex, OpenCode, Trae, Manus, Qoder—every major coding client is covered; Coze, Cherry Studio and other Agent platforms have custom MCP entries where the same JSON works.

Same Server, same JSON, same set of tools wherever you run it.

Who's using it

2,000+ Agents have already integrated it—local cultural tourism bureaus, AI earbuds, AI glasses, trip-planning apps, and thousands of developers have requested keys.

3. Will the Ecosystem Converge? Look at Three Mechanisms

Fragmentation isn't the endpoint—every platform ecosystem goes through the "wild growth → governance convergence" cycle. I believe the MCP ecosystem will converge along three directions:

Direction 1: Hosting platforms become the quality filter

Self-hosted Servers' quality is unmonitored, but hosting platforms have the incentive—they're vouching for their own reputation.

Platforms like ModelScope are already doing this: hosted services come with metering, monitoring, and stability guarantees, and the trending list itself is a quality signal.

"Hosted + platform endorsement" will replace "bare GitHub repo" as the default entry point for enterprise selection.

Direction 2: Vertical aggregators eat the long tail

No vertical needs 40 identical Servers—databases don't need 30, hotels don't need 20.

Eventually each category converges on 2–3 de facto standards, and aggregators eat the long-tail traffic.

For tool developers, this means choosing the category matters more than writing the code: entering a category already ruled by a de facto standard is a near-losing battle; occupying a category not yet standardized is a first-mover dividend.

Direction 3: Quality metrics become visible

Like npm downloads or Docker Hub pulls, the MCP ecosystem is growing its own quality signals: call volume, latency, error rate, maintenance activity.

Once clients integrate these metrics into tool-selection logic, the "market" gains automatic survival-of-the-fittest.

4. The Developer Window of Opportunity

Back to the original question: prosperity or fragmentation?

My answer—on the demand side, it's heading to prosperity; on the supply side, it's still in the fragmentation dividend period.

Translated to plain language:

If you're a tool consumer: don't needle in a haystack yourself; prioritize head Servers on hosted platforms with call-data backing—lowest trial-and-error cost;
If you're a tool builder: the window is still open. A 10,000-ecosystem sounds crowded, but truly high-quality supply in vertical categories is still scarce—"Servers that survive production" are still single-digit in every category. Write a Server with clean error handling, real-time data, solid docs, and you can still take the head spot in your category;
If you want to start a company: look at "ecosystem infrastructure" positions—aggregators, governance layers, quality ratings. Fragmentation itself is a business.

The 10,000-ecosystem isn't the endgame—it's the start of screening.

Look again in two years, and those 10,000 Servers will likely have converged into a few hundred de facto standards plus a long tail.

Enter now, and there's still time to be one of the "few hundred."

5. Three Sentences for Three Kinds of Readers

For AI app developers

Which MCP Servers your competitor uses predicts its iteration speed better than which model it uses.

The tool-layer information gap is the biggest one right now—spend more time browsing hosted-platform trending lists, less time fretting over model leaderboards.

For MCP Server authors

In a 10,000-ecosystem, "being discovered" and "being trusted" matter more than "feature-complete."

Prioritize three things:

An error response an Agent can understand;
A credible call-volume proof;
A steady maintenance cadence.

Those three are the entirety of what buyers base decisions on.

For investors and founders

Don't bet on "which Server wins," bet on "which layer wins."

Historical pattern: the protocol layer winner-takes-most (already settled), the aggregation layer has a few oligopolies (positioning now), long-tail Servers eat vertical-scenario margins (window still open).

When evaluating a project, ask first: which layer are you on, and why.

The 10,000 number will keep growing, but ecosystem value was never determined by quantity—it's determined by how fast the screening mechanism matures.

Do you think aggregation platforms will emerge in the MCP ecosystem? Who will it be—hosting platforms, model vendors, or new entrants? Share your call in the comments.