Blog
Travel MCP server for ancillaries: lounge, eSIM, insurance for AI agents
AI travel agents are getting good at planning itineraries. The harder product problem is fulfillment: attaching insurance, connectivity, lounge access, and airport services once a flight exists—without stuffing a booking-widget upsell into every chat turn.
A travel MCP server (Model Context Protocol) is how you give those jobs to the agent as tools. This guide is for B2B builders of AI travel agents and OTAs. It is not about Mobile Passport Control (CBP’s “MCP” program)—that SERP collision is real; name the protocol when you write docs and titles.
What “travel MCP” should mean for builders
Model Context Protocol lets a host (Claude, Cursor, ChatGPT, custom agents) discover and call tools over a standard session. For travel, that usually starts with search and booking surfaces. Ancillaries are the next layer:
| Job the traveller still needs | Typical tool shape |
|---|---|
| Cover for cancellation / medical / bags | insurance.quote → book |
| Data while abroad | esim.plans → activate |
| Layover comfort | anc.lounge.search → book |
| Security queue | fasttrack.book |
| Entry rules / eVisa eligibility | visa.check |
Flights stay with your air API of choice. The MCP shelf covers everything that is still “ancillary” after the ticket.
For a longer product framing—fulfill the trip, don’t only plan it—see Build an AI travel agent that fulfills ancillaries.
A layover session in practice
A 4-hour connection at CDG 2E is a normal first demo. Same token, two tools:
anc.lounge.search { airport: "CDG", terminal: "2E", date: "2026-10-14", stay_hours: 4 }
esim.plans { country: "FR", days: 7, data_gb: 5 }
The agent presents supplier-priced options, waits for an explicit yes, then books with an Idempotency-Key so retries do not double-issue. Marketing copy still uses [SUPPLIER], [PRICE], and [N] where a live catalog figure is not public.
Deep-dive on connectivity tooling: eSIM API for AI agents. Lounge-specific routing: Airport lounge API for agents.
One key: explicit supplier or routed job
Call a supplier by name and that supplier runs. Call a routed tool such as anc.lounge.search and the platform walks a credential ladder: your contract, then a stored secret, then a verified public route, then the marketplace key—billed only on that last rung. Routed responses should name who answered (X-Anc-Served-By in Ancilair’s headers).
Strict inputs matter more for agents than for humans: declared parameters only, 422 before anything hits a supplier, so a bad call is never a billed call.
MCP vs REST vs CLI
| Surface | When builders pick it |
|---|---|
| MCP | Chat / IDE agents that already speak tools |
| REST | Headless backends, CI, multi-tenant OTA workers |
| CLI | Local playbooks, ops, skill packaging |
Same catalog and token model across surfaces reduces “we integrated MCP but ops still curls a different API.” Ancilair lists install patterns for Claude, Cursor, and other MCP clients at ancilair.com; the MCP endpoint is https://mcp.ancilair.com.
After flights: who books the rest?
If you already book air with a modern flights API (for example Duffel), seats and bags often stay in that air stack. Lounge, eSIM, insurance, and fast track are a different supplier map. See After Duffel: who books lounge, eSIM, and insurance?.
Checklist before you ship a travel MCP shelf
- Name tools by job, not only by vendor (
insurance.quotevs opaque SKUs). - Quote cost before the call; refuse empty-balance with a recoverable error (e.g. HTTP 402 + top-up URL).
- Idempotent bookings for anything that issues a voucher or policy.
- Audit: call id, settled cost, supplier, cache state.
- Playbooks (
SKILL.md+ tool list) so teammates install a layover recipe without seeing keys.
A printable version of the shelf decision lives in Insurance vs a multi-ancillary shelf (email-gated checklist).
Sources
- Ancilair — product positioning, MCP / REST / CLI surfaces
- Model Context Protocol specification — protocol standard
- Duffel documentation — air offers, bags/seats as available services (not lounge/eSIM)
Not legal, immigration, or insurance advice. Supplier coverage, eligibility, and airport programs change; verify against the live catalog and supplier terms.
Questions
- Is “MCP travel” the same as Mobile Passport Control?
- No. Mobile Passport Control is a US CBP airport program. Here MCP means Model Context Protocol—the open standard for giving AI agents tools. Prefer search phrases like “travel MCP server” or “Model Context Protocol travel ancillaries” when you mean agent tooling.
- What can a travel MCP server expose beyond flights?
- Non-ticket ancillaries your agent still needs after a PNR exists—insurance quotes, eSIM plans, lounge search, security fast track, transfers, and entry-document checks. Flight GDS or NDC APIs remain the source of truth for the ticket.
- Does Ancilair mark up supplier rates on MCP calls?
- The hosted marketplace is built to pass through the supplier’s own rate, with the price quoted before the call. Figures that are not public stay as placeholders such as [PRICE].
- Where do supplier credentials live?
- Credentials are injected on the server and are not meant to reach the agent’s machine. You can also register your own supplier contract so calls run on your key unmetered.