Direct answer: NDC is an airline Offer and Order data standard. A GDS is a distribution intermediary. MCP is a general AI-to-systems connectivity protocol. They are not substitutes. Before a UK travel company lets an AI agent shop or order airline content, get those layers straight — or you will fund the wrong work in the wrong order.
That is the operator question Kaize is answering here. We are a UK AI product studio for travel and hospitality. We do not sell a GDS seat, an NDC certification badge, or an MCP product. We care about the systems sequence: what content you can actually buy, where the booking file lives, who is allowed to write, and only then how an AI agent is allowed to touch the pipe.
Industry commentary has started to blur the terms. Travel Distribution News put it plainly in June 2026: treating NDC, GDS and MCP as interchangeable leads to bad commercial decisions. Vendor announcements such as TPConnects’ March 2026 MCP layer on its Astra NDC gateway show why the confusion spiked — MCP is arriving *on top of* NDC, not instead of it.
The budget problem is layer confusion, not “more AI”
Most UK tour operators, TMCs and travel tech teams do not fail AI projects because the model is weak. They fail because the budget meeting bought a slogan.
- “We need NDC” when the real gap is a join between booking and CRM.
- “We need MCP” when the real gap is Offer/Order content that an agent could even call.
- “We need AI distribution” when nobody has named which system is allowed to create or change an order.
Layer confusion is expensive because each layer has different owners, contracts and failure modes. Buying an AI access layer before you can retail offers cleanly is how you get a fluent demo that cannot survive a partial cancel. That is the same production gap we described in what usually breaks when travel AI leaves testing.
What NDC is — and is not
IATA describes NDC (New Distribution Capability) as a data exchange format based on Offer and Order management for airlines to create and distribute relevant offers regardless of channel. It is an XML-based transmission standard under an industry program — open for third parties to implement — not a marketplace, not a GDS, and not “AI”.
In operator language: NDC is the language for richer airline shopping and ordering (dynamic offers, ancillaries, a move toward Offer/Order rather than fares-plus-ticket folklore). Channels — GDS, aggregator, direct connect — can choose to speak it.
- NDC is a content and messaging standard for airline retailing.
- NDC is not, by itself, a sales channel.
- NDC does not automatically give your AI agent identity, authority or a safe write path.
IATA’s own materials and the NDC developer entry point are the right primary sources when someone in a vendor call claims otherwise.
What a GDS is
A GDS (Global Distribution System — Amadeus, Sabre, Travelport and their ecosystems) is intermediary infrastructure that connects airline content to agencies and corporate tools. It is a channel and a commercial relationship, not a schema.
This is where the “NDC will kill the GDS” story goes wrong. As Travel Distribution News notes, NDC changes what content can move through an intermediary; it does not delete the need for distribution intermediaries. GDSs have built NDC capability into their own stacks. An airline can run NDC through a GDS, through an aggregator, or direct. Standard and channel are separate decisions.
For a UK seller, the practical question is rarely “GDS or NDC?” It is “which channels do we sell through, which standards do those channels actually expose to us, and which system of record captures the resulting order?”
What MCP is
The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems — data sources, tools and workflows. The docs use a USB-C analogy on purpose: MCP standardises how an AI app plugs into systems. It is not a travel industry distribution standard, and it does not define airline Offer/Order payloads.
When travel tech vendors talk about MCP, they usually mean an access and orchestration layer that lets AI agents call capabilities that already exist underneath — including NDC gateways. TPConnects’ announcement frames MCP as sitting above NDC APIs to normalise schema fragmentation for AI-ready interfaces. That is a connectivity claim. It is not proof that MCP replaces NDC, and it is not a reason to skip content, joins or write controls.
Why “MCP instead of NDC” is the wrong sequence
If your AI agent has a clean MCP pipe into a messy or incomplete Offer/Order surface, you have not accelerated retailing. You have accelerated the rate at which the agent can ask the wrong system the wrong question.
- MCP without usable Offer/Order content → the agent has nowhere truthful to shop.
- MCP without a named booking system of record → the agent cannot place a durable order you can service.
- MCP without identity and authority gates → the agent can propose writes nobody approved — the failure mode we map in how travel companies should control AI agents.
Sequencing is the product decision. Finish (or deliberately scope) the content layer you need. Then fix the joins. Then define agent identity and human confirmation on order changes — including the rebooking discipline in what AI can prepare and what humans must confirm. Only then expose a narrow MCP (or any AI tool) surface.
What still breaks when the AI pipe is clean but the booking/CRM join is not
A fluent agent that can “see” airline offers still fails the commercial day if passenger, PNR/order id, payment state and CRM timeline disagree. That is not an MCP bug. It is the same systems problem as connecting booking systems and CRM without a second system of record.
- Offer selected in the agent, order id only in the NDC gateway, passenger profile only in the CRM.
- Partial fail on pay or ticket with no single owner for recovery.
- Servicing staff re-keying because the agent transcript is not a booking file.
Kaize’s stance on build versus buy fits here: buy the content and connectivity seats you cannot economically own; build the join and control plane no vendor will own for you.
Kaize sequencing: content → joins → agent identity/authority → then AI access
The wider map of where software and AI belong sits on AI for travel: a practical guide. For airline content specifically, we recommend this order:
- Content: which offers can you actually shop and service (NDC and/or legacy), through which channels?
- Joins: which system is the booking/order system of record, and how does CRM receive identifiers without becoming a second file?
- Identity and authority: which agent identities exist, what may they read, what may they draft, what requires a named human before write?
- Access: only then expose MCP or equivalent tool interfaces to that bounded surface.
Skip a step and the demo still looks clever. Production will teach you the missing step at customer cost.
A practical pre-MCP checklist for UK operators
Before you fund an “AI-ready distribution” workstream, write answers an engineer and a commercial owner can both sign:
- Which channels and standards produce the offers we sell today (GDS EDIFACT, GDS NDC, aggregator, airline direct)?
- For each path: can we create, pay, ticket/order, change and refund with a single durable id?
- Where does that id live, and what does CRM store instead of copying the whole file?
- Which write actions are forbidden to any AI agent without human confirmation?
- If the MCP (or chatbot) vendor disappears tomorrow, do we still have Offer/Order access through a non-AI path?
If you cannot answer those on one page, you are not ready for an AI access layer. You are ready for content and join work.
Frequently asked questions
Is NDC a replacement for the GDS?
No. NDC is a data standard for richer Offer/Order exchange. A GDS is a distribution intermediary. NDC content can move through a GDS, an aggregator or a direct connection. Standard and channel are separate choices.
Is MCP a travel distribution standard?
No. MCP is a general protocol for connecting AI applications to external systems. Travel vendors may expose NDC or other APIs through MCP. That does not make MCP a substitute for NDC schemas or for IATA’s Offer/Order model.
Should we wait for MCP before investing in NDC?
Usually the opposite. If you need richer airline offers and order servicing, that is an NDC/content problem. MCP may later change how an AI agent calls that surface. It does not invent the surface.
Where should AI agents be allowed to write?
Only where identity, scope and human confirmation are explicit — especially for booking changes, refunds and anything that creates a new commercial obligation. See Kaize’s agent-control and rebooking pieces for the control pattern.
Does this article recommend a specific GDS, aggregator or MCP vendor?
No. Kaize is describing layers and sequence. Vendor selection is a separate commercial decision once the layer map is honest.
Is this legal or regulatory advice?
No. Distribution contracts, passenger rights and data protection obligations remain with your counsel and compliance owners. This page is about systems sequencing for operators and travel tech teams.