Abrar’s take: Predictions and viewpoints based on 24+ years operating and investing in travel. Dated September 2026. Counts are snapshots from my working directory, not a market census. I update when wrong.
Travel is AI-ready, but the MCP supply chain isn’t. Companies that ship a scoped MCP server this year learn how AI assistants discover, invoke, and transact against their services — while the category is still unstandardized. Waiting means conceding that learning to whoever builds first.
Why MCPs are business development, not just tech
Answer first: treat an MCP server the way you treat an API — as distribution. It turns your capabilities into AI-native surface area: an assistant can discover your tools and call them at runtime. That’s a new channel to manage, not just a feature to ship.
MCP vs API: what actually changes
Fact: MCP is an open standard introduced by Anthropic, with JSON-RPC messaging and tools / resources / prompts per the MCP specification. In practice MCP wraps your API; it doesn’t replace it.
| Primitive | Role | Travel example |
|---|---|---|
| Tools | Executable functions; can change state | search_flights, create_order, cancel_booking |
| Resources | Read-only context | Schedule, fare rules, destination guide |
| Prompts | Reusable instruction templates | plan_trip, check_travel_requirements |
My prediction: MCP will become the default conduit for AI-initiated travel interactions — the discovery and action layer on top of NDC/GDS/REST, not the transaction rail itself. We are not there yet. Travel still transacts on existing rails; MCP is the adapter agents will prefer.
Mapping the landscape
My working list: 18 travel MCPs I’m tracking — my definition of table stakes.
I count 18 that meet my bar in my Travel MCP Server Directory (last checked September 21, 2026): a provider-published MCP endpoint or maintained travel-focused repo, with identifiable transport and travel tools — including official servers like Booking.com, Sabre, TourRadar, Peek, and Expedia Group, plus hosted and open-source entries like Travala, trvl, and FlyAI. Cross-checked against the community Travel & Transportation MCP list.
Treat this as a snapshot, not a census — listings churn, prototypes stall, and “MCP available” does not mean “bookable.” My table-stakes bar: search + offer detail + one transaction or servicing action, with auth documented. Few meet all three today, which is exactly the opening.
Launching an MCP: scope and prerequisites
Launching your own MCP lets AI systems use your services across booking, research, and automation workflows (B2B and B2C). It is not turnkey. Before you build, ensure: clear ICP and product-market fit; a monetizable use case and transaction flow; a distribution hypothesis for how AI will surface your MCP.
Tech baseline and constraints
Constraints exist — latency, context windows, and guardrails — but a scoped pilot compounds learning. Start with 3–6 tools maximum (2–3 reads, 1 write, 1 status lookup), with OAuth 2.1, per-session scoping, idempotency keys for booking tools, logging, and rate limits.
Near-term use cases and future state
Current use cases cluster around dynamic itineraries, pricing, and booking — see Travel MCP Use Case Examples. My prediction from this April 2026 post: within 12–18 months (by late 2027), AI concierge that plans and books end-to-end will become table stakes. Start building now to shape the workflows and data structures that matter. What would prove me wrong: assistants keep third-party routing closed, or MCP adds cost without incremental conversion over links and APIs.
Why build: distribution and revenue
My thesis on distribution: early, well-placed servers get a discovery and learning advantage while the category is unstandardized — fewer custom integrations per assistant, faster partner trials, input into emerging tool patterns. That is not a permanent moat. Platforms control ranking and routing, and liability still sits with the underlying API. For background on why the API remains the commercial foundation, see Stop Treating Your API Like a Tech Project.
Patterns you can ship today
- B2B distribution: offer as an MCP the way you offer APIs, for pre/during/post-trip planning, recommendation engines, and booking.
- Consumer AI connectors: be the “plugin” for chat models — prioritize discoverability and seamless install.
- Niche verticals: religious-tour MCPs and experience MCPs that let AI book tours, tickets, and excursions with pricing and availability in one flow.
Governance risks (read before you ship)
MCP tool outputs and tool descriptions can carry prompt-injection / tool-poisoning payloads; new servers commonly default to no auth (Microsoft, WorkOS). Require OAuth 2.1 with short-lived scoped tokens, least-privilege per-session tool access, human approval for spend or PNR changes, and full audit logs. My view, not a security audit.
Caveats
- Don’t build without clear ICP, transaction flow, and AI use cases.
- Don’t treat MCPs as a vanity channel; they magnify existing strengths.
- Start narrow, prove value, then expand scope.
Subscribe for the Travel MCP Playbook + implementation templates.
90-day evaluation framework
Days 1–30: Define one transaction. Pick one ICP and one job. Write the distribution hypothesis in one sentence: which assistant, which user moment, why MCP instead of a link or API? Stop if there is no monetizable flow or dispute owner.
Days 31–60: Ship a scoped pilot. 3–6 tools max. Implement auth, scoping, logging, rate limits. Test with two MCP clients. Measure completion rate, parameter-error rate, p95 latency, cost per completed task, approval rate.
Days 61–90: Decide. Continue only if completion meets your servicing bar, errors fall with schema fixes, unit cost is sustainable, and a partner commits to routing. Otherwise keep the REST API as system of record. My prediction: by end-2027, most mid-size+ sellers will consume or offer at least one MCP — if routing opens and pilots clear these gates.
FAQ
Is an MCP a replacement for our API? No — keep the API as the system of record and add a thin MCP layer over the same backend for model callers.
What should v1 expose? Search plus one gated write action — for example flight or hotel search, offer detail, and booking with human approval — plus order lookup.
What is the biggest operational risk? Unauthenticated or over-permissioned tools combined with prompt injection. Require OAuth 2.1, least-privilege scoping, approval for spend or PNR changes, and full audit logs.