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.
Top comments (0)