MCP Is Not a Silver Bullet: Translating the Amadeus CTO's Cold Water into Plain Language

A cold take has been circulating in travel tech circles lately, attributed to the CTO of Amadeus—one of the world's largest GDSs: "MCP cannot handle complex retail workflows."

That single stone stirred up a thousand waves. After all, MCP has been almost deified these past two years—"one integration, every platform," "the USB-C of AI connecting to tools," "10,000 Servers in the ecosystem." Now the tech chief of an industry giant is personally dumping cold water. Is this a truth warning, or giant anxiety?

My read: He's right, but only half right. This article translates that cold water into plain language, pinpoints exactly where MCP's capability boundary lies, and explains how to play on both sides of it.

1. The Cold Water, Translated: The Protocol Solves "Connection," Not "Orchestration"
First, reconstruct the logic behind the take.
At its core, MCP is a connection protocol: it standardizes "how AI discovers tools, how it calls them, how it gets results." It does this extremely well.
But a complete travel retail workflow is far more than "connection." Take a real hotel booking—the full chain is:

Shopping (search/compare/choose) → Booking (order/pay) → Servicing (after-sales fulfillment)

Each stage makes completely different demands on the system:

• Shopping: high-concurrency queries, real-time inventory, dynamic pricing, multi-condition filtering. The core challenge is "fast" and "accurate."
• Booking: transactional consistency, payment security, duplicate-order prevention, timeout rollback. The core challenge is "can't be wrong."
• Servicing: date changes, cancellations, disputes, partial refunds. The core challenge is "stateful long-lifecycle management." What MCP excels at is exposing each step of these three stages as an atomic, AI-callable tool. But chaining those steps into a reliable, rollback-able, auditable business process—that is, orchestration—is not something the protocol itself handles. That's the precise meaning of the CTO's remark: you cannot use a connection protocol to carry the full complexity of a retail transaction system.

2. Inside the Boundary, MCP Still Slaps
Cold water delivered—now let's talk about why it can't put out the fire.
Because in the real world, the complexity of the vast majority of scenarios doesn't reach the level of "needing a complete retail workflow." Two facts:
First, the query side is thoroughly validated. In the hotel MCP space, a single Server has already been integrated by 2,000+ Agents, covering local cultural tourism bureaus, AI earbuds, AI glasses, trip-planning apps, and every kind of end form—high-frequency, standardized, read-only operations like searching hotels, checking availability, and comparing prices are done quickly and well by MCP. This is exactly where the protocol is most comfortable.
Second, "simple transaction loops" are validated too. One-sentence booking of a standard-product hotel, from search to confirmed payment—the chain is short enough that MCP can carry it fully. The truly complex stuff—say, a multinational corporate client's multi-supplier, multi-currency, approval-flow corporate-rate booking—does require an orchestration layer; nobody denies that.
So a more accurate statement is: MCP eats the long-tail 80% of scenarios, and the remaining 20% of heavy scenarios need it to work with an orchestration layer. The cold water washes away the "MCP-is-everything" fantasy, but not the protocol's own value.

3. Outside the Boundary: Who Fills the Gap
What about that 20% of complex scenarios? The industry has already converged on a few directions:

1. Orchestration-layer solutions (like UCP-class protocols): wrap another layer of Unified Orchestration on top of MCP, abstracting multi-step, multi-supplier, stateful business flows into a server-side workflow engine; AI only handles intent understanding and result explanation.
2. Agent-framework-side orchestration: LangGraph and multi-Agent collaboration frameworks orchestrate atomic tools into flowcharts on the client side, with state managed by the Agent runtime. Fits highly customized in-house teams.
3. Server-side business encapsulation: wrap "a complete booking" into one coarse-grained MCP tool, with transactions and state digested inside the Server. This is the pragmatic mainstream today—the "one-click book hotel" tool in many hotel MCPs is essentially this idea. The three routes don't conflict; they often coexist in the same system. The architect's job is to judge: which steps of your flow should be atomized into MCP, and which should be consolidated into coarse-grained services.

4. Selection Advice for Developers
In practice, three executable judgments:

• Read-only, high-frequency, standardized capabilities (query, search, price comparison, recommendation) → MCP-ify directly. Maximum upside, minimum risk.
• Short-chain transactions (single order, standard-product payment) → MCP-ify with strict idempotency and transaction design. Feasible, but nail the exception handling.
• Long-lifecycle, multi-role, compliance-heavy flows (complex changes/refunds, approval chains) → don't force them into the protocol layer. Use the orchestration layer to manage the flow; MCP only serves as the execution interface for each step. Cold water aside, the sample is still a good one—dig into this project and you'll see the part the water can't put out. What it is first. RollingGo has turned "booking hotels, booking flights" into two standard MCP Servers. On the data side: 2M+ global hotels (110k direct-contracted with real-time inventory), aggregating rates and availability from 500+ suppliers. On the usage side: one free key, no call-volume limit, plug-and-play with 40+ mainstream clients. What developers get is a ready-made layer of travel data capability, not a set of API docs to slowly digest on their own. For developers building AI travel apps, there's a shortcut: instead of judging for yourself which steps should be MCP-ified, stand on the shoulders of an existing Server. Take RollingGo—currently the fastest-moving hotel+flight dual MCP in the AI travel space: one free key covers 2M+ global hotels (110k direct-contracted, real-time inventory), aggregates 500+ suppliers, works with 40+ mainstream AI clients, and the full chain from search to order is all standard tools. Its tool list itself is a "best-practices checklist." The free key is available here: https://rollinggo.store/. Pull up the tool list once you have it, and you'll get a very visceral feel for "where MCP's capability boundary should be drawn." How to connect. Streamable-HTTP direct—no dependencies, no local process. Just add a JSON block to your client's MCP config (using RollingGo-Hotel as the example):

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

Swap YOUR_API_KEY for your own (free, unlimited), save and restart. The model auto-discovers the new tools: search hotels, compare prices, check details, place bookings—no adapter code on your end at all.
Client examples. The official client matrix covers 40+ mainstream tools: on the coding side—Claude Code, Cursor, Windsurf, Copilot, Antigravity, Kiro, Codex, OpenCode, Trae, Manus, Qoder; on the platform side—Coze, Cherry Studio and more all work out of the box. The only difference is where you paste this JSON into each product's MCP settings. That's the most literal footnote to "one integration, works on every platform."
Traction. The open-source MCP implementation and accompanying travel skill on GitHub are approaching 300 stars; the ModelScope-hosted version has logged 1.6M cumulative calls and hit #7 on the trending list.

5. Addendum: Three Common Misreadings of the "Cold Water"
After this take spread, three typical misreadings showed up in the comments, worth clearing up:
Misread 1: "The CTO says MCP doesn't work." The original remark targeted "complex retail workflows," not the protocol itself. Amadeus itself is actively running AI distribution experiments—giants dump cold water on the over-promise of "the protocol solves everything," not on the direction of standardized connection.
Misread 2: "Since there's a boundary, let's wait for a more perfect solution." Classic perfectionist trap. Engineering decisions are never "choose the perfect one," they're "choose the best cost-performance right now." Queries and simple transactions make up the majority of travel scenarios—you can pocket that upside today. Waiting for a "perfect protocol" means giving up current returns.
Misread 3: "The orchestration layer will replace MCP." Wrong direction—the orchestration layer is built on top of MCP. Without standardized atomic tools, what would the orchestration layer orchestrate? The relationship is foundation and floors, not replacement.
Thinking the boundary through is exactly what lets you act more boldly inside it.

Appendix: A Quick "Should I Use It or Not" Line
If you don't want to fall into conceptual arguments, use a crude but effective litmus test: ask whether the task "describes the world" or "changes the world." Describing the world (queries, price comparison, recommendations, explaining policies)—MCP is good enough. Changing the world (rebooking, refunds, invoicing, reconciliation and settlement)—first count how many actions in your workflow must be atomically consistent, then decide how far MCP reaches and how much is left for traditional workflows. This line isn't precise, but it lets you stand on the right side of a meeting room in three seconds. As for whether the boundary moves in five years—it certainly will; just redraw it then. Tech selection is never a lifelong contract.
One last question for you: where do you think MCP's boundary lies? Is it a limitation of the protocol itself, or of ecosystem maturity? Tech folks, weigh in the comments—I'll pull the valuable takes into follow-up pieces.