When Kiwi.com released their MCP server earlier this month, it became one of the first examples of agentic travel booking. This post covers how we helped them build it, what we optimized, and where we think there’s still room to improve.
If you'd like to try it out, the install guide is here: https://mcp-install-instructions.alpic.cloud/servers/kiwi-com-flight-search
Why MCP instead of APIs or scraping?
Scraping the UI: brittle, slow, and expensive (cookie banners, custom date pickers, JavaScript quirks).
Direct APIs: better, but not designed for LLMs. Hundreds of endpoints return too much irrelevant data, flooding context windows.
MCP provides a middle ground. It lets developers expose exactly the right tools, with guardrails, so the model can handle the task effectively.
Kiwi.com’s MCP server: first version
The current server exposes a single search-flight tool with the following parameters:
- Trip type (one-way, round-trip)
- Origin and destination (city or airport)
- Dates with ±3 day flexibility
- Passenger mix (adult, child, infant)
- Cabin class
Each result comes with a direct booking link.
What we optimized with Alpic
1. One-click deployment & hosting
The server is deployed from a Git repo with standard build commands. Once pushed, it’s live on a secure HTTPS endpoint with a custom domain. Behind the scenes:
- TLS termination and request parsing handled automatically
- Tool execution in stateless, isolated environments
- Built-in DDoS protection and rate limiting
This reduced Kiwi.com’s operational overhead so they could iterate quickly and expose the service to real users.
2. Server design choices
Shortened booking links: Long URLs eat context and risk breaking. We introduced shortened booking links to keep token usage small.
Structured responses: Instead of a free blob of text, the MCP instructs the LLM to return results in a table format, making comparison easier for users.
Fewer, curated results: Kiwi.com’s API can return thousands of flights, but the MCP server only sends a few dozen “best” options. This leverages Kiwi’s business logic while avoiding models making poor tradeoffs (like suggesting 15-hour layovers for €30 savings).
What’s missing and what’s next
Right now, the server only handles simple round-trip and one-way searches. Features not yet handled include:
- Multi-destination itineraries
- Checked bags
- Max duration filtering
- Account login and loyalty integration
On the protocol side, new MCP features could open up more options:
Elicitations: proactively asking the user to clarify (e.g. “Do you prefer Orly or CDG?” when searching Paris flights).
User preferences: storing seat choices, airlines, or price vs. comfort tradeoffs in reusable context.
Finally, better client-side capabilities will make adoption smoother: server registries (e.g. Claude Directory), less installation friction, and eventually end-to-end booking inside assistants without link redirects.
Takeaways
MCP servers are not just API wrappers, they require deliberate design for LLM usability.
Optimizing context usage (short links, curated data, structured responses) is critical.
Kiwi.com’s MCP server is an early step, but it shows how travel booking could work in an agent-native world. We'd love to have your feedback and ideas for future iterations.
Also, if you’re building with MCP and want one-step deployment, hosting, and AI-specific analytics, check out Alpic.ai.
Top comments (0)