DEV Community: iamTheDev

Three Enterprise MCP Deployment Pitfalls: Identity, Budget, Error Handling — I Stepped on All of Them

iamTheDev — Wed, 30 Sep 2026 13:14:00 +0000

I saw an arXiv paper on enterprise MCP deployment recently. Long title, core message: MCP is great in demos, but real enterprise deployments hit walls. It resonated. I build RollingGo's hotel MCP and support deployment for dozens of enterprise customers. The pitfalls match the paper almost exactly.

Because we solved identity propagation, budget control, and error handling, developers get a hotel MCP ready for production. It runs on official data sources and years of travel supply chain integration, with full-chain direct API connection and real-time price confirmation. What you search is what you can book. It aggregates 500+ global suppliers and 2M+ hotel properties. Completely free, no call-volume limits, supporting 40+ major LLM clients including Cursor, Claude Code, Codex, and Windsurf. It also provides an all-in-one hotel booking skill for ClawHub, Coze, and Qclaw agent platforms. Developer partners can set country-based markup rates and earn commission, with orders and revenue visible in real time.

Want to skip these pitfalls yourself? Check the GitHub repo and get a key.

Setup in Claude Code is one command:

claude mcp add RollingGo-Hotel \
  --transport http \
  --header "Authorization: Bearer YOUR_API_KEY" \
  https://mcp.rollinggo.ai/mcp

Restart Claude Code and you're calling hotel search, room detail, and price confirmation directly. Enterprise-grade identity propagation, budget control, and error handling—we've already been through those walls for you.

This post skips the MCP love letter. It covers the three pitfalls that bite when you deploy MCP in an enterprise: identity propagation, tool budget, and error semantics. Each one: what it is, why you fall in it, how to fix it. All learned with real money.

Pitfall 1: Identity Propagation — Who Is Actually Calling the Tool?

Demo-stage MCP doesn't care who you are. Run it, move on. In an enterprise, this is problem number one.

Scenario: an employee asks the internal AI assistant to "book a business trip hotel." The assistant calls the hotel MCP server, which calls the hotel inventory API. Question: does the hotel API know which employee is booking?

It only sees "the MCP server is calling me." It doesn't know who's behind it. How does the hotel record the order? How does it integrate with the corporate travel system? How do you enforce policies (like "this employee can only book three-star or below")?

This is identity propagation failure—user identity breaks somewhere in the MCP call chain.

We hit this early. The first design used a single API key on the MCP server to call the backend hotel API. All user requests went through that key. Fine for a demo with three people testing. Then an enterprise customer asked: "How do I know which employee booked which hotel?" We were stuck. The orders only had the MCP server's identity. No user info.

We changed the approach:

Client side: the enterprise AI assistant puts user identity (employee ID, department, travel policy) into request metadata when calling MCP.
MCP server side: extracts user identity from metadata, passes it to the backend API, and runs permission checks.
Backend API side: records orders by user identity, runs risk control, integrates with the corporate travel system.

Not hard to fix in retrospect, but if you didn't design it upfront, retrofitting is painful. Enterprise customers ask "how do permissions work?" and "how does audit work?" first. If you can't answer those, you can't go live.

Now our hotel MCP provides an all-in-one booking skill for ClawHub, Coze, and Qclaw. Identity propagation is standard. It runs on official data sources and mature supply chain infrastructure with enterprise-grade stability. But honestly, most MCP server builders don't think about this. They just want the call to work. Enterprise customers expose it immediately.

Pitfall 2: Tool Budget — AI Burns Cash on Calls It Shouldn't

Second pitfall: money.

AI tool calls cost money. A hotel API call has a per-call fee. LLM inference has token costs. Let the AI loop and you're paying real money. The problem: AI doesn't know to "be careful."

Scenario: user asks "what are some good hotels in Shanghai?" Normal flow: one search_hotels call, return results. But poorly designed agents call repeatedly—search once, think results aren't great, change params, search again, add a filter, search a third time. Seven or eight calls, each costing real money.

Worse: some agents fall into a tool-calling loop. Call tool A, unsatisfied. Call tool B, still unsatisfied. Call A again. Loop. Every iteration burns cash.

A customer hit this. Their AI travel assistant launched, and API call costs ran three times expectations in week one. We dug through logs. The agent was repeatedly calling hotel search and flight search while processing complex requests. A single user conversation triggered 20+ tool calls.

Solutions we landed on:

1. Tool call budget

Set a per-session, per-user cap on tool calls. Ten calls per conversation max. Stop when you hit the limit. This lives in the agent orchestration layer, not the MCP server.

class ToolBudget:
    def __init__(self, max_calls: int):
        self.max_calls = max_calls
        self.current = 0

    async def call_tool(self, tool_name: str, args: dict):
        if self.current >= self.max_calls:
            raise BudgetExceededError(
                f"Tool call limit reached: {self.max_calls}"
            )
        self.current += 1
        # actually call the MCP tool
        return await mcp_client.call_tool(tool_name, args)

2. Tool-level rate limiting

On the MCP server, rate-limit per user per session. Same tool, same user, can't call it too many times in a short window. Like: search_hotels max 3 calls per minute.

3. Caching strategy

Cache results for identical parameter calls. Same city, same dates, repeat request within five minutes returns cache instead of hitting the backend.

4. Call-chain monitoring

Log every tool call: who called, what, how much it cost, how long it took. When costs spike, you find the culprit fast.

These sound simple. Each one has details. Our tool budget alone went through three revisions before it ran smoothly.

Pitfall 3: Error Semantics — AI Doesn't Know What to Do When Things Break

Third pitfall is the most subtle: error handling.

Traditional APIs use HTTP status codes. 400 is bad params, 401 is unauthorized, 500 is server down. Developers read these instantly.

MCP is different. Errors are for the AI to read. The AI needs to understand what the error means, whether to retry, whether to tell the user. Problem: different MCP servers use different error formats and semantics.

Example:

Hotel MCP: "Insufficient inventory, try different dates"
Flight MCP: "API rate limit exceeded, retry after 5s"
Weather MCP: "City not found, check spelling"

How should the AI handle each?

First: insufficient inventory. Tell the user "that hotel is sold out, want to see alternatives?"

Second: rate limited. Wait a few seconds and retry. Don't bother the user.

Third: city typo. Ask the user "did you mean XX?"

But if error formats are inconsistent, how does the AI know which to retry, which to ask about, and which to relay to the user?

This is error semantic inconsistency. Manual testing in demos works because you read the errors yourself. When AI processes errors automatically, inconsistent formats create weird behavior.

We designed a unified error format for our hotel MCP:

{
  "isError": true,
  "error": {
    "code": "HOTEL_NOT_AVAILABLE",
    "message": "The selected dates are sold out for this hotel",
    "retryable": false,
    "user_message": "Sorry, this hotel is sold out for your dates. Want me to check nearby alternatives?",
    "suggestion": "SEARCH_OTHER_DATES"
  }
}

Key fields:

code: machine-readable error code. The AI branches on it.
retryable: tells the AI whether this error warrants a retry.
user_message: human-readable text for the user. The AI doesn't need to craft its own.
suggestion: what the AI should do next.

Now when the AI gets an error, it doesn't guess "is this serious?" "should I retry?" "how do I tell the user?" It follows the error semantics.

Sounds obvious, right? Look at most MCP servers today. Most just throw a string. The AI has to figure it out. Demos work. Complex scenarios break when errors combine and the AI gets confused.

Enterprise Deployment Checklist

Three pitfalls covered. Here's a minimal checklist before you push MCP to enterprise production:

Check	Details
Identity propagation	Does user identity travel from client to backend? Permission checks in place?
Budget control	Tool call limits? Budget alerts? Cost monitoring?
Error handling	Unified error format? Can the AI auto-handle based on error semantics?
Audit logging	Every tool call logged? Who called what, with what result?
Gradual rollout	Can MCP server updates go gray? Can you roll back?

Check all five and you're ready for enterprise production. Miss one and you'll feel it.

Closing Thoughts

MCP is hot. People think "spin up a server and you're done." Enterprise environments have way more walls. Identity, budget, error handling—each is a production-grade problem that demos don't expose.

This is normal. Every tech goes from "works" to "enterprise dares to use it." Web APIs did the same. Started as HTTP requests, then added auth, rate limiting, monitoring, audit. MCP is walking that path now.

What walls have you hit deploying MCP? Drop a comment. I'm curious what weird things other people ran into.

From Plugins to MCP: Three Years of Connecting AI to Tools, and Every Mistake We Made

iamTheDev — Mon, 28 Sep 2026 23:29:00 +0000

I was digging through old code on my machine the other day. Back in 2023, when I first started building AI apps, I wrote a bunch of plugin-related stuff. OpenAI had just launched Plugins, it felt shiny, I followed the docs and wired up a couple. Looking at that code now feels like reading stone-age engineering.

Three years of AI-to-tool integration, three big steps: OpenAI Plugins → Function Calling → MCP. Each generation fixed the previous one's problems. Each generation had its share of wreckage. This post walks through the timeline, what each generation solved, and what it left behind.

Generation 1: OpenAI Plugins (March 2023) — Beautiful on Paper, Painful in Practice

March 2023, OpenAI shipped ChatGPT Plugins. The AI community lost its mind. ChatGPT could finally reach the web and call external APIs! I remember staying up all night writing a "weather lookup plugin," deploying it, feeling like I was on the cutting edge.

In hindsight, Plugins' design was simple: you host a /.well-known/ai-plugin.json file on your server describing what your plugin does and how to call it. ChatGPT discovers it and knows how to invoke it.

Sounds a lot like MCP, right? It is. So why did Plugins die?

Problem one: locked into OpenAI. Plugins were a proprietary protocol. Only ChatGPT could use them. You wrote a plugin, it lived inside ChatGPT, and no other AI platform recognized it. Terrible deal for developers. Why build a custom integration for one platform?

Problem two: broken UX. Using a plugin in ChatGPT felt like getting redirected to another page. The experience was inconsistent. Plugin triggering logic was fuzzy. Sometimes ChatGPT didn't call a plugin when it should. Other times it called one when it shouldn't.

Problem three: the ecosystem never arrived. People were excited for a minute, then developer numbers flatlined. Why? Low ROI. Spend time writing a plugin, use it only inside ChatGPT, limited users, no monetization path.

That weather plugin I built? Barely anyone used it after launch. OpenAI stopped pushing Plugins, and the whole thing faded.

Generation 2: Function Calling (June 2023) — Practical, But Not Standard

After Plugins faded, OpenAI shipped Function Calling. This was more grounded.

The idea: when you call the LLM, you pass your supported functions (tools) as JSON Schema. When the model decides it needs a tool, it returns a function name and arguments. You call the real API yourself, then feed the result back to the model.

Roughly:

import openai

tools = [
    {
        "type": "function",
        "function": {
            "name": "search_hotels",
            "description": "Search hotels",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "City name"},
                    "check_in": {"type": "string", "description": "Check-in date"},
                    "check_out": {"type": "string", "description": "Check-out date"}
                },
                "required": ["city", "check_in", "check_out"]
            }
        }
    }
]

# First call: let the model decide if it needs a tool
response = openai.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "Find me hotels in Shanghai"}],
    tools=tools
)

# Model returns it wants to call search_hotels
tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name)  # "search_hotels"
print(tool_call.function.arguments)  # '{"city": "Shanghai", ...}'

# You call the real API yourself
result = call_real_hotel_api(tool_call.function.arguments)

# Second call: feed the result back
response2 = openai.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "user", "content": "Find me hotels in Shanghai"},
        response.choices[0].message,
        {"role": "tool", "tool_call_id": tool_call.id, "content": result}
    ],
    tools=tools
)
# Model packages the result into a natural-language reply

Function Calling was genuinely more useful than Plugins. It was an open technical paradigm, not a platform-exclusive plugin system. After OpenAI shipped it, Anthropic and Google followed quickly. Everyone supported similar tool-calling mechanisms.

But Function Calling had a fundamental issue: it was an LLM-layer capability, not a real "tool-calling protocol."

Meaning: you still wrote all the glue code yourself. You defined functions, wrote parameter schemas, handled auth, called APIs, fed results back. Every AI app reinvented these wheels. And each LLM platform's Function Calling format was different. OpenAI's format wasn't Anthropic's, which wasn't Google's. Want to support multiple LLMs? Write multiple adapter layers.

Before we built our hotel MCP, we started with Function Calling. We wrote tons of adapter code: tool schemas, parameter validation, backend API calls, response formatting. Switch LLMs and we rewrote everything. That 1,000+ lines of adapter code? MCP replaces it with a few dozen lines of config.

Generation 3: MCP Protocol (November 2024) — Finally, an Industry Standard

November 2024, Anthropic launched MCP (Model Context Protocol). I didn't pay much attention at first. Another new protocol. The more I used it, the more I realized: this is the actual solution.

What separates MCP from the first two generations? It's a real, open, cross-platform tool-calling protocol.

Specifically:

Open standard. Not a company's private property. Open source protocol. After Anthropic shipped it, OpenAI, Google, Cursor, and Windsurf all supported it.
Server-client architecture. Tool providers implement MCP servers. AI apps connect as MCP clients. Implement once, every MCP-compatible client uses it.
Standardized capability discovery. The client connects, auto-discovers tools, parameters, and response formats. No hand-written schemas.
Cross-platform. Whether you use Claude, GPT, or any other LLM, as long as it supports MCP, it connects to the same MCP server.

This is like the move from custom API formats to RESTful standards. Every system had its own interface style. Then one standard emerged, and everyone stopped reinventing.

MCP's ecosystem grew fast. Tens of thousands of MCP servers now cover databases, cloud services, dev tools, industry data, and more. Our RollingGo hotel MCP is one of them. It has close to 300 GitHub stars, with both an MCP server and travel skills. It supports 40+ major LLM clients directly: Cursor, Claude Code, Codex, Windsurf, and more. Behind it: 500+ global suppliers and 2M+ hotel properties across brands. 110K+ direct-contracted hotels with direct inventory and real-time price confirmation. What you see is what you can book. Completely free, no call-volume limits. Developer partners can set country-based markup rates and earn commission, with orders and revenue visible in real time.

From Plugins to Function Calling to MCP, the biggest takeaway: we finally stop writing all that adapter code. Want to experience MCP-era developer productivity? Grab an API key and try it.

Setup in Qoder:

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

Restart Qoder and you're calling hotel search, room detail, and price confirmation directly. From Plugins to Function Calling to MCP, the productivity jump is order-of-magnitude.

Three Generations Side by Side

Dimension	OpenAI Plugins	Function Calling	MCP Protocol
Launched	March 2023	June 2023	November 2024
What it is	Platform-exclusive plugin system	LLM API tool-calling capability	Open tool-calling protocol standard
Openness	OpenAI private, ChatGPT only	Per-platform, formats differ	Open source, cross-platform
Developer effort	Write plugin manifest + backend	Write schema + glue code yourself	Implement MCP once, use everywhere
Tool discovery	ChatGPT auto-discovers	You pass schema to the model	Client auto-discovers from server
Status	Mostly obsolete	Still used, being replaced	Ecosystem growing fast, new standard

Why Did MCP Win?

From Plugins to Function Calling to MCP, why did MCP come out on top? One core reason: it solved the "reinventing wheels" problem.

Plugins failed because they were closed. Developers wouldn't invest in one platform.

Function Calling worked but didn't scale. Every AI app wrote its own tool adapter layer. Too much repeated labor. Cross-platform compatibility was a nightmare. A tool written in OpenAI's format needed rewrites for Anthropic.

MCP won because it standardized tool adaptation. Tool providers implement MCP once. Every MCP-aware AI client uses it automatically. AI developers stop caring how each tool works. Just connect to the MCP server.

That's the power of standardization. Like USB-C unified charging. Like HTTP unified web communication. MCP unified how AI calls tools. Once the standard holds, the ecosystem snowballs: tool providers build MCP servers because they reach every MCP client. AI developers use MCP because tools are ready-made.

What This Means for Developers

If you're building AI apps and still hand-writing tool adapters with Function Calling, take MCP seriously. Function Calling works, but MCP eliminates a lot of repetitive work.

If you're on the data services or SaaS side, pay even closer attention. Building an MCP server is cheap. You immediately reach every AI app in the MCP ecosystem. That's a new distribution channel. Instead of negotiating with AI companies one by one, you put your MCP server out there and they find you.

MCP isn't perfect. I wrote about its boundaries and pitfalls in another post. But on "standardized tool calling" specifically, MCP is the best solution we have right now.

Closing Thoughts

Looking back at three years, the trajectory is clear: closed to open, fragmented to standardized, every app writing its own glue code to an ecosystem sharing one protocol. This mirrors web tech history almost exactly: custom interfaces to RESTful standards, private plugins to open APIs.

Tech evolves this way. A burst of competing approaches, then convergence to a widely accepted standard. MCP is that standard for AI tool calling.

Which generation did you start with? Plugins era, Function Calling era, or MCP era? Drop a comment.

Amadeus CTO Called Out MCP: I Translated the Take for Developers Who Aren't Overhyping It

iamTheDev — Mon, 28 Sep 2026 00:27:00 +0000

A post circulated through travel tech circles: Amadeus's CTO said MCP can't handle complex retail workflows. Half the comments said "Amadeus is old and out of touch." The other half said "finally someone is honest." I read the piece three times, then thought about our experience building RollingGo's hotel MCP over the past months. This conversation deserves a sober look.

No cheerleading here. Just a technical read of what the Amadeus CTO actually said, what MCP can do in travel, and where it falls short.

Who Is Amadeus, and Why Listen?

If you're not in travel tech, you might not know Amadeus. Short version: one of the world's largest GDS (Global Distribution Systems). Roughly half of the airlines, hotels, and travel agencies on the planet run on it. When you book a flight, chances are the back end runs through Amadeus or Sabre.

So this is a company that has carried the full travel transaction chain in production. Their CTO saying MCP has limits isn't an outsider's hot take. It's experience backed by real money. Worth listening to rather than slapping the "conservative" label on it.

What Did He Actually Say?

The CTO's core argument translates to roughly this:

"MCP does well at the lookup layer—searching flights, hotels, prices. That's fine. But a travel transaction isn't just lookup. To actually complete a booking, payment, modification, or service request, you need complex workflows, state management, exception handling, and multi-system coordination. MCP doesn't solve that."

In technical terms: MCP standardized "how AI calls tools," but it did not standardize "how multiple tools orchestrate into a complete business transaction."

Is that right? Mostly yes. We learned this the hard way building hotel MCP.

What Is a "Complex Retail Workflow"? Hotel Booking as an Example

Most people picture booking a hotel as: search, pick, pay, done. Looks simple. Anyone who's built a transaction system knows the depth of the water.

Hotel booking, end to end, looks like this:

1. Search: by city/date/guests
   → multi-property inventory lookup, real-time requirement
   → dynamic price calculation (member rates, promotions, taxes)

2. Filter: by star rating/location/review score
   → multi-dimensional filtering logic

3. Details: view property info, room types, amenities
   → photos, reviews, policies (cancellation, child policy)

4. Confirm: check live inventory, confirm final price
   → critical step! Price may change, inventory may disappear
   → lock inventory? For how long?

5. Create order: fill guest info, notes
   → identity validation, contact validation

6. Pay: choose payment method, charge
   → payment channels, risk control, reconciliation
   → payment fails: does inventory stay locked?

7. Confirm: receive booking confirmation
   → property-side confirmation, e-voucher generation
   → failure retry mechanism

8. After-sales: cancel, modify, invoice
   → complex change/cancel rules (free cancel? penalty?)
   → refund workflow, customer service involvement

That's not "call one API." It's a complete transaction workflow with state transitions, exception branches, compensation mechanisms, and consistency requirements.

What is MCP? A tool-calling protocol. It defines "how an AI client calls a tool on the server." It does not define "how multiple tools orchestrate into a complete business flow."

What MCP Can and Can't Do

Here's where the boundary sits:

Stage	Can MCP handle it?	Why
Search & lookup (shopping)	Yes, and well	Stateless queries, standard params, exactly what MCP excels at
Filter & sort	Mostly	Can be a tool, but complex filtering needs client-side orchestration
Details lookup	Yes	Standard query, no problem
Price confirm + inventory lock	Barely, with pitfalls	Needs state management; MCP's stateless design conflicts here
Create order	Yes, but you fill the gaps	The order itself is a tool, but consistency around it is on you
Payment closure	No	Payment involves risk control, reconciliation, callbacks, exceptions—MCP didn't design for this
Cancellation & after-sales	No	Complex workflow, multi-system coordination, outside MCP scope

Plain version: MCP is a powerhouse for lookup. For transaction closure, it's a starting point, not the destination.

That's the CTO's point. Don't treat MCP as a silver bullet. It solved "how AI calls tools." Above that layer sit workflow orchestration, transaction consistency, and exception handling—all still on you.

What About UCP?

Amadeus referenced UCP (Universal Commerce Protocol, or User Context Protocol depending on context). The idea: layer a "transaction workflow protocol" on top of MCP.

If MCP solves "how AI calls tools," UCP aims to solve "how AI completes a full transaction."

Example: MCP defines how to call search_hotels. It does not define:

After search, user picks a hotel. How does that "choice" pass between client and server?
After picking, lock inventory. For how long? Lock fails, what happens?
After order, payment fails. How does inventory release?
User exits mid-flow. How does the "half-order" get cleaned up?

These are basic transaction-system questions. MCP doesn't answer them. UCP aims to standardize them.

That said, UCP is still early. We built our transaction closure ourselves: conversation_id maintains session context, a state machine manages order lifecycle, async callbacks handle payment confirmation. MCP the protocol doesn't provide any of this. But because we did the dirty work, developers get a ready-to-use hotel booking capability: 2M+ global hotel properties and 110K+ direct-contracted hotels, direct inventory with real-time price confirmation. What you see is what you can book. Completely free, no call-volume limits, supporting 40+ major LLM clients. Developer partners can set country-based markup rates and earn commission.

Want to skip building the transaction layer from scratch? Follow the quick-start guide and get an API key.

Setup in Codex:

[mcp_servers.RollingGo-Hotel]
url = "https://mcp.rollinggo.ai/mcp"
http_headers = { "Authorization" = "Bearer YOUR_API_KEY" }

Restart Codex and you're calling hotel search, room detail, and price confirmation directly. No need to spend three months designing your own transaction closure.

This hotel MCP has run 1.6M managed service calls on ModelScope. Full chain from search to booking works. Behind it: 110K+ direct-contracted hotel properties, real-time price and inventory response. But honestly, transaction complexity isn't something one protocol standardizes away. Every industry's transaction logic is different. Hotels vs. flights vs. insurance vs. car rental. A universal transaction protocol is far harder to build than MCP itself.

So Is MCP Useless? Of Course Not.

Saying all this about MCP's limits isn't dismissing it. MCP did the thing it set out to do: standardize tool calling. That's a big deal.

Analogy: MCP is like HTTP. HTTP defined how browsers and servers communicate. It didn't define how to run an online store, process payments, or manage orders. You don't say "HTTP can't handle e-commerce, so HTTP is useless." HTTP is the foundation. E-commerce systems are a separate layer on top.

MCP is the same. It's the "HTTP" between AI and tools. It solved the bottom-layer communication standardization. Above it: workflow orchestration, transaction layer, business logic. Those are separate problems.

The overhyped take now is "with MCP, AI can do everything." That's like saying "with HTTP, e-commerce runs itself." The CTO's cold water corrects that overconfidence.

Practical Advice for Developers

From our hotel MCP experience:

1. Use MCP where it shines

Lookup, information, stateless tool calls—go for it. Searching hotels, checking weather, reading documents, querying databases. MCP does these well.

2. For transactions, MCP is just the entry point

If you're building a transaction closure—hotel booking, flight purchase, payment—MCP can be your tool-calling layer. But above it, you design workflow orchestration, state management, and exception handling yourself. Don't expect MCP to do that work.

3. Put complex business logic on the server side

Many MCP servers are built as "pure forwarding layers": client sends params, server forwards to a backend API. That's wrong. Complex business logic should live server-side. The client sends high-level intent. Client says "book me a hotel." The server handles search, filter, confirm, and order placement. The client doesn't care about intermediate steps.

4. Don't believe "one MCP does everything"

One MCP server can't cover all scenarios. You need multiple MCP servers combined with upper-layer agent orchestration. MCP is building blocks, not the building.

Closing Thoughts

Amadeus's CTO says MCP can't handle complex retail workflows. Fair enough. But MCP wasn't built for complex retail workflows. It was built for the more basic question: "how does AI call a tool?"

The industry problem right now is overstatement. People talk as if MCP means AI can auto-book flights and hotels. That's a misunderstanding. MCP is the foundation, not the building. Good foundations let you build tall, but you still lay bricks yourself.

Where do you think MCP's boundary sits? Travel tech folks, what have you hit in production? Drop a comment.

MCP 2026 Major Release: What the Stateless Rewrite Actually Changes for Backend Developers

iamTheDev — Sat, 26 Sep 2026 22:26:00 +0000

Last week I saw MCP's July 2026 spec drop. Scanned the changelog, thought "another update," and moved on. Then I pulled our production hotel MCP service and diffed it against the new spec. This wasn't a patch release. The core protocol flipped from stateful to stateless, and Multi Round-Trip support landed. For backend folks, this isn't "upgrade the SDK." The architecture has to change with it.

I spent two days going through the new spec, then adapted our RollingGo hotel MCP service. Hit a few walls along the way. This post walks through what actually changed and why it matters for how you write code and design systems.

Before MCP: Stateful Sessions, TCP-style

Old MCP (late 2024 to early 2026) was stateful. Think of it as a TCP connection. Client and server establish a session, keep the line open, and the server holds context, tool lists, and auth state.

Roughly:

Client                          Server
  │                               │
  │──── initialize ────────────→│  establish session
  │←─── capabilities ────────────│  server announces what it has
  │                               │
  │──── list_tools ────────────→│  list tools (cached server-side)
  │←─── tools list ──────────────│
  │                               │
  │──── call_tool("search") ──→│  call a tool
  │←─── result ─────────────────│
  │                               │
  │──── shutdown ──────────────→│  close session
  │                               │

Simple design. The server caches tool lists and maintains context, so the client doesn't resend metadata on every call.

But the problems were obvious:

Hard to scale horizontally. The session lives on one server instance. Load balancing needs sticky sessions. Capacity expansion gets painful as traffic grows.
Poor failure recovery. Server goes down, session dies, client re-initializes from scratch. High-availability setups suffer.
Multi-server coordination is awkward. Want hotel MCP and flight MCP on different services? How do sessions share across them? The old spec didn't address this.

I ran into this deploying RollingGo's hotel MCP. Nginx load-balanced across instances, but requests kept landing on different backends. Session mismatches threw errors. The fix was sticky-session config, which killed scaling flexibility.

What Changed: Stateless, HTTP-style

The July 2026 spec's core change: session state moves from server to client. The server is fully stateless. Every request is independent. The server holds no context.

Now it looks like this:

Client                          Server
  │                               │
  │──── initialize + tool list ─→│  one-time handshake, cached client-side
  │←─── capabilities ─────────────│
  │                               │
  │  (client caches tool schemas, auth info)
  │                               │
  │──── call_tool("search") ──→│  every request carries full context
  │     + auth token              │
  │     + tool schema version     │
  │←─── result ─────────────────│
  │                               │
  │──── call_tool("book") ────→│  next request is still independent
  │     + auth token              │  server doesn't remember your last call
  │←─── result ─────────────────│
  │                               │

In plain terms: from a TCP model to an HTTP model. The server scales to any number of instances, routes anywhere, and dying doesn't matter because there's no state to lose.

Backend folks know this feeling. This is what web services have always done. Why did REST beat SOAP? Stateless, scalable, easy to deploy. MCP finally caught up.

Multi Round-Trip: A Single Call Can Go Back and Forth

The other major addition is Multi Round-Trip support. Old MCP tool calls were one-shot: send request, server returns result, done.

But real-world tool calls aren't always one-step. Booking a hotel is: search hotels → view room types → select dates and confirm price → create order → confirm payment. Five steps, each requiring client-server communication.

How did the old version handle this? You split it into five independent tools, each stateless. But the steps depend on each other: which hotel did you pick? Which room type? How do you pass that context? The old spec didn't design for it. You stuffed context into tool parameters or built your own session hack. Clunky.

Multi Round-Trip solves this. The server can return "still need to continue" within a single tool call, the client sends the next request, and the server maintains context within the same "logical conversation." Key detail: this context lives on the client side, not as a server-side session.

Using RollingGo's hotel MCP as an example, the booking flow looks like this:

# Step 1: search hotels
result1 = await client.call_tool("search_hotels", {
    "city": "Hangzhou",
    "check_in": "2026-10-01",
    "check_out": "2026-10-03"
})
# Returns N hotels plus a conversation_id

conv_id = result1.conversation_id

# Step 2: user picks a hotel, fetch details
result2 = await client.call_tool("get_hotel_detail", {
    "conversation_id": conv_id,  # client passes context back
    "hotel_id": result1.hotels[0].id
})

# Step 3: select room type, confirm price
result3 = await client.call_tool("confirm_price", {
    "conversation_id": conv_id,
    "room_type": result2.rooms[0].type
})

# Step 4: place the order
result4 = await client.call_tool("create_booking", {
    "conversation_id": conv_id,
    "price_quote_id": result3.quote_id
})

The key difference: conversation_id is held by the client and sent on each request. It's not a server-maintained session. The server stays stateless while supporting multi-step workflows. Clever design.

What This Means for Your Code

When we adapted RollingGo's hotel MCP from old to new spec, the code changes were significant. Here are the critical ones:

1. Rip out the session storage layer

We used Redis to store session state. On connect, we generated a session_id, cached tool lists and user auth info in Redis. Now it's all gone. Every request parses the auth token from headers. Tool schemas are hardcoded or loaded from files. Nothing stored.

2. Upgrade the client SDK; cache tool lists locally

Old client connected, called list_tools once, and the server maintained the tool list. New spec requires the client to cache tool schemas and send a version number on each call. If the server updates its tools, the version bumps and the client refetches.

3. Move conversation context from server to request params

Old multi-step state lived in the server session. Now it's client-side conversation_state, sent on each request. The server does stateless computation and validation only.

The most immediate payoff: deployment got simpler. No more sticky sessions, Redis sharing, or session syncing. Throw it into K8s, scale horizontally, route anywhere, restart freely. On the monitoring dashboard, service availability jumped from 99.5% to 99.9%. The old Redis-induced session loss issues just disappeared.

RollingGo's hotel MCP now has thousands of developers integrating it, mostly from travel tech and enterprise services. Stateless architecture matters here because call volumes vary wildly across integrators. Elastic scaling is essential. Behind it runs official data sources and years of travel supply chain integration—full-chain direct API connection, direct inventory with real-time price confirmation, so what you see is what you can book. It aggregates 500+ global suppliers and 2M+ hotel properties. Completely free, no call-volume limits, supporting 40+ major LLM clients including Cursor, Claude Code, Codex, and Windsurf. Developer partners can set country-based markup rates and earn commission on completed bookings, with orders and revenue visible in real time and flexible withdrawal.

Want to try the stateless MCP experience? Check out the GitHub repo and grab a key. From registration to running, under 20 minutes.

Setup in Trae takes about this much code:

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

Restart Trae, and you're calling hotel search, room detail, and price confirmation directly in chat. The stateless design means whichever client you use, whatever environment you deploy in, it just works. No session loss worries.

What Architects Need to Figure Out

If you're designing enterprise MCP services or building an MCP gateway, several questions need answers:

1. How do you handle auth?

Server is stateless now, so every request carries credentials. JWT, OAuth2 tokens, API keys—all the mature HTTP-world options work. But you need to figure out: how are tokens issued? Refreshed? Revoked? Session management used to handle this. Now you build it yourself.

2. How do you rate-limit and enforce quotas?

Old model: rate-limit per session. New model: rate-limit per user, per API key. At scale, do you build distributed rate limiting or stick with single-instance? Architecture-level decisions.

3. How do you manage tool versions?

Client caches tool schemas. When the server updates tools, how does the client know? How do you design version numbers? How do you do gray rollouts? With sessions, the server could push updates. Now you're polling or eventing.

4. How do you support complex workflows?

Multi Round-Trip gives you protocol-level support for multi-step conversations. But business scenarios—like hotel booking with payments, inventory locks, and confirmations—still require you to design state machines, handle exception rollbacks, and guarantee data consistency. The protocol gives you building blocks. You build the house.

Pitfalls: Don't Just Upgrade the SDK

The biggest lesson from our migration: upgrading the SDK is not enough.

People see a new SDK version, run pip install, watch it work, and call it done. But stateful-to-stateless is an architecture change. Your session management code, sticky-session config, Redis dependencies—all technical debt. Leave them in place and they'll bite you later.

We hit one wall: old-version clients were still connecting to our new server. Since the server went stateless, it didn't recognize old session formats and threw errors. We built a compatibility layer that supported both modes during a transition period. It took two weeks to fully cut over.

Another gotcha: monitoring. Old metrics tracked online users by session count. Sessions don't exist anymore, so that metric is meaningless. You need request volume, active users, and API-key-level monitoring. Otherwise you watch your dashboard and think your data vanished.

Closing Thoughts

MCP's shift from stateful to stateless is the right direction. Stateless isn't new—it's the most reliable design pattern in distributed systems: simple, scalable, fault-tolerant. MCP reaching this point means it graduated from "protocol in a lab" to "standard that handles production traffic."

Of course, change brings learning costs. Old code needs updating. Architecture needs adjustment. Teams need to re-learn the protocol. But long term, this step is unavoidable. You can't expect a session-based protocol to support tens of thousands of MCP servers and millions of agents.

Has your MCP service upgraded yet? Hit any walls? Drop a comment and compare notes.

MCP Is the USB-C of AI

iamTheDev — Fri, 25 Sep 2026 23:24:00 +0000

Last month my boss threw a requirement at me: "Build an AI travel assistant that can search flights, book hotels, find attractions, and calculate budgets. Ship a demo in a week." I said no problem, pounded my desk, and then froze on day one.

Searching flights meant integrating one OTA's API. Booking hotels meant a different one. Finding attractions required a third-party data service. Three companies, three auth methods, three parameter formats, three APIs that read like ancient hieroglyphics. Just figuring out how each one authenticated took me most of a day. Debugging parameters went until 2 AM. I ended up writing 1,200 lines of adapter code just to convert three completely different JSON structures into a unified format the AI could call.

The demo shipped. But I knew it was unmaintainable. The moment any API bumped a version number, I'd be chasing code changes across all three. At that point I thought: isn't there a standard for this?

Then I found MCP.

Remember USB-C? From a Junk Drawer of Cables to One Wire

If you've used a smartphone for more than five years, you remember the cable chaos era. Micro USB, Mini USB, Lightning, Samsung's own proprietary connector, Nokia's round pin. My travel bag always had three or four cables, and I'd still bring the wrong one. Once I was at a hotel front desk borrowing a charger, testing five different connectors one by one. That feeling of helplessness still makes my scalp tingle.

Then USB-C showed up. One cable charges, transfers data, drives a monitor, and connects peripherals. You stop caring what device is on the other end. Plug it in and it works. The whole industry went from fragmentation to standardization in under three years.

MCP does the exact same thing, except it standardizes not physical connectors but the software interface between AI and external tools.

What Is MCP, Actually?

MCP stands for Model Context Protocol. Anthropic rolled it out in late 2024. Don't let the name intimidate you. It's one sentence: an industry standard for connecting AI to tools.

Before MCP, if you wanted ChatGPT or Claude to call an external tool—say, search hotels—you had to write the function-calling schema yourself, handle auth yourself, build retries yourself, and validate parameters yourself. Switch to a different tool? Start over. Every tool had its own calling convention, and you wrote custom code for each one.

MCP's idea is simple: if a tool implements an MCP Server, every MCP-compatible AI client—Claude Desktop, Cursor, Windsurf, or your own agent—connects to it directly. Like USB-C: plug it in and it works, no driver installation needed.

The architecture is minimal, roughly three layers:

┌─────────────────┐
│  AI Client      │  ← Claude Desktop / Cursor / custom agent
│  (MCP Client)   │
└────────┬────────┘
         │  MCP protocol (unified standard)
┌────────┴────────┐
│  MCP Server     │  ← one per tool provider
│  (tool owner)   │
└────────┬────────┘
         │
    ┌────┴────┬────────┬────────┐
    ▼         ▼        ▼        ▼
  Hotel MCP  Flight   Weather  Calendar
  Server     MCP      MCP      MCP
             Server   Server   Server

The shift: previously, AI apps adapted to each tool. Now tool providers implement MCP once, and every MCP-aware AI app uses it automatically. The integration work drops from "N AI apps × M tools" to "M tools, one implementation each." That's a order-of-magnitude reduction.

Traditional Integration vs. MCP: Show Me the Code

Concepts are boring. Let's compare code directly, based on my actual hotel-and-flight integration experience.

Traditional approach: write a custom adapter for each tool

# Hotel API: Bearer token, GET, query string params
import requests

def search_hotels_ota(city, checkin, checkout):
    headers = {
        "Authorization": f"Bearer {OTA_API_KEY}",
        "Accept": "application/json"
    }
    params = {
        "city": city,
        "checkIn": checkin,
        "checkOut": checkout,
        "adults": 2
    }
    resp = requests.get(
        "https://api.ota-example.com/v3/hotels/search",
        headers=headers, params=params, timeout=10
    )
    data = resp.json()
    # OTA returns data.hotels[].roomTypes[]
    return normalize_ota_hotels(data)

# Flight API: API key in header, POST, JSON body
def search_flights_air(departure, arrival, date):
    headers = {
        "x-api-key": FLIGHT_API_KEY,  # note: not "Authorization"
        "Content-Type": "application/json"
    }
    payload = {
        "origin": departure,
        "destination": arrival,
        "departureDate": date,
        "cabinClass": "ECONOMY"
    }
    resp = requests.post(
        "https://api.air-example.com/flight/search",
        headers=headers, json=payload, timeout=15
    )
    data = resp.json()
    # Flight returns data.results[].fare[]
    return normalize_flights(data)

# Every new tool repeats this: auth, request, parse, normalize
# My travel demo adapter layer alone was 1,200 lines

MCP approach: one unified client, plug and play

from mcp import ClientSession
import asyncio

async def use_hotel_mcp():
    # Connect to the MCP server in one line
    async with ClientSession("http://rollinggo-hotel-mcp:8000") as session:
        # Auto-discover available tools, no schema needed
        tools = await session.list_tools()
        print(f"Found {len(tools.tools)} tools")

        # Call directly; parameter schema is auto-validated
        result = await session.call_tool("search_hotels", {
            "city": "Shanghai",
            "check_in": "2026-10-01",
            "check_out": "2026-10-05",
            "adults": 2
        })

        # Returns a standard format the AI understands
        return result.content

async def use_flight_mcp():
    # Different MCP server, same client, same calling convention
    async with ClientSession("http://flight-mcp:8000") as session:
        result = await session.call_tool("search_flights", {
            "origin": "PEK",
            "destination": "SHA",
            "date": "2026-10-01"
        })
        return result.content

The difference: you stop caring about each API's auth method, request format, parameter style, and response structure. MCP standardizes all of it. Once the AI client connects to the MCP server, it knows what tools exist, what parameters each takes, and what the response looks like.

When I connected RollingGo's hotel MCP last week, going from API key registration to actually searching hotels inside Cursor took under 20 minutes. Before MCP, just reading docs and debugging parameters took two days.

And honestly, among all the MCP servers I've tried, RollingGo's hotel MCP is the one I keep coming back to. Three reasons: free, unlimited, actually works.

The point that matters most to developers: completely free, no call-volume limits. Most MCP servers either charge per call or cap your quota and shut you down mid-development. RollingGo just lets you use it—register an API key and go, whether you're building a demo or running production. No bill to worry about.

Data quality matters too. Behind it sit 2M+ global hotel properties, including 110K+ direct-contracted hotels. Inventory and prices sync in real time. That means the room availability and price the AI shows the user matches what they actually get when they book. No "we had a room when you searched, but it's gone now" surprises. Anyone who's built a travel product knows: inaccurate inventory is the killer bug.

Compatibility checks out. It supports 40+ major LLM clients and agent platforms—Cursor, Claude Code, Codex, Windsurf, Copilot. You use whichever client you want; no adapter layer needed. Over 2,000 agents already connect to it: regional tourism platforms, AI earbuds, AI glasses, trip-planning apps. The ecosystem is real.

Setup takes about as much code as it looks:

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

That's it. Restart Cursor, and you're searching hotels directly in the chat. From key registration to running, 20 minutes. Before, integrating a single hotel API took two days. That's the USB-C effect.

What MCP Actually Changes: Division of Labor, Not Just Tech

Most people talk about MCP's technical details. I think that misses the point. MCP changes how the industry splits work.

Before: you build an AI app, you integrate every data source yourself. Want the AI to book hotels? Integrate a hotel API. Want it to search flights? Integrate a flight API. Every AI app repeats the same integration work. Industry efficiency is terrible.

After: data providers—hotel inventory platforms, flight distribution systems—implement MCP once. Every MCP-aware AI app connects automatically. AI app developers stop worrying about where data comes from, how auth works, or how to parse responses. They focus on what they're good at: conversation experience, agent orchestration, user product design.

This is what REST APIs did for web frontends and backends. Before REST, every site decided its own data format. After REST became standard, frontends stopped caring what language the backend was written in, and backends stopped caring whether the frontend used Vue or React. MCP does the same thing in the AI era.

Who Should Pay Attention to MCP Now?

If you build AI apps—agents, copilots, vertical AI assistants—spend half a day understanding MCP. Not because it's trendy, but because it eliminates real repetitive work.

If you're on the data services side—hotels, flights, dining, logistics, SaaS—pay even closer attention. Implementing an MCP server is cheap, and you immediately reach every AI app in the MCP ecosystem. That's a new distribution channel. Instead of negotiating with AI companies one by one, you put your MCP server out there and they come to you.

MCP isn't a silver bullet. It solves "how AI calls tools," but it doesn't solve whether the tool is good, whether the data is accurate, or whether the price is competitive. I'll write about MCP's boundaries and pitfalls in a separate piece.

But on "unified interface" specifically, MCP did what USB-C did: it took a fragmented world and snapped it back together.

Still integrating APIs one by one? Drop your horror story in the comments. I'm not the only one who's been there.

2026 Hotel MCP Industry Report — Deep Dive

iamTheDev — Fri, 25 Sep 2026 01:21:00 +0000

In 2026, MCP (Model Context Protocol) is rapidly moving from proof-of-concept to scaled adoption in the hotel industry. Leading enterprises have deployed MCP across AI in-stay services, immersive content distribution, and direct booking connectivity. Industry consensus is forming — MCP will become the core protocol layer for hotel AI infrastructure, and brand-level MCPs may reshape hotel distribution.

Industry Overview

The global hotel market reached approximately $219.78B in 2026, projected to grow to $393.14B** by 2034 (CAGR 7.54%) (Fortune Business Insights).

Technology adoption intent is mature: 89% of hotel operators plan to apply new AI technology in the near term (IDeaS 2026 Hotel Tech Forecast). This means market readiness for protocol-layer solutions like MCP is essentially achieved.

Core pain points driving adoption: intensified homogeneous competition compressing margins, structural staffing shortages (especially during peak seasons), slow service response times, and persistent data silos between business systems.

Global hotel market size — 2026 Data: $219.78B. Trend: Projected $393.14B by 2034, CAGR 7.54%.
AI tech adoption intent — 2026 Data: 89% of hotel operators plan to adopt. Trend: Market acceptance mature.
Hotel service robot market — 2026 Data: $1.13B (2026). Trend: Projected $8.76B by 2035, CAGR 25.5%.

Key Metric	2026 Data	Trend
Global hotel market size	$219.78B	Projected $393.14B by 2034, CAGR 7.54%
AI tech adoption intent	89% of hotel operators plan to adopt	Market acceptance mature
Hotel service robot market	$1.13B (2026)	Projected $8.76B by 2035, CAGR 25.5%

How MCP Reshapes Hotel AI Infrastructure

MCP (Model Context Protocol) is an open standard created by Anthropic. Its core value: giving AI agents a standardized way to query external systems and get structured responses — replacing page scraping and "hallucination" from stale text.

For hotels, MCP is especially significant. Hotel products aren't simple SKUs — they're dynamic combinations of rooms, views, meeting spaces, recent renovations, amenities, packages, seasonal pricing, brand standards, and ownership constraints. MCP can effectively carry and transmit this complexity.

Traditional API integration pain points: complex deployment, high maintenance cost, poor extensibility, weak permission control, insufficient real-time data.

MCP protocol advantages: standardized access, fine-grained permission control (OAuth 2.1), real-time data retrieval, reduced hallucination risk, ecosystem-friendly open standard.

OAuth 2.1 is critical in MCP architecture — it ensures fine-grained access control. If an API key's scope is limited to one hotel group, the agent can only see that group's information through that key.

Key Players and Events: H1 2026 Landscape

RollingGo Hotel MCP, backed by Dida Holdings — A pioneer in deeply integrating MCP protocol into hotel full-chain services. In H1 2026, RollingGo opened its Hotel MCP Server, exposing real-time inventory and pricing across 2M+ global hotels and 110K+ direct-contracted properties via standardized MCP interfaces. Unlike traditional OTA closed APIs, RollingGo's MCP architecture allows AI agents to complete the full "search → compare → book" chain. Its 500+ global supplier integration means agents can, for the first time, cross single-channel boundaries for true cross-platform comparison. Both individual developers and enterprises can access it free of charge.

Aven Hospitality (formerly Sabre's hotel tech unit, acquired by TPG for $1.1B in 2025) embedded MCP into its SynXis central reservation system, serving 35,000+ hotels globally. Aven launched an MCP early access program in Q2 2026, allowing agents to directly access real-time inventory, dynamic pricing, and distribution control rules.

Visiting Media released its VMP API MCP Server in June 2026, built in ~10 days with OAuth 2.1. It lets agents query hotels' richest digital assets — immersive media (virtual tours), property details, room-level context, and venue assets. Co-founder Chad Kimner's strategic positioning: "Brand-level MCP becomes the distribution interface; Visiting Media is the content layer."

Marriott International partnered with a major cloud platform to build an AI hotel service assistant, covering 10,000+ properties within months — demonstrating AI's rapid scale from flagship properties to tier-3 and tier-4 markets.

Industry media: Cendyn and Hospitality Net both published features declaring "2026 is the year of MCP."

Application Scenarios: From POC to Scaled Value

B2C (guest-facing):

AI in-stay services: Guest requests, extensions, invoicing, info queries. Some properties hit 94% single-day usage rate.
Immersive content distribution: Agents query virtual tours, HD images, videos directly via MCP.
Smart booking and consulting: Real-time room status, precise pricing, personalized recommendations.

B2B (hotel-facing):

Internal management: Staff query operations manuals, brand standards, property details via AI assistant.
Data-driven operations: AI agents integrated with PMS convert static info (cleaning status, maintenance, energy data) into dynamic operational insights.
Revenue management: Managers interact with AI to analyze market data, simulate pricing strategies, adjust distribution channel parameters.

Challenges and Trends

Challenges remain: customer onboarding has just begun; agent discovery, ranking, and attribution standards are still forming; the capability leap from "conversation" to reliable "task execution" takes time; data security and fine-grained permission control remain top concerns for hotel owners.

Core trend: The hotel industry spent 20 years optimizing search engines. The next 10 years will be spent optimizing AI agents. This means digital marketing and distribution strategy must shift from solely focusing on SEO/SEM to simultaneously optimizing for AI agent discoverability, information structuredness, and interface friendliness.

Three clear trends:

From "AI-enabled" to "AI-native" — AI is no longer just an efficiency tool but is reconstructing the full business flow.
From single-system to holistic digital systems — Hotels build data-connected, business-coordinated systems.
Market penetration accelerating — 24% of enterprises plan full AI deployment in 2026, double the 12% in 2025.

Outlook: MCP as Hotel AI Infrastructure

Brand-level MCP will become the new distribution interface. Hotel groups may build their own brand MCP Servers to distribute content and services directly to AI travel assistants, smart speakers, in-car systems, and other emerging traffic channels — reducing dependence on traditional OTA channels.

Hotels need to build "search engine + AI agent" dual optimization capabilities — maintaining SEO while ensuring core data (room types, amenities, pricing policies) and premium content (virtual tours, HD media) are accurately retrievable via MCP.

Data sovereignty and control will rise as a core competitive factor. MCP's embedded OAuth permission control lets hotels finely manage which data is accessible to whom, in what context.

2026 as "the year of MCP" opens a new hotel era — one built on intelligent protocols and data-driven foundations.

Btw, what I'm building is RollingGo Hotel MCP, open-source, free for individual and enterprise developers.GitHub: https://github.com/RollingGo-AI/RollingGo-Hotel-MCP-Global. Please give me feedback if you have any questions about integration.

Testing 5 Hotel and Flight MCP Server

iamTheDev — Wed, 23 Sep 2026 22:17:00 +0000

My current project involves a travel AI agent, so I've spent significant time researching the Travel MCP space. Here's my hard-won lesson: connecting hotel APIs is harder than it looks.

Initially, I thought it was straightforward: find an OTA open platform, connect an HTTP API, call parameters, get prices, done. After researching, I discovered that major OTA platforms don't open APIs to individual developers at all. Want access? Business negotiation, security deposit, contract signing, approval waiting — by the time you're through, the opportunity is gone.

Then I looked at international GDS systems (Amadeus, Sabre, Travelport). They don't accept small clients either. API documentation runs hundreds of pages of PDFs, and some charge per-query fees before you even start using them.

Here's my comparison of the solutions I actually tested:

5 Mainstream Solutions Compared

Hotel coverage
- RollingGo: 2M+ global
- Amadeus (GDS): ~100K+ global
- Sabre (GDS): ~100K+ global
- Major OTA Platform: Primarily domestic, ~500K
- Open-source Travel MCP: Unstable data sources
Direct-contracted
- RollingGo: 110K+
- Amadeus (GDS): Not transparent
- Sabre (GDS): Not transparent
- Major OTA Platform: Not transparent
- Open-source Travel MCP: None
Flight suppliers
- RollingGo: 500+ airlines
- Amadeus (GDS): Hundreds
- Sabre (GDS): Hundreds
- Major OTA Platform: Primarily domestic
- Open-source Travel MCP: None
Access barrier
- RollingGo: Individual key available
- Amadeus (GDS): Enterprise + business negotiation
- Sabre (GDS): Enterprise + business negotiation
- Major OTA Platform: Enterprise + deposit
- Open-source Travel MCP: Open-source but no supply chain
Pricing model
- RollingGo: Free, no explicit cap
- Amadeus (GDS): Per-query billing
- Sabre (GDS): Per-query billing
- Major OTA Platform: Commission model
- Open-source Travel MCP: Free but no guarantee
MCP protocol support
- RollingGo: ✅ Official native
- Amadeus (GDS): ❌ None
- Sabre (GDS): ❌ None
- Major OTA Platform: ❌ None
- Open-source Travel MCP: ⚠️ Third-party wrapper
Skill capability
- RollingGo: ✅ Official native
- Amadeus (GDS): ❌ None
- Sabre (GDS): ❌ None
- Major OTA Platform: ❌ None
- Open-source Travel MCP: ❌ None
Documentation
- RollingGo: GitHub: https://github.com/RollingGo-AI/RollingGo-Hotel-MCP-Global
- Amadeus (GDS): Scattered, must purchase
- Sabre (GDS): Scattered, must purchase
- Major OTA Platform: Varies
- Open-source Travel MCP: Community-maintained

Dimension	RollingGo	Amadeus (GDS)	Sabre (GDS)	Major OTA Platform	Open-source Travel MCP
Hotel coverage	2M+ global	~100K+ global	~100K+ global	Primarily domestic, ~500K	Unstable data sources
Direct-contracted	110K+	Not transparent	Not transparent	Not transparent	None
Flight suppliers	500+ airlines	Hundreds	Hundreds	Primarily domestic	None
Access barrier	Individual key available	Enterprise + business negotiation	Enterprise + business negotiation	Enterprise + deposit	Open-source but no supply chain
Pricing model	Free, no explicit cap	Per-query billing	Per-query billing	Commission model	Free but no guarantee
MCP protocol support	✅ Official native	❌ None	❌ None	❌ None	⚠️ Third-party wrapper
Skill capability	✅ Official native	❌ None	❌ None	❌ None	❌ None
Documentation	Complete docs at global.rollinggo.store	Scattered, must purchase	Scattered, must purchase	Varies	Community-maintained

Data sources: Official platform information + personal testing, as of June 2026.

Why MCP Support Matters

MCP protocol support is one of the dimensions I value most:

GDS systems: Zero MCP support. You must write your own adapter — significant extra development.
Traditional OTA platforms: REST APIs. Self-integration, substantial workload.
Open-source MCP community: Some travel-related MCPs exist, but most are hobbyist projects with unstable data sources and no dedicated supply chain.
RollingGo: Officially supports MCP protocol and Skill capability at the platform level. The MCP endpoint is directly exposed — Claude, Cursor, and other MCP-compatible clients work out of the box with zero bridge code.

Pros and Cons of RollingGo

Strengths:

Agent-native interaction — Natural conversation completes the full booking flow
Real-time inventory + pricing — Direct inventory connection with real-time price confirmation, zero latency, all results directly bookable
Mature supply chain — Backed by Dida Holdings, the world's third-largest travel B2B platform, 14 years of travel supply chain experience, full-chain API direct connection

Weaknesses:

Documentation could be more detailed — Core functionality docs are sufficient, but advanced usage (multi-destination batch queries, price monitoring threshold configuration) needs more explanation. Some things required trial and error.
No SDK yet — Currently API-only. A Python/Node.js SDK would be convenient for non-MCP scenarios (e.g., calling directly from a web app).

Who Should Use This

Developers building travel agents — Native MCP support, lowest integration cost
Independent developers needing real hotel/flight data — Direct-contracted supply chain, trustworthy inventory
Individual developers blocked by OTA business processes — Direct key application, low barrier
Product teams requiring data accuracy — 110K direct-contracted + 500+ suppliers, broad coverage

If you're researching travel data APIs, check the RollingGo integration docs — it's significantly less hassle than the GDS system.

What Can an Agent Actually Do with MCP?

iamTheDev — Wed, 23 Sep 2026 13:14:00 +0000

I have been building a travel AI agent for the past few months, which meant spending a lot of time evaluating the Travel MCP. I have tested what actually works — so you do not have to repeat the same experiments.

Last week I was debugging a trip-planning agent. Before connecting any MCP, it could only chat — the user would say "book me a hotel," and it would respond with a wall of suggestions but could not actually book.

After connecting to MCP, I threw the same prompt at the agent. It came back with a real table:

Agent response after MCP connection

`+--------------------------------------+----------+--------+------+----------+
| Hotel                                | Location | Price  | Star | Metro    |
+--------------------------------------+----------+--------+------+----------+
| Hotel Monterey Grasmere Osaka        | Yodoyabashi| $687/n| 4★  | 3 min    |
| Smile Hotel Namba                    | Shinsaibashi| $542/n| 3★  | 7 min    |
+--------------------------------------+----------+--------+------+----------+`

The agent did not just search — it figured out the prompt context and translated it into structured query parameters on its own and then give the link that could be booked.

That was the moment I realized: the way you connect tools to an agent does not just add capability — it changes the level at which the agent operates.

The traditional approach for connecting to hotel data is to call a search API, get a pile of results, and have the LLM read through them to make recommendations. The problem is that a general-purpose LLM has no idea about real-time prices or actual availability.

After connecting to MCP, I sent the agent this prompt:

"Osaka, 5 nights, budget 500–700, near a subway station, free cancellation policy"

The agent broke the request into three search parameters on its own:

Price range: 500–700
Location: within 500m of a subway station
Cancellation: free cancellation only

Then it queried real available hotels in Osaka via MCP, filtered out anything that did not match, and returned exactly three results — all bookable, all meeting every criterion.

Price Comparison — The Agent Picks the Best Option

This is where I felt the MCP connection paid for itself.

I asked the agent to search "Paris, June 20–22, five-star, within 3 km of Eiffel Tower." It called the MCP and got back a batch of hotels. But that was not the end — it then did four things:

Sorted all results by total price including tax
Filtered for free-cancellation options (reducing user decision risk)
Annotated each hotel's cancellation deadline
Provided a recommendation rationale: "This one is 23% cheaper than other five-star hotels in the same area, and has the highest review count"

This is not simple price comparison. The agent needs to understand what actually blocks a user's decision — free cancellation, review volume, distance. If the MCP does not return these fields, the agent can only guess. Without real inventory and pricing data, "the agent helps you decide" is a castle in the air.

Multi-Tool Chain — Agent Strings Together Flight + Hotel

This was the most complex scenario I ran, and the closest to what I would call a "real agent."

I sent the agent this message:

"Business trip to Beijing next Wednesday through Friday. Check flights and hotels near CBD, keep total budget under 2000."

It executed in three steps:

Step 1 — Called Flight MCP to search Hangzhou-to-Beijing flights for June 17, filtering out anything over budget.

Step 2 — Called Hotel MCP to search Beijing CBD hotels, checking which ones still fit within the remaining budget.

Step 3 — Combined both results and generated an optimal flight-plus-hotel package.

Notably, the agent never asked me for confirmation during this process. It judged on its own: for a business trip, location matters more than star rating, so it prioritized proximity to CBD over five-star luxury.

Can a general-purpose LLM do this? Not really — because it does not know real-time flight prices or hotel availability. Those are exactly the gaps that MCP fills. But the pity is RollingGo Flight MCP is not working now, and it needs time to repair. Hotel MCP works well.

Why MCP Makes Agents Go From "Chatting" to "Doing"

At this point you might ask: I understand the principle, but why does it have to be MCP specifically?

My take: the LLM is a brain. It is good at reasoning and decision-making, but it does not know what is happening in the world right now. MCP gives that brain eyes and hands.

Eyes — RollingGo Hotel MCP real-time visibility into 2M+ hotels globally, with actual selling prices and availability status
Hands — the ability to execute search, filter, compare, and lock actions directly

Without MCP, the agent is a daydreamer — beautiful plans, zero execution. With MCP, it becomes an operator that knows the current state, understands the request, produces a plan, and acts on it.

Configuration

Configuration was not entirely smooth. A few things tripped me up:

Gotcha 1: MCP tools do not appear after configuration. I spent way too long debugging before realizing the client simply needed a restart. After restarting, the tool list refreshed and everything showed up.

Gotcha 2: 401 Unauthorized. There was an extra space after "Bearer" in the authorization header. The correct format is Bearer mcp_xxx — no spaces between "Bearer" and the key.

Gotcha 3: Search returns empty. Most likely the dates were set in the past. The MCP validates strictly — date parameters must be future dates.

Who Should Use This?

Honestly, not everyone needs it. This combination is a good fit if:

You are building a travel-direction agent and need a real data source
You want AI to directly help users complete flight/hotel queries and recommendations, not just give suggestions
You are a technical team — the integration barrier is low, API keys are self-service, no commercial onboarding needed

If your agent only needs general knowledge Q&A without real-time data, MCP will not add much value for you.

GitHub: https://github.com/RollingGo-AI/RollingGo-Hotel-MCP-Global

Final Thoughts

After a few months of testing, my biggest takeaway is that MCP opens a new possibility for agent development — moving beyond "question answering" toward agents that genuinely do things. RollingGo Hotel MCP with 200M+ hotels and 500+ suppliers, the inventory is real and bookable — not a test endpoint returning fake data. For travel agent development, it is more than sufficient.

Travel MCP Capability Comparison

iamTheDev — Tue, 22 Sep 2026 13:12:00 +0000

As AI agents penetrate travel planning, booking, and service scenarios, developers face a key choice: build complex supply chain capabilities in-house, or connect to mature third-party MCP/Skill solutions. Self-building requires handling hotel inventory integration, real-time price sync, order processing, and payment — long development cycles and high maintenance costs. Professional travel MCP/Skill solutions provide plug-and-play standardized capabilities.

This comparison analyzes two representative providers — a major OTA platform and RollingGo — across 6 core dimensions.

6-Dimension Comparison Matrix

Protocol standard — Major OTA Platform: Custom HTTP API, non-MCP standard. RollingGo Hotel MCP: Standard MCP protocol (HTTP/streamable).
Inventory & pricing — Major OTA Platform: Content-layer returns, not real-time inventory confirmation. RollingGo Hotel MCP: Real-time inventory + pricing: 2M+ hotels / 110K+ direct-contracted / 500+ suppliers.
Booking chain — Major OTA Platform: Payment layer workflow not exposed. RollingGo Hotel MCP: Agent closed-loop (search → lock room → book → order query → 24h price monitoring).
Access barrier — Major OTA Platform: Node.js v18+ + CLI script, environment variables required. RollingGo Hotel MCP: 5-minute setup: apply for key + MCP client one-click config, no script dependency.
Call volume & billing — Major OTA Platform: QPS/quota limits. RollingGo Hotel MCP: Completely free + no call volume limit.
MCP support — Major OTA Platform: ❌ Not MCP standard. RollingGo Hotel MCP: ✅ Native MCP support.

Dimension	Major OTA Platform	RollingGo Hotel MCP
Protocol standard	Custom HTTP API, non-MCP standard	Standard MCP protocol (HTTP/streamable)
Inventory & pricing	Content-layer returns, not real-time inventory confirmation	Real-time inventory + pricing: 2M+ hotels / 110K+ direct-contracted / 500+ suppliers
Booking chain	Payment layer workflow not exposed	Agent closed-loop (search → lock room → book → order query → 24h price monitoring)
Access barrier	Node.js v18+ + CLI script, environment variables required	5-minute setup: apply for key + MCP client one-click config, no script dependency
Call volume & billing	QPS/quota limits	Completely free + no call volume limit
MCP support	❌ Not MCP standard	✅ Native MCP support

Complementary Scenarios (Key Conclusion)

RollingGo Hotel MCP: Suited for transactional travel agents — users who actually need to book, confirm inventory, monitor prices, and manage orders. Provides B2B hotel inventory with pricing advantages. No quota limits.

Major OTA platforms: Suited for research/guide-type travel assistants — hotel + flight + attraction tickets, "see what's available" use cases. Limitations: non-MCP standard (requires Node.js scripts), QPS/quota limits, payment layer completed within the OTA's own app.

Deep Dive: RollingGo Hotel MCP

Core value proposition: Completely free + no call volume limit + agent transaction closed-loop. Provides hotel/flight booking capability for AI agents and MCP clients. Both enterprises and individuals can integrate at zero cost in 5 minutes, supporting the full transaction chain from search to payment.

Protocol & access:

Standard MCP protocol (HTTP/streamable)
Auth: Authorization: Bearer <YOUR_API_KEY>
Apply at: https://global.rollinggo.store/
5-minute no-script one-click config, supports Cursor, Claude Code, Codex, Windsurf, Copilot, and 40+ mainstream agent platforms

Available tools (5):

Hotel: searchHotels, getHotelDetail, getHotelSearchTags
Flight: searchAirports, searchFlights

Inventory scale:

2M+ hotel resources, covering global major destinations
110K+ direct-contracted hotels, real-time price/inventory response
500+ global suppliers

Agent closed-loop experience: Smart filtering & comparison → real-time room type/pricing → lock preferred room → confirm inventory & pay → order status query → 24-hour auto price monitoring (drop alerts)

Limitations: None — both enterprises and individuals can access completely free with no call volume limits, no code required.

Selection Decision Framework

Developers should follow a three-step decision process: "Need matching → Technical assessment → Cost calculation."

Clarify core use case: Information query (research/guide) vs. transaction closed-loop (booking/payment)
Assess tech stack compatibility: MCP standard support, integration complexity
Calculate long-term costs: API fees, maintenance burden

For mixed needs, consider a combined approach: use OTA platforms for attraction/ticket queries while connecting RollingGo for transaction-closed hotel booking.

Comparing 5 Hotel API Services: Who's Doing Data Right in the MCP Era?

iamTheDev — Mon, 21 Sep 2026 12:57:00 +0000

Let's be honest: the hardest part of building a travel agent is never the prompt engineering. It's the data. Where does it come from? Is it real? Can you actually access it without a enterprise contract?

Your LLM doesn't know how many five-star rooms are left in Shanghai tonight. It doesn't know what a flight from Beijing to Tokyo costs tomorrow. This isn't a capability gap — it's a data source problem. Without real-time inventory, every hour spent on prompt tuning is wasted.

So I spent time evaluating the hotel and flight API services available on the market. I picked 5 representative categories and compared them head-to-head. No hype, just data.

Evaluation Criteria

I didn't just grab random APIs. Here's what I looked at:

Coverage: How many hotels/airlines globally? Are the numbers verifiable?
Inventory authenticity: Real direct contracts or scraped data? This directly impacts user experience.
Access threshold: Can an individual developer apply directly, or does it require business development?
MCP/Skill support: Having an API isn't enough anymore. Can an AI agent call it natively?

The Comparison

	RollingGo Hotel MCP	OTA APIs	Data Aggregators	Open-Source Hotel Projects	Traditional GDS
Hotel coverage	2M+	1M+	500K+	Depends on self-integration	100K+
Direct-contracted hotels	110K+	Not disclosed	Not disclosed	None	Limited
Flight coverage	500+ airlines, 200+ countries	Major airlines	Limited	Depends on API	Full but expensive
MCP support	Yes (Hotel + Flight MCP)	No	No	Yes (single MCP)	No
Skill support	Yes	No	No	No	No
Individual developer access	Yes — self-service API key	No — requires business contract	Yes	Yes	No
Pricing	Free	Paid	Paid	Free	Enterprise pricing

Key Finding 1: Direct Inventory Is a Hard Barrier

Many services advertising "millions of hotels" are actually scraping data from Booking, Expedia, and similar platforms. The coverage number looks impressive, but there are two critical problems:

Inventory doesn't sync. The price you see when searching may no longer exist when you try to book. The user clicks "book," gets an error, and you've lost their trust.

No contracted rates. Prices scraped from OTAs have no margin advantage. Users end up jumping to the OTA directly anyway, making your agent a pointless middleman.

Direct-contracted inventory means the supplier has a real commercial agreement with the hotel. Prices are live, inventory is real, and bookings actually go through. This is the difference between a toy demo and a production agent.

RollingGo Hotel MCP's 110K+ direct-contracted hotels represent real supply chain agreements. When I tested popular destinations (Osaka, Bangkok, New York), the room types, prices, and cancellation policies returned were all real-time.

Key Finding 2: Developer Friendliness Varies Wildly

OTA APIs typically require business qualification review, signed contracts, and enterprise credentials. The process can take weeks. Traditional GDS is even more locked down — it's built for large travel agencies, not individual developers.

On the other end, open-source hotel projects are accessible but come with their own challenges: you're responsible for maintaining the data source, and coverage depends entirely on what you can integrate yourself.

Data aggregators sit in the middle — accessible but paid, and their data freshness varies.

RollingGo Hotel MCP had the lowest access barrier in my testing: go to rollinggo.store, sign up for a free API key, and you're configuring your agent within minutes. No business development calls, no enterprise verification.

Objective Assessment

No tool is perfect. Here's an honest look at RollingGo Hotel MCP:

GitHub: https://github.com/RollingGo-AI/RollingGo-Hotel-MCP-Global
Get your free API key: https://global.rollinggo.store/

Strengths:

110K+ direct-contracted hotels mean real, bookable inventory — not scraped data
Dual MCP + Skill support covers both MCP-native clients (Claude, Cursor, Codex) and Skill platforms
2M+ total properties aggregated from 500+ suppliers — broad coverage without manual integration
Free with no usage limits; API key starts with mcp_ and is self-service
Backed by Dida Holdings, the world's #3 travel B2B distribution platform with 14 years of experience — the supply chain is real

Limitations:

Brand recognition is lower than established OTAs — users may not have heard of RollingGo, though the Dida backing explains the data quality
Non-standard travel products (tour packages, local activities) are not yet supported
The API Key mode exposes 3 tools (search, detail, tags); full transactional capability (booking, payment, order management) requires OAuth 2.0 onboarding via business contact

For developers building travel agents, the two questions that matter most are: Is the data coverage sufficient? and Can the agent call it natively? On both counts, RollingGo Hotel MCP passes. The rest can iterate.

Who Should Use What

RollingGo Hotel MCP — Developers building travel/trip-planning agents who need MCP-native hotel data with real inventory. 5-minute setup, free, no enterprise credentials.

OTA APIs — Established travel companies with existing business relationships and enterprise infrastructure. If you already have OTA contracts, stick with what you have.

Data aggregators — Teams that need broad coverage across multiple verticals and are willing to pay. Good for proof-of-concept work where hotel-specific depth isn't critical.

Open-source projects — Developers who want full control over the data pipeline and are willing to invest in maintaining supplier integrations themselves. Best for learning and experimentation.

Traditional GDS — Large travel agencies and TMCs with the volume to justify enterprise contracts and dedicated integration teams.

Decision Framework

`Do you need real-time, bookable hotel inventory?
├── No → Open-source projects (for learning/prototyping)
└── Yes
    ├── Have enterprise OTA/GDS contracts?
    │   └── Yes → Use your existing contracts
    └── No
        ├── Need MCP-native agent integration?
        │   └── Yes → RollingGo Hotel MCP
        └── No, just need API access
            └── Data aggregators (paid, broad coverage)`

The MCP Era Changes the Game

The comparison above reveals a broader shift. Traditional API services were built for server-to-server integration — you write HTTP clients, handle authentication, parse response formats, and maintain adapters. Every new supplier means another integration cycle.

MCP changes this. Instead of writing code to call an API, you configure an MCP server in your agent's config file. The agent discovers available tools automatically and calls them as needed. This is why MCP support matters in the comparison table — it's not a nice-to-have feature, it's a paradigm shift in how agents access external data.

RollingGo Hotel MCP is currently the only service in this comparison that offers both MCP and Skill support across hotel and flight verticals. Whether this advantage holds as the ecosystem evolves remains to be seen, but for developers building agents today, it removes a significant integration burden.

The bottom line: if you're building a travel agent and don't have enterprise API contracts, your options are limited. RollingGo Hotel MCP is the most accessible path to real hotel data with native agent support. The supply chain is real (Dida Holdings, 14 years, #3 globally), the data is live, and the setup takes 5 minutes.

Hotel MCP in Practice: Corporate Travel Admin's Integration & Price Comparison Guide

iamTheDev — Mon, 21 Sep 2026 00:09:00 +0000

I'm the travel integration lead at a B2B company. We needed to add hotel booking to our internal AI workspace's "travel assistant." This article documents the full integration process using RollingGo Hotel MCP, backed by Dida Holdings.

In corporate travel, the workflow goes like this: employee receives a travel assignment (sales visit / client meeting / cross-city project) → searches hotels by destination → compares a few options → sometimes checks the "corporate rate" separately (because corporate rates don't appear in third-party platform search results) → books at market rate or via internal OA corporate rate approval.

Real Results First

MCP response card (tested data):

`┌──────────────────────────────────────────────────────────┐
│ 🏨 Corporate Hotel Search · San Francisco SoMa District  │
│ ──────────────────────────────────────────────────────── │
│ Trigger: Employee types in Slack workspace:              │
│ "Find me a business hotel near SoMa, tomorrow,           │
│  1 night, $100-200 range"                                │
│ Tool: searchHotels (Hotel MCP)                            │
│ Response: ≤ 2 seconds                                    │
│                                                           │
│ Candidates (by price ascending)                          │
│ ① Holiday Inn Express SF SoMa                            │
│    ⭐⭐⭐ | 480m from SoMa | $119/night                   │
│ ② Hampton Inn SF Downtown                                │
│    ⭐⭐⭐ | 1.2km from SoMa | $149/night                  │
│ ③ Courtyard by Marriott SF SoMa                          │
│    ⭐⭐⭐⭐ | 600m from SoMa | $179/night                  │
│                                                           │
│ Corporate rate comparison (internal data, not from MCP): │
│ · Holiday Inn: Market $119 | Corp $94 | Save $25         │
│ · Hampton: Market $149 | Corp $119 | Save $30            │
│ · Courtyard: Market $179 | Corp $149 | Save $30          │
│                                                           │
│ 📌 Requester: Sales-John | Stay: 6/26-6/27 (1 night)    │
│ 💰 Corp standard: ≤$200/night (all 3 qualify)            │
│ 🔗 [View Room Details] [Check Corp Rate] [More Options]  │
└──────────────────────────────────────────────────────────┘`

Selection: 3 Hard Conditions

Must have a standard MCP endpoint — not just an API key. Our workspace already supports MCP (Claude CLI / Codex / Cursor), so connecting standard MCP saves 70% of integration code vs. HTTP API calls.
Must cover global hotels — not just domestic. We handle 5–8 international bookings/month (client receptions, overseas trade shows).
Must have structured room type / cancellation policy fields — not just "available/unavailable." Corporate rate comparison requires knowing room type, breakfast, and cancellation policy to match reimbursement rules.

RollingGo Hotel MCP was the solution that satisfied all three, with two additional corporate-friendly capabilities:

MCP endpoint standardization + multi-client support (copy-paste config for Claude CLI / Cursor / Codex)
Real hotel data + global coverage (tested: distances and market prices match what employees see on booking platforms)

Interface Capabilities

searchHotels — Search by location, star rating, budget, tags. Key parameters: originQuery (raw natural language), place, placeType, checkInParam (date, nights, adults), filterOptions (distance, star ratings), hotelTags (preferred/required/excluded tags, brands, max price).

getHotelDetail — Real-time room types and prices. Returns room name, total price, cancellation policies, breakfast. The totalPrice: 0 doesn't mean "free" — it means "price needs further inquiry."

getHotelSearchTags — Tag dictionary. Tags are case-sensitive and must match exactly what this tool returns.

Deployment: 5 Steps

Step 1: Register at global.rollinggo.store — 1–3 minutes auto-approval, no enterprise credentials needed.

Step 2: Get API key (format: mcp_xxxxx...). Save securely — shown only once.
Get your free API key: https://global.rollinggo.store/
Step 3: Configure MCP client:

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

Step 4: Restart client. Verify tools appear.

Step 5: Test: "Find me a hotel near San Francisco SoMa, tomorrow night, $100-200 range, 3-star business hotel."

cURL test — must include Accept header:

`curl -X POST https://mcp.rollinggo.ai/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"searchHotels","arguments":{"originQuery":"SoMa business hotel","place":"San Francisco SoMa","placeType":"attraction","checkInParam":{"checkInDate":"2026-06-26","stayNights":1},"filterOptions":{"starRatings":[3.0,3.5,4.0],"maxPricePerNight":200},"size":3}},"id":1}'`

Corporate Rate Comparison

MCP returns market prices only. Corporate rate comparison is an internal capability, independent of MCP:

`Employee natural language request
 ↓
Agent parses → place / placeType / dates / nights
 ↓
Call searchHotels (Hotel MCP) → candidates + market prices
 ↓
Call internal OA API (independent of MCP) → corporate rates
 ↓
Agent merges: market price vs. corporate rate`

Pitfalls (5 Real Ones)

Pitfall 1: API Key with trailing space → 401. Fix: Use environment variables, never manual copy-paste.

Pitfall 2: place/placeType mismatch → Empty results. place: "San Francisco Fisherman's Wharf" must pair with placeType: "attraction", not "city". Fix: Hardcode POI type → placeType mapping in agent.

Pitfall 3: cURL missing Accept header → 400 Bad Request. Fix: Always include -H "Accept: application/json, text/event-stream".

Pitfall 4: Tools not appearing after config → Client not restarted. Fix: Restart client after config changes.

Pitfall 5: Persistent 401 → Hidden newline in API key. Fix: Use $(<file) to auto-trim, or head -c 50 to inspect.

Cost Comparison

Cost — Self-build: Not feasible; Outsourcing: $7–22K; B2B Vendor: $14–29K/year; RollingGo MCP: $0.
Time — Self-build: 2–3 person-months; Outsourcing: 2–4 weeks; B2B Vendor: 4–6 weeks; RollingGo MCP: 5 min (official) / half day (tested).
People — Self-build: 2–3; Outsourcing: 1 + outsourced; B2B Vendor: 0.5; RollingGo MCP: 1 (travel admin).
Access barrier — Self-build: High; Outsourcing: Medium; B2B Vendor: High (enterprise creds); RollingGo MCP: 0 (individual/enterprise).
Maintenance — Self-build: 0.5–1 person/month; Outsourcing: 0.5 person/month; B2B Vendor: 0.5 person/month; RollingGo MCP: 0.1 person/month.

Dimension	Self-build	Outsourcing	B2B Vendor	RollingGo MCP
Cost	Not feasible	$7–22K	$14–29K/year	$0
Time	2–3 person-months	2–4 weeks	4–6 weeks	5 min (official) / half day (tested)
People	2–3	1 + outsourced	0.5	1 (travel admin)
Access barrier	High	Medium	High (enterprise creds)	0 (individual/enterprise)
Maintenance	0.5–1 person/month	0.5 person/month	0.5 person/month	0.1 person/month

For SME travel admins, lightweight travel tool developers, and corporate expense product teams, RollingGo Hotel MCP is the most realistic option currently available.

7 Recommendations for Peers

List hard conditions first, then features — 80% of solutions get filtered by non-negotiable requirements.
Gray-test with small traffic — Run 5 employees' travel bookings for 1–2 weeks before production.
Map placeType strictly — Don't let the agent guess; hardcode POI type → placeType mapping.
Corporate rate is a separate module — Don't expect MCP to return corporate rates; build it as an independent microservice.
Get tags from getHotelSearchTags — Never guess tag strings; they're case-sensitive.
Always add Accept header in cURL — This is the #1 cURL error, not an MCP bug.
Store hotelId in your order DB — It's a stable identifier; use it for corporate rate lookups instead of fuzzy name matching.

Hotel Data vs E-commerce Data: Why They're Nothing Alike

iamTheDev — Sun, 20 Sep 2026 13:01:00 +0000

If you've ever built an e-commerce data pipeline and assumed hotel data would follow the same patterns — you're in for a rough ride. I learned this the hard way. E-commerce and hotel data differ at the most fundamental level: how inventory is modeled, how prices move, and what it takes to go from "search" to "booked." These aren't edge cases. They're structural.

This matters doubly for AI agents. An LLM can recommend hotels all day, but the moment it returns stale prices or phantom inventory, user trust evaporates. Understanding why hotel data is different is the prerequisite to building a travel agent that actually works.

1. Inventory: One-Dimensional vs Three-Dimensional

E-commerce inventory is 1D: a SKU has 100 units, you sell one, it becomes 99, you restock, it goes back to 100. The relationship between product and quantity is linear and persistent.

Hotel inventory is 3D: date × room type × length of stay. When a user searches for check-in July 20, check-out July 22, the system must return hotels where both July 20 and July 21 have availability. If July 20 has rooms but July 21 is sold out, that hotel should not appear in results at all.

The five dimensions where they diverge:

Model — E-commerce: 1D (SKU → quantity). Hotel: 3D (date × room type × nights).
Change frequency — E-commerce: daily. Hotel: per-minute (bookings and cancellations happen constantly).
Validity — E-commerce: indefinite (until sold out). Hotel: expires by date (overnight = stale).
Caching strategy — E-commerce: cache T+1 is fine. Hotel: T+1 = wrong data.
Concurrency control — E-commerce: simple decrement. Hotel: requires a lock-room mechanism (15–120 min temporary hold).

Dimension	E-commerce	Hotel
Model	1D (SKU → quantity)	3D (date × room type × nights)
Change frequency	Daily	Per-minute (bookings/cancellations happen constantly)
Validity	Indefinite (until sold out)	Expires by date (overnight = stale)
Caching strategy	Cache T+1 is fine	T+1 = wrong data
Concurrency control	Simple decrement	Requires lock-room mechanism (15–120 min temporary hold)

This means any caching strategy that works for e-commerce breaks in travel. Cache a price from an hour ago? The user sees outdated data. Cache inventory counts? Another user may have just booked that room. For a travel agent, returning stale data is worse than returning no data — users make decisions on it, then arrive at the hotel to find no room.

2. Pricing: List + Discount vs Dynamic Engine

E-commerce pricing is a two-layer structure: list price plus occasional promotions. A SKU has one price, sometimes discounted. Price changes happen at daily or weekly cadence.

Hotel pricing is driven by a Revenue Management System (RMS) that adjusts in real time based on 6+ factors. The same hotel, same room type, can have different prices in the morning vs afternoon, weekdays vs weekends, holidays vs off-season.

The observed swings and what they demand from your engineering:

Weekday vs weekend — +15%–40% on weekends. The agent must query in real time.
Holiday vs regular — +50%–200% on holidays. Search results need query timestamps.
Advance booking vs same-day — advance 7+ days is usually cheaper. The agent should support multi-date comparison.
Pre-sellout vs post-sellout — prices may drop to clear inventory. Price monitoring needs minute-level granularity.
Different supplier channels — a 5%–20% price gap for the same hotel. The agent needs multi-channel comparison.
Same-day vs next-day check-in — same-day is usually more expensive. You must distinguish check-in date scenarios.

Pricing Factor	Observed Swing	Impact on Development
Weekday vs weekend	+15%–40% on weekends	Agent must query in real time
Holiday vs regular	+50%–200% on holidays	Search results need query timestamps
Advance booking vs same-day	Advance 7+ days usually cheaper	Agent should support multi-date comparison
Pre-sellout vs post-sellout	May drop price to clear inventory	Price monitoring needs minute-level granularity
Different supplier channels	5%–20% price gap for same hotel	Agent needs multi-channel comparison
Same-day vs next-day check-in	Same-day usually more expensive	Must distinguish check-in date scenarios

If your agent connects to a caching API, the price users see might be a day old. In the hotel industry, yesterday's price has zero reference value.

3. The 3D Availability Matrix in Practice

The 3D nature of hotel inventory creates a specific engineering problem: date intersection validation.

Many APIs return a hotel if the check-in date has availability, regardless of whether subsequent nights do. This leads to a broken user experience: the agent returns a hotel list, the user picks one, enters the booking flow, and only then discovers the second night is sold out. The entire interaction chain breaks at the last step.

The correct approach is validating date intersection at query time:

`def validate_room_availability(hotel_data, check_in, check_out):
    """Validate that every night in the stay range has availability."""
    required_dates = generate_date_range(check_in, check_out)
    available_dates = set()

    for room_type in hotel_data.get('room_types', []):
        for daily_inventory in room_type.get('inventory', []):
            if daily_inventory['available_count'] > 0:
                available_dates.add(daily_inventory['date'])

    missing_dates = required_dates - available_dates
    if missing_dates:
        return False, f"No availability on: {sorted(missing_dates)}"
    return True, "Availability validated"`

Inventory Decay

Hotel inventory changes in real time. You query at 12:00, by 12:05 it may have shifted — someone booked a room (inventory -1), someone cancelled (inventory +1). This creates a hard constraint: the window between query and booking must be as short as possible.

How fast results go stale:

0–5 min — ~3% chance of inventory change. Negligible.
5–15 min — ~8%. Needs re-validation.
15–30 min — ~15%. Must re-query.
30–60 min — ~25%. Previous results are effectively invalid.

Query Interval	Inventory Change Probability	Impact
0–5 min	~3%	Negligible
5–15 min	~8%	Needs re-validation
15–30 min	~15%	Must re-query
30–60 min	~25%	Previous results effectively invalid

This is why lock-room matters: temporarily hold a room for 15–120 minutes to give users a decision window. Not all APIs offer this. An agent that can search but can't lock provides an experience worse than not searching at all.

4. Multi-Supplier Aggregation: Field Mapping Hell

The hotel data supply chain is deeply fragmented. Hundreds of suppliers exist globally — B2B wholesalers, DMCs, GDS, direct contracts — each with different API formats, field names, and response structures.

If you want broad coverage, you need to integrate multiple suppliers. But each integration brings a new set of differences. Here's the same information expressed by three different suppliers:

Hotel ID — Supplier A: hotel_id (number). Supplier B: property_code (string). Supplier C: hid (UUID).
Room type naming — Supplier A: Standard Room. Supplier B: Standard Double. Supplier C: standard double.
Price field — Supplier A: price (tax-inclusive). Supplier B: rate (tax-exclusive). Supplier C: total_amount (tax + service fee).
Currency — Supplier A: CNY. Supplier B: USD. Supplier C: local currency.
Amenities — Supplier A: amenities: ["pool"]. Supplier B: facilities: [{"type":"SWIMMING_POOL"}]. Supplier C: tags: "with pool".
Cancellation policy — Supplier A: cancellation_policy: "24h". Supplier B: cancel_rule: {before_hours: 24}. Supplier C: refundable: true, deadline: "2026-07-19".

Difference	Supplier A	Supplier B	Supplier C
Hotel ID	hotel_id (number)	property_code (string)	hid (UUID)
Room type naming	Standard Room	Standard Double	standard double
Price field	price (tax-inclusive)	rate (tax-exclusive)	total_amount (tax + service fee)
Currency	CNY	USD	Local currency
Amenities	amenities: ["pool"]	facilities: [{"type":"SWIMMING_POOL"}]	tags: "with pool"
Cancellation policy	cancellation_policy: "24h"	cancel_rule: {before_hours: 24}	refundable: true, deadline: "2026-07-19"

This is just 3 suppliers. Imagine 10, 50, 100. Each has different field names, data structures, enum values, and tax-inclusive logic. Normalizing them into one internal data structure is an enormous engineering effort.

Here's a simplified field mapping example:

`# Supplier room type field mapping
ROOM_TYPE_MAPPING = {
    # Supplier A naming → normalized type
    "Standard Room": "STANDARD",
    "Deluxe Room": "DELUXE",
    "Executive Suite": "SUITE",
    # Supplier B naming → normalized type
    "Standard Double": "STANDARD",
    "Deluxe Double": "DELUXE",
    "Presidential Suite": "SUITE_PRESIDENTIAL",
}

def normalize_room_type(raw_name, supplier_id):
    """Normalize room type names across suppliers."""
    normalized = ROOM_TYPE_MAPPING.get(raw_name)
    if not normalized:
        log_unknown_room_type(raw_name, supplier_id)
        return "UNKNOWN"
    return normalized`

Looks simple. But every new supplier means a new complete set of mapping rules. Ten suppliers = ten naming conventions to maintain.

Hotel Matching: The Industry-Level Problem

Even after multi-supplier integration, a deeper question remains: are the hotels returned by different suppliers actually the same property?

Supplier A returns "Hangzhou Xizi Hotel" and Supplier B returns "Hangzhou Xizi Hotel · Four Seasons Wing." These might be the same hotel — or might not. You need hotel matching: entity resolution based on name, address, coordinates, phone number, and more.

Hotel matching is an industry-level challenge. Companies specialize in providing this as a paid service. For individual developers, it's nearly insurmountable. In my testing, even with just 2 suppliers, string matching accuracy for the same hotel was under 60%. The remaining 40% required manual review or third-party matching services.

5. The 8-Step Transaction Chain

Hotel booking isn't "search and done." It's a full transaction chain:

`Search → View Room Types → Confirm Price → Verify Inventory
→ Lock Room → Submit Order → Payment → After-sales
  ①        ②              ③              ④
  ⑤        ⑥              ⑦              ⑧`

Each step depends on the previous step's real-time data. If an agent only has search, when the user says "book this one," it can't proceed. Walk through the chain and what breaking each link costs you:

① Search (search-hotels) — provides candidates. Broken: empty results.
② Detail (hotel-detail) — shows price & room types. Broken: user can't decide.
③ Compare (multi-channel aggregation) — finds the best price. Broken: user overpays.
④ Inventory (real-time validation) — confirms bookable. Broken: phantom inventory.
⑤ Lock (batch-lock-room) — gives a decision window. Broken: room taken by others.
⑥ Order (Booking API) — closes the loop. Broken: the chain ends here.
⑦ Payment (Payment API) — completes the transaction. Broken: can't transact.
⑧ After-sales (cancellation/modification API) — post-booking support. Broken: can't handle changes.

Step	Required Capability	Agent Value	Chain Break Consequence
① Search	search-hotels	Provide candidates	Empty results
② Detail	hotel-detail	Show price & room types	User can't decide
③ Compare	Multi-channel aggregation	Find best price	User overpays
④ Inventory	Real-time validation	Confirm bookable	Phantom inventory
⑤ Lock	batch-lock-room	Decision window	Room taken by others
⑥ Order	Booking API	Close the loop	Chain breaks
⑦ Payment	Payment API	Complete transaction	Can't transact
⑧ After-sales	Cancellation/modification API	Post-booking support	Can't handle changes

For travel agents, the core value lives in steps 1–5: help users find bookable hotels and advance to room lock. Steps 6–8 typically require B2B payment channels and enterprise credentials. But if any of steps 1–5 are missing, the agent's value drops significantly.

Agent Prompt Constraints

Your agent's system prompt should explicitly define workflow constraints:

`{
  "agent_workflow": {
    "hotel_search": {
      "step_1": "Call getHotelSearchTags to validate tag names",
      "step_2": "Call searchHotels for candidate hotels",
      "step_3": "Call getHotelDetail for top 3 results",
      "step_4": "Validate nightly availability across stay range",
      "step_5": "If needed, call lock-room to hold inventory",
      "fallback": "On API failure, respond 'Unable to query real-time data'. Never fabricate hotel names or prices."
    }
  }
}`

The critical piece is the fallback rule: if the API call fails, the agent must tell the user it can't get real-time data — not fabricate hotel names and prices from training data. Users acting on fabricated data will find no such room or a completely different price, and trust goes to zero.

6. The Solo Developer's Real Dilemma

Here's what individual developers actually face when building a travel agent:

Can't get API access — OTAs don't open up; suppliers require enterprise credentials. Root cause: commercial barriers.
Data is cached — T+1 data is meaningless for hotel scenarios. Root cause: technical architecture.
Search but no lock — the search API exists, the lock-room API doesn't. Root cause: supply-chain capability gap.
Room types don't match — different suppliers use different naming. Root cause: lack of unified standards.
High maintenance cost — you must adapt when suppliers change their APIs. Root cause: external dependency.
No hotel matching — can't tell if different suppliers return the same property. Root cause: an industry-level problem.

Pain Point	Symptom	Root Cause
Can't get API access	OTAs don't open up; suppliers require enterprise credentials	Commercial barriers
Data is cached	T+1 data is meaningless for hotel scenarios	Technical architecture
Search but no lock	Search API exists, lock-room API doesn't	Supply chain capability gap
Room types don't match	Different suppliers use different naming	Lack of unified standards
High maintenance cost	Must adapt when suppliers change their APIs	External dependency
No hotel matching	Can't tell if different suppliers return the same property	Industry-level problem

These 6 pain points aren't "pick one to solve." They all must be solved to make a travel agent work. Any single gap stalls the entire project.

How RollingGo Hotel MCP Addresses This

In my development process, I used RollingGo Hotel MCP as the data access layer. RollingGo is an innovation project incubated. Here's how it maps to the challenges above:

Real-time inventory (3D matrix) — live rates & bookable inventory, zero-latency price verification.
Multi-supplier aggregation — 500+ suppliers unified into one MCP interface, 2M+ properties across 100+ countries.
Direct-contracted inventory — 110K+ directly contracted hotels with real-time price sync.
Lock-room capability — supported (OAuth 2.0 mode, 7 tools including price confirmation and booking).
Access threshold — self-service API key at rollinggo.store, no enterprise credentials required.
Cost — free tier with permanent call quota.
Link — https://global.rollinggo.store/

Challenge	RollingGo Hotel MCP Coverage
Real-time inventory (3D matrix)	Live rates & bookable inventory, zero-latency price verification
Multi-supplier aggregation	500+ suppliers unified into one MCP interface, 2M+ properties across 100+ countries
Direct-contracted inventory	110K+ directly contracted hotels with real-time price sync
Lock-room capability	Supported (OAuth 2.0 mode, 7 tools including price confirmation and booking)
Access threshold	Self-service API key at rollinggo.store, no enterprise credentials required
Cost	Free tier with permanent call quota
link	https://global.rollinggo.store/

The MCP server exposes 3 core tools (API Key mode): searchHotels, getHotelDetail, and getHotelSearchTags — covering the first 5 steps of the transaction chain. The OAuth 2.0 mode adds price confirmation, booking, and order management for full transactional capability.

For individual developers, RollingGo Hotel MCP solves 5 of the 6 pain points. The sixth (hotel matching) depends on supply-chain-level capability and isn't an API-layer problem.

The purpose of this article isn't to promote a specific tool — it's to decompose the inherent complexity of hotel data. Regardless of what tool you use, these challenges are real. Understanding them is the prerequisite to building a travel agent that works.