Building the First Airline MCP Server for Agent-Based Customer Interactions
turkish_airlines · Other · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.5 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: airline customer-service agents
Turkish Airlines wanted customers to interact with flight search, bookings, check-in status, baggage, promotions, and profile data through natural-language agents instead of complex airline forms, while keeping enterprise security and governance acceptable.
Constraints:
- Airline customer interactions involve sensitive booking, profile, and flight-availability data.
- MCP authentication support was immature when the team began, and existing enterprise OAuth mechanisms did not support the newer OAuth/OAT 2.1 requirement.
- The initial production release had to avoid exposing write operations that could create safety, fraud, or customer-service risk.
- The team needed to prevent scraping of flight availability data.
- Enterprise MCP adoption also had to fit internal security constraints around cloud LLM use.
Architecture
Turkish Airlines built an end-user-focused MCP server that exposes read-only airline tools over existing mobile and web APIs, authenticates users through the Miles&Smiles frequent-flyer program, implements the newer OAuth/OAT layer in the MCP server, and uses Cloudflare Workers/Agent SDK plus rate limiting by frequent-flyer ID. It also runs internal TakeAI GPT on on-prem GPU infrastructure with MCP support for enterprise tools.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR llm-client-platform["LLM client platform"] --> turkish-airlines-mcp-server["Turkish Airlines MCP server"] turkish-airlines-mcp-server --> oauth-authentication-layer["OAuth authentication layer"] oauth-authentication-layer --> frequent-flyer-identity["frequent flyer identity"] frequent-flyer-identity --> rate-limiting-policy["rate limiting policy"] turkish-airlines-mcp-server --> cloudflare-security-layer["Cloudflare security layer"] cloudflare-security-layer --> rate-limiting-policy turkish-airlines-mcp-server --> existing-mobile-and-web-apis["existing mobile and web APIs"] existing-mobile-and-web-apis --> read-only-airline-tools["read-only airline tools"] rate-limiting-policy --> read-only-airline-tools read-only-airline-tools --> booking-link-generator["booking link generator"] booking-link-generator --> llm-client-platform takeai-gpt["TakeAI GPT"] --> on-prem-gpu-models["on-prem GPU models"] takeai-gpt --> enterprise-mcp-connectors["enterprise MCP connectors"]
Components
| Component | Role | Interacts with |
|---|---|---|
LLM client platform |
Accepts the user's natural-language travel request and calls the MCP tools. | Turkish Airlines MCP server |
Turkish Airlines MCP server |
Exposes airline customer-service tools to external agent clients. | OAuth authentication layer, Cloudflare security layer, existing mobile and web APIs, read-only airline tools |
OAuth authentication layer |
Authenticates end users through the Miles&Smiles frequent-flyer program. | frequent flyer identity, Turkish Airlines MCP server |
frequent flyer identity |
Provides the authenticated user identity used for profile access and rate limiting. | rate limiting policy, OAuth authentication layer |
Cloudflare security layer |
Hosts or supports the OAuth implementation and security controls around the MCP server. | rate limiting policy, Turkish Airlines MCP server |
rate limiting policy |
Limits flight-availability access per frequent-flyer ID to reduce scraping risk. | read-only airline tools |
existing mobile and web APIs |
Provide production-tested airline API surfaces behind the MCP proxy. | read-only airline tools |
read-only airline tools |
Expose flight search, flight status, booking details, check-in eligibility, promotions, city guides, and profile data. | booking link generator |
booking link generator |
Returns a traditional booking link with selected flight information prefilled. | LLM client platform |
TakeAI GPT |
Internal ChatGPT-like platform for employees using on-premise models and MCP integrations. | on-prem GPU models, enterprise MCP connectors |
on-prem GPU models |
Host internal LLMs such as Qwen/Q3 without sending employee data to cloud LLM providers. | TakeAI GPT |
enterprise MCP connectors |
Connect internal assistant workflows to tools such as Jira and Confluence. | TakeAI GPT |
Data flow
A user asks an LLM platform a travel question; the platform invokes the Turkish Airlines MCP server; the user authenticates with a frequent-flyer ID; Cloudflare and the MCP OAuth layer secure the request; the MCP server proxies existing mobile/web APIs for flight search, booking details, check-in status, promotions, city guides, and profile data; the agent returns answers or a prefilled booking link while write flows remain future work.
3 supporting quotes
Why this architecture
The MCP server lets Turkish Airlines meet customers inside agent platforms while limiting blast radius: it reuses existing app APIs, authenticates end users, puts Cloudflare controls in front, and starts with read-only flows before moving toward check-in, disruption handling, and UI-rich operations.
3 supporting quotes
Models used: Qwen/Q3 · on-premise LLMs
Scale
- Turkish Airlines reports more than 500 aircraft, with a target of 800.“currently we have like 500 plus aircrafts and we aim to be uh increasing that to 800”transcript, stated
- The transcript reports around 9 million passengers annually.“we carry around 9 million passengers annually.”transcript, stated
- Development started one or two weeks after the OAuth/OAT specification release and the MCP was fully live at the time of the talk.“after the oath specification was released I think uh after one or two weeks later we started uh how we can build this MCP.”transcript, stated“So it is fully live you can test it out today. It is not a like demo thing.”transcript, stated
- The roadmap includes transactional check-in and disruption-management flows beyond the initial read-only release.“we are currently working on check-in flows.”transcript, stated“when there's a disruption we automatically uh suggest new uh flights to our customers and we are working if we can do this through our MCP.”transcript, stated
Alternatives considered (roads not taken)
Connect MCP directly to core airline booking systems.
Rejected because: The team proxied existing mobile and web APIs to avoid new direct access to core booking systems.
Wait for existing enterprise OAuth infrastructure to support OAuth/OAT 2.1.
Rejected because: Waiting was expected to take almost a year, so the team implemented the OAuth/OAT layer in the MCP path using Cloudflare examples.
Launch with write/transactional airline operations.
Rejected because: The initial launch kept tools read-only because check-in, seat selection, and disruption handling introduce additional security challenges.
Use external cloud LLMs for all internal enterprise workflows.
Rejected because: Turkish Airlines built on-prem GPU infrastructure to avoid compromising security when employees use LLMs.
Patterns
tool-use-orchestration (agent architecture)
The MCP server exposes discrete airline tools for flight search, status, booking detail lookup, check-in eligibility, promotions, city guides, and profile access.
safety-policy-enforcement (security)
The first production release limits capabilities to read-only flows and requires user authentication before accessing personal airline data.
guardrails-io-filtering (security)
The MCP layer uses Cloudflare security controls and rate limiting by frequent-flyer ID to prevent flight-data scraping.
privacy-preserving-processing (enterprise ai)
For internal employee use, Turkish Airlines runs on-premise GPU models and a ChatGPT-like platform to avoid sending sensitive enterprise data to cloud LLM providers.
Tradeoffs
Proxy existing app APIs through MCP.
Chose Existing mobile and web APIs over New direct access to core airline booking systems.
Rationale: The proxy approach reused vetted API surfaces and reduced security risk while allowing faster MCP launch.
Start with read-only MCP tools.
Chose Read-only flight and profile operations over Transactional booking, check-in, or disruption actions at launch.
Rationale: Read-only scope lowered security risk while the team prepared more sensitive flows.
Rate-limit by authenticated frequent-flyer ID.
Chose Per-user throttling tied to frequent-flyer authentication over Unauthenticated public flight-data access.
Rationale: The team wanted to prevent scraping of flight availability while still serving legitimate end users.
Run internal LLM tooling on-premise.
Chose On-prem GPU models and TakeAI GPT over Cloud LLMs for employee data.
Rationale: The organization viewed cloud LLM use as difficult in enterprise settings and prioritized security for internal data.
Gotchas (what bit them)
New MCP security concerns slowed enterprise acceptance.
Root cause: MCP was new, and a contemporary GitHub MCP data exposure incident made security stakeholders wary.
Resolution: Reuse existing APIs, require authentication, add Cloudflare security, rate-limit access, and keep flows read-only at first.
3 supporting quotes
Existing enterprise OAuth/OAT mechanisms lagged the MCP auth standard.
Root cause: OAuth/OAT 2.1 was relatively new and unsupported by existing authentication infrastructure.
Resolution: Implement the needed auth layer in the MCP path using Cloudflare Worker/Agent SDK examples.
MCP UI support limits airline UX for visual workflows.
Root cause: Seat maps and similar airline tasks do not fit well as plain text.
Resolution: Wait for MCP clients to support UI rendering and plan to return visual components when available.
Enterprise MCP management remains harder than expected.
Root cause: Adding multiple MCP servers into enterprise applications creates centralized management needs.
Resolution: The speaker says they need a better way to centrally manage MCP integrations.
Evaluation
The talk reports production live status and demonstrates use cases, but does not provide a formal quantitative evaluation of MCP user success, latency, or conversion.
Metrics: 500+ aircraft, target 800 · Around 9 million passengers annually in transcript · Fully live MCP, not a demo · Initial read-only tool scope · No formal user-success metric disclosed
3 supporting quotes
Outcomes
- The MCP server is described as fully live and testable, not a demo.
- Users can ask natural-language questions about flight search, booking status, check-in eligibility, baggage, promotions, city guides, and frequent-flyer profile data.
- The team also built Takeoff UI MCP and internal TakeAI GPT with enterprise MCP integrations.
The airline context includes 500+ aircraft, an 800-aircraft target, and passenger-scale operations; the MCP-specific metrics disclosed are live status, read-only scope, frequent-flyer auth, and roadmap items.