The short version: the Model Context Protocol (MCP) standardizes how an AI application finds and calls outside capabilities. It does not, on its own, make a multi-step business process such as a travel booking transactional, recoverable, auditable or safe. You still have to design those properties yourself.
One caveat first. A DEV Community article by Becky_dev (September 30, 2026) attributes the line “MCP cannot handle complex retail workflows” to the Amadeus CTO. That page gives no name, date, interview or primary link, and I could not find an original Amadeus statement. Treat the phrase as that article’s paraphrase, not a verified quote. The engineering point behind it still stands, and it is worth separating from the headline.
As an Amazon Associate I earn from qualifying purchases.
What MCP does, in plain terms
Think of MCP as a shared plug shape. An AI client and a server agree on how to list what the server offers and how to call it. The server overview describes three core primitives: prompts, resources and tools. (That page is marked draft, so use it as conceptual background, not as the authority on the current version.)
That agreement cuts down on custom connector code. It does not define your business rules. It does not say what “booked” means, who may approve a payment, or what happens if step three of five fails. A server can follow the protocol perfectly and still expose a badly designed booking tool.
#1 Best Overall
Protocol quality is also separate from the quality of particular servers, clients, models and deployments. A weak result in one product says little about the specification, and a conformant implementation says little about whether it is safe to hand money-moving actions to a model.
Reading versus changing state
The useful distinction in travel retail is between looking and committing. This is an engineering analysis, not a restriction in the protocol.
| Operation type | Examples | What you must design |
|---|---|---|
| Read / search | Search flights, check hotel availability, fetch fare rules | Result freshness, rate limits, relevance, how results are trimmed for the model |
| State-changing | Book, pay, modify, cancel, partial refund | Authorization, user confirmation, duplicate-action protection, failure recovery, reconciliation, audit trail |
Searching is comparatively bounded: a wrong or repeated query is usually cheap. A booking sequence is different. If the model calls “hold seat,” then “charge card,” and the second call times out, you need to know whether the charge happened, whether retrying double-charges, and who cleans up the held seat. A tool-call protocol does not answer those questions. Your application or server logic does.
What the application still owns
- Transaction boundaries: which steps commit or roll back together, and what compensating action undoes a completed step.
- Idempotency: a retried call must not create a second booking or charge.
- State: where the booking-in-progress lives and who is the source of truth.
- Authorization and consent: who may do what, and when a human must confirm.
- Recovery: what happens after partial failure.
- Auditability: a record of what was requested, approved and executed.
These are design requirements. None is automatically guaranteed by a tool-call protocol.
Three ways to build complex workflows on MCP
The source article’s “connection versus orchestration” framing maps onto three implementation choices. They are not protocol-defined modes and they are not mutually exclusive.
1. Orchestrate atomic tools in a runtime
An agent or workflow engine calls small tools (search, hold, pay, confirm) and owns the state between them. You get flexibility and visible steps, but the runtime must handle retries, rollback and approvals, and more control sits with model-selected tool calls unless you constrain the sequence in code.
2. Expose a coarse-grained operation on the server
A single tool such as “book itinerary” runs the larger business transaction internally, where the system that owns the data can apply real transactional guarantees. This reduces model-driven mistakes and latency from round trips, but it hides steps from the model, is less flexible, and puts more responsibility on the server’s design.
3. Hybrid
Let the model explore with fine-grained read tools, then hand off commitment to a server-side operation guarded by explicit user confirmation. Many consequential workflows will land here.
| Axis | Runtime orchestration | Server-side encapsulation | Hybrid |
|---|---|---|---|
| Transaction boundary and rollback | Built by you in the runtime | Inside the owning system | Reads are loose; commit is inside the server |
| State ownership | Runtime | Server | Split by phase |
| Confirmation and authorization | Runtime gates each step | Gate before the single call | Gate before the commit call |
| Audit trail | Assembled across steps | Centralized at the server | Both |
| Failure handling | Compensation logic you write | Handled internally | Handled at commit |
| Latency | More round trips | Fewer | Mixed |
| Model control | Highest | Lowest | Bounded |
So “the orchestration layer will replace MCP” is also a misreading. They sit at different levels: MCP is the connection surface, and orchestration is how calls over it are sequenced and governed.
Rank #4
- Book - powershell for sysadmins: workflow automation made easy
- Language: english
- Binding: paperback
What the 2026 protocol updates change
Stateless core does not mean stateless business processes
On July 28, 2026, the maintainers announced revision 2026-07-28 in The 2026-07-28 Specification. It describes a stateless protocol core, header-based routing, cacheable list results, authorization hardening, an extension framework, and Tasks as an extension for long-running work. Lead maintainers David Soria Parra and Den Delimarsky write: “Dropping the protocol-level session doesn’t force your application to be stateless.” Their guidance for continuity is: “If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument.”
In practice, a booking flow can return a quote or cart ID that later calls reference. The state exists, but it is explicit and owned by your application rather than hidden in a transport session. That is a good fit for the idempotency and audit needs above, though the protocol still does not supply them for you.
Recommended Free Tools
Large tool catalogs have a cost
The maintainers’ August 22, 2026 roadmap calls out another practical problem: big tool catalogs consume model context, and tool selection tends to get worse as the catalog grows. This is a runtime and tool-surface concern, not a fixed MCP limit. A retail platform exposing hundreds of fine-grained operations will feel it, which is another argument for coarse-grained or hybrid designs and for exposing only the tools a given task needs.
What not to repeat as fact
The source article also makes claims about a specific hotel-data provider, including hotel counts, direct contracts, supplier numbers, client compatibility, pricing and call limits, and popularity. Those are the article’s statements. Check a provider’s current documentation before relying on them. Likewise, the description of Amadeus as one of the world’s largest GDSs was not independently verified here, and no verified adoption or travel-market statistic backs this discussion.
Quick Recap
A practical selection test
- Which operations change state? List them. Everything else can usually stay as simple read tools.
- Who owns state and approval? Decide whether the runtime, the server or the user holds the booking-in-progress and gives the final yes.
- What happens after partial failure? Walk through a timeout after payment but before confirmation. If the answer is “the model will figure it out,” move that step behind a server-side operation with idempotency keys and a clear compensation path.
- Can you audit it? Make sure you can reconstruct who requested and approved each state change.
- How big is the tool surface? Trim it so the model is not choosing among dozens of near-duplicate tools.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
