Add real-time flight search to any MCP client. Alice Flights is a hosted, remote Model Context Protocol (MCP) server that lets an AI assistant search flights — best, cheapest, and fastest options with live seat availability — directly in a conversation. Powered by Alice, one of Israel's best-known travel apps and a top flight seller.
This repository is the reference implementation of the Alice Flights MCP server and documentation for the hosted service. For everyday use there's nothing to run — Alice hosts it at
https://mcp.alice.co.il/mcp(one-click, no API key). You can also run this server yourself: it's a complete, standalone MCP server, not a proxy.
Endpoint: https://mcp.alice.co.il/mcp (Streamable HTTP)
Auth: OAuth 2.0 — one-click, anonymous consent. No account, no API key.
Official MCP Registry: il.co.alice/flights
Website & privacy: mcp.alice.co.il · privacy policy
Best / cheapest / fastest — results arrive categorized, not as a flat list; every option carries why it was picked.
Live seat availability — a low-seats note when only a few seats remain.
Interactive results widget (MCP Apps) — carrier chips, itinerary timeline, baggage info, tabs, and a nonstop filter; renders inline in hosts that support MCP Apps. (Hosted service only.)
Bilingual — ask in English or Hebrew; Hebrew results render right-to-left. (Hosted service only.)
Read-only & anonymous — it searches and links you to book on alice.co.il; it can't book, charge, or change anything, and it needs no sign-in.
Related MCP server: skrishnak7-mcp
Alice is a standard remote MCP server (Streamable HTTP + OAuth), so it works with any
MCP-capable client. Clients that read an mcp.json:
{
"mcpServers": {
"alice": {
"type": "http",
"url": "https://mcp.alice.co.il/mcp"
}
}
}For stdio-only clients, bridge the hosted endpoint with mcp-remote:
{
"mcpServers": {
"alice": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.alice.co.il/mcp"]
}
}
}(The first connection opens a browser once for the anonymous OAuth consent.)
This repo is a complete, standalone MCP server (TypeScript, stdio transport) that talks
to Alice's public flight-search endpoint (api.alice.co.il). No credentials, no
API key, no sign-up — the affiliate identity is attached server-side at Alice's edge, so
nothing secret is ever in this repo or on your machine.
git clone https://github.com/blackrabbit-travel/alice-flights-mcp
cd alice-flights-mcp
npm install
npm run build
npm run smoke # boots the server, runs the MCP handshake and a real live search
npm start # runs the MCP server on stdioThen point any stdio MCP client at the built entry:
{
"mcpServers": {
"alice": {
"command": "node",
"args": ["/path/to/alice-flights-mcp/dist/index.js"]
}
}
}Or with Docker:
docker build -t alice-flights-mcp .
docker run -i --rm alice-flights-mcpRate limit. The public endpoint allows 10 searches per minute and 200 per day per IP address. Beyond that it answers
429with aRetry-After, which the server turns into a plain "try again in N seconds" message. That is plenty for personal use; for anything heavier, or for the interactive widget and Hebrew results, use the hosted endpoint above.
Configuration is optional (see .env.example):
Variable | Default | Description |
|
| Override the search endpoint. Leave unset. |
search_flights — Search flights by origin, destination, dates, passengers, and cabin
class. Returns options tagged best / cheapest / fastest, each with price, itinerary,
baggage, and seats_remaining.
Try asking:
"Find me a flight from Tel Aviv to London next Thursday, back on Sunday."
"What's the cheapest nonstop to Athens in August for two adults?"
Operated by Alice (alice.co.il). The flight-search backend
(the search engine and pricing) is proprietary; the MIT license in this repository covers
this connector — the MCP server implementation, Dockerfile, server.json, and config
examples. The hosted service adds an interactive widget, bilingual UI, and OAuth consent on
top of the same search_flights tool.
Search for available flights between two cities. Returns a curated set of options, each tagged with one or more categories:
best: the engine's recommended balance of price, total duration, and stops.
cheapest: lowest total price.
fastest: shortest total travel time.
The categories overlap — a single flight can be both best and cheapest. Each option includes price, total durations, layovers, its categories, and a direct booking link. Options may include seats_remaining — the number of seats left in this booking class at this price; values of 4 or fewer indicate limited availability.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adult passengers (0–9) | |
| origin | Yes | 3-letter IATA city or airport code (e.g. 'TLV', 'LON', 'MAD') | |
| infants | No | Number of infant passengers (0–9) | |
| seniors | No | Number of senior passengers (0–9) | |
| children | No | Number of child passengers (0–9) | |
| destination | Yes | 3-letter IATA city or airport code (e.g. 'TLV', 'LON', 'MAD') | |
| return_date | No | Return date for round trips (YYYY-MM-DD). Omit for one-way. | |
| flight_class | No | Cabin class: tour (economy), tourPlus (premium economy), business, or first | tour |
| departure_date | Yes | Departure date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be a safe read operation. The description adds valuable behavioral context beyond annotations: it reveals that results are 'curated' (i.e., not exhaustive), explains the meaning of the category tags, and defines the significance of 'seats_remaining' (4 or fewer = limited availability). This helps the agent interpret results correctly and set user expectations, going beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it leads with the main purpose, then breaks out the category definitions in a bulleted list, and finally explains the output fields and the seats_remaining nuance. It is a bit lengthy (around 100 words) but every sentence contributes meaning. The front-loading is effective, and the formatting aids readability. It earns a 4 rather than a 5 because some phrasing (e.g., 'the engine's recommended balance' and the seats_remaining explanation) could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and no output schema, the description carries the responsibility of explaining the return structure. It does this thoroughly: it lists the fields (price, total durations, layovers, categories, booking link, seats_remaining) and defines each category. It also explains the optional nature of seats_remaining. The only minor gap is that it does not explicitly mention that the output is for the specified departure date and optionally includes a return date for round trips, but the schema already documents that via the return_date parameter. Overall, it is complete enough for an agent to call and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: every parameter includes a description (e.g., origin/destination are 3-letter IATA codes, dates are YYYY-MM-DD). The tool description adds no additional parameter-specific information; it focuses entirely on the output. Since the schema already fully documents parameters, the baseline of 3 is appropriate; the description does not need to repeat parameter details, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Search') and resource ('available flights between two cities'), and then elaborates on the output categories (best, cheapest, fastest) which distinguishes the tool's value proposition. It precisely defines what the tool returns and how categories overlap. With no sibling tools, differentiation is not required, but the description is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever flight options are needed between two cities. It does not mention alternatives (none exist), but it explains the output's curation and categories, which helps an agent decide if this tool fits the user's intent (e.g., if the user wants the fastest option). No explicit exclusions or 'when not to use' are given, but the purpose is self-evident and the description adds context about the result semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0search_flightsScored across 1 tool
With only one tool, there is no possibility of confusion between tools. The tool's purpose is clearly defined as flight search, making its role unambiguous.
The single tool name 'search_flights' follows a clear verb_noun pattern, and since there is only one tool, there is no inconsistency to evaluate.
The server exposes only one tool, which feels thin for a flight-related service. While it may be sufficient for a search-only endpoint, it falls below the typical 3-15 tool range and leaves the impression of an underprovisioned server.
The tool covers basic flight search but lacks essential parameters like travel dates or passenger count, and there are no booking or management tools. This results in significant gaps for a flight service domain.
Flight search MCP server providing search, pagination, and itinerary details for AI assistants.
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
AI marketplace — flights, tours, activities, transport & more via MCP. No auth required.
