How do I use azair-eu-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@azair-eu-mcp Find cheapest weekend trips from Berlin to anywhere in Spain next month" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

azair-eu-mcp

by yuriiter

Overview Schema Source Related Servers Discussions Admin

Python

Remote

✈️ azair-eu-mcp

Python MCP azair.eu

MCP server for azair.eu — cheap flight search across European low-cost airlines with flexible dates. Give your AI assistant the power to hunt for bargain flights the way humans do on azair: loose date ranges, multiple airports, metro areas, and every advanced filter from the azair search form.

Features

🔎 Flexible-date search — the core azair superpower: pick a date range, get the cheapest day combinations within it
🛫 Multi-airport search — search from several airports at once (e.g. PRG + BRQ + NUE)
🏙️ Metro-area search — cover all airports of a city via metro codes (e.g. MIL_ALL → MXP, BGY, LIN)
🌍 Anywhere mode — destination XXX searches the whole continent
⚙️ All advanced filters — weekdays, time windows, stopover length, transfers, Schengen-only, clubs, and more
💱 Multi-currency — EUR, USD, GBP, PLN, CZK, and all azair currencies
✍️ Structured results — clean JSON with prices, dates, per-segment flight details, and booking links

Related MCP server: cheapflights-mcp

Quick start

Ask your assistant (Claude, Cursor, Windsurf, …):

Find cheap return flights from Prague to anywhere in Italy between August and January, min 5 nights, max 8 nights, any Milan or Rome airport.

or directly:

search_flights(src_airport="PRG", src_airports=["BRQ", "NUE"],
               dst_airport="MXP", dst_airports=["LIN", "BGY"], dst_metro_code="MIL_ALL",
               dep_date="2026-08-01", arr_date="2027-01-31",
               min_days_stay=5, max_days_stay=8)

Example response:

{
  "total_price": 33.33,
  "currency": "EUR",
  "length_of_stay_days": 6,
  "outbound_date": "Thu 20/08/26",
  "return_date": "Wed 26/08/26",
  "outbound_segments": [
    {
      "airline": "Ryanair",
      "airline_iata": "FR",
      "flight_number": "FR3601",
      "departure_airport": "Prague",
      "departure_airport_code": "PRG",
      "departure_time": "09:00",
      "arrival_airport": "Bologna",
      "arrival_airport_code": "BLQ",
      "arrival_time": "10:30",
      "duration": "12:10 h / 1 change",
      "price": 33.33,
      "currency": "EUR"
    }
  ],
  "return_segments": [],
  "booking_url": "book/b.php?b=RlJQUkdCTFEyNjA4MjUzNjAxMTAwMjAyNi0wOC0wMSswMjoxM2Vud3d3LmF6YWlyLmV1"
}

Returns up to 180 results, each with total price, dates, outbound/return segments (airline, flight number, times, duration, leg price), and a direct booking URL.

Tools

`search_flights`

Full-featured flight search mirroring the azair search form, including advanced parameters.

Parameter	Type	Default	Description
`src_airport`	string	—	Source airport IATA code (e.g. `WMI`, `STN`)
`dst_airport`	string	—	Destination IATA code or `XXX` for anywhere
`src_airports`	string[]	—	Additional source airports, e.g. `BRQ`, `NUE` together with `PRG`
`dst_airports`	string[]	—	Additional destination airports, e.g. `LIN`, `BGY` together with `MXP`
`src_metro_code`	string	—	Source metro code covering all its airports, e.g. `MIL_ALL`
`dst_metro_code`	string	—	Destination metro code covering all its airports, e.g. `MIL_ALL`
`dep_date`	string	—	Earliest departure, `DD.MM.YYYY` or `YYYY-MM-DD`
`arr_date`	string	—	Latest return, `DD.MM.YYYY` or `YYYY-MM-DD`
`min_days_stay`	int	`2`	Minimum trip length in days
`max_days_stay`	int	`7`	Maximum trip length in days
`adults`	int	`1`	Adults (1-9)
`children`	int	`0`	Children (0-8)
`infants`	int	`0`	Infants (0-8)
`currency`	string	`EUR`	`EUR`, `USD`, `GBP`, `PLN`, `CZK`, …
`max_changes`	int	`1`	Max stopovers per leg (0-3, `0` = direct flights only)
`is_oneway`	bool	`false`	One-way instead of return
`schengen_only`	bool	`false`	Only transfers inside the Schengen area
`allow_transfer`	bool	`false`	Allow ground transfer between airports
`departure_weekdays`	int[]	all	Departure weekdays, `0=Mon..6=Sun`
`return_weekdays`	int[]	all	Return weekdays
`min_hour_outbound`	string	`0:00`	Earliest outbound time
`max_hour_outbound`	string	`24:00`	Latest outbound time
`min_hour_inbound`	string	`0:00`	Earliest inbound time
`max_hour_inbound`	string	`24:00`	Latest inbound time
`min_hour_stay`	string	`0:45`	Minimum stopover time
`max_hour_stay`	string	`23:20`	Maximum stopover time
`next_day`	int	`0`	Allow overnight stopovers
`same_dep`	bool	`true`	Return to the same departure airport
`same_arr`	bool	`true`	Return from the same arrival airport

`search_airports`

Resolve IATA codes and airport names before searching — useful for finding the right code for a city.

Parameter	Type	Description
`query`	string	IATA code or partial name (e.g. `WMI`, `London`, `Barcelona`)

Returns up to 50 matching airports with code and name.

Installation

git clone <repo-url> azair-eu-mcp
cd azair-eu-mcp
uv sync

Usage

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "azair-eu-mcp": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/azair-eu-mcp", "python", "main.py"]
    }
  }
}

Cursor / Windsurf

Add the same command in the MCP servers settings.

Any MCP client

Run the server directly — it speaks MCP over stdio:

uv run python main.py

Development

uv sync
uv run python main.py

Sanity-check a search without spinning up the server:

uv run python -c "
import asyncio
from azair.models import SearchParams
from azair.client import fetch_search_results
from azair.parser import parse_results

async def main():
    html = await fetch_search_results(SearchParams(
        src_airport='PRG', dst_airport='STN',
        dep_date='2026-08-01', arr_date='2026-08-31',
    ))
    print(len(parse_results(html)), 'results')

asyncio.run(main())
"

How it works

Azair exposes no public JSON API — results are scraped from the HTML search results page (azfin.php)
The airport database is fetched once from azair's static JS asset and cached in memory
Multi-airport and metro codes are sent exactly as the azair web app does (bracket notation + srcapN/dstapN params)

Notes

Azair uses an expired SSL certificate — the server bypasses SSL verification
Search times vary (10-60s) depending on the query scope

Available Tools

2 tools

search_airportsA

Search for airports by IATA code or name. Uses the azair airport database.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Airport IATA code or name to search for

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It mentions the data source ('azair airport database') but does not disclose return format, matching behavior (exact/partial), result limits, or other operational details. This is a minimal disclosure for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two short sentences. The action and resource are front-loaded, and every word contributes value without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter tool with no output schema or annotations. The description states what is searched and by which keys, which is largely sufficient for basic invocation. A slight gap remains around return value expectations, but the scope is small.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the single 'query' parameter as 'Airport IATA code or name to search for' with 100% coverage. The description repeats this same concept without adding additional meaning or nuance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies a specific verb ('Search') and resource ('airports'), and specifies the search keys (IATA code or name). This distinguishes it from the sibling tool 'search_flights' by resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use the tool (when searching for airports), but it does not explicitly mention alternatives or exclusionary conditions. The sibling name 'search_flights' provides some context, but no direct guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_flightsA

Search for cheap flights on azair.eu across European low-cost airlines. Supports flexible date ranges, multiple airports per side, metro-area codes (e.g. MIL_ALL), anywhere (XXX), one-way or return, and all advanced filters (weekdays, time windows, stopover limits, overnight waits, transfers, Schengen-only).

ParametersJSON Schema

Name	Required	Description	Default
`adults`	No	Number of adult travellers aged 12+ (default 1)
`infants`	No	Number of infants under 2 years (default 0)
`arr_date`	Yes	Latest return date, format DD.MM.YYYY or YYYY-MM-DD
`children`	No	Number of children aged 2-11 (default 0)
`currency`	No	Currency for prices, e.g. EUR, USD, GBP, PLN, CZK (default EUR)	EUR
`dep_date`	Yes	Earliest departure date, format DD.MM.YYYY or YYYY-MM-DD
`next_day`	No	Allow waiting at the airport overnight so the next flight departs on the following day; 0 disallows overnight waits, up to 7 days (default 0)
`same_arr`	No	Require the return flight to depart from the same airport the outbound flight arrived at (default true)
`same_dep`	No	Require the return flight to arrive at the same airport the outbound flight departed from (default true)
`is_oneway`	No	Search one-way flights only; false searches return flights (default false)
`dst_airport`	Yes	Destination IATA code, e.g. STN, or XXX for anywhere in Europe
`max_changes`	No	Maximum stopovers per flight leg, 0 means direct flights only (default 1)
`src_airport`	Yes	Source airport IATA code, e.g. PRG, WMI, STN
`dst_airports`	No	Additional destination airports searched together with dst_airport, e.g. LIN, BGY alongside MXP
`src_airports`	No	Additional source airports searched together with src_airport, e.g. BRQ, NUE alongside PRG
`max_days_stay`	No	Maximum trip length in nights between outbound and return flight (default 7)
`max_hour_stay`	No	Maximum stopover (layover) duration between connecting flights as H:MM (default 23:20); applies only to itineraries with changes	23:20
`min_days_stay`	No	Minimum trip length in nights between outbound and return flight (default 2)
`min_hour_stay`	No	Minimum stopover (layover) duration between connecting flights as H:MM (default 0:45); applies only to itineraries with changes	0:45
`schengen_only`	No	Only allow transfers within the Schengen area (default false)
`allow_transfer`	No	Allow ground transfer between different airports during a connection, e.g. arriving at one airport and departing from another (default false)
`dst_metro_code`	No	Destination metro code covering all airports of a city, e.g. MIL_ALL, PAR_ALL, LON_ALL
`src_metro_code`	No	Source metro code covering all airports of a city, e.g. MIL_ALL (MXP, BGY, LIN), LON_ALL
`return_weekdays`	No	Weekdays the return flight may depart on, 0=Mon..6=Sun; omit for any day
`max_hour_inbound`	No	Latest departure time of the return flight, 24h local time as H:MM (default 24:00)	24:00
`min_hour_inbound`	No	Earliest departure time of the return flight, 24h local time as H:MM (default 0:00)	0:00
`max_hour_outbound`	No	Latest departure time of the outbound flight, 24h local time as H:MM (default 24:00)	24:00
`min_hour_outbound`	No	Earliest departure time of the outbound flight, 24h local time as H:MM (default 0:00)	0:00
`departure_weekdays`	No	Weekdays the outbound flight may depart on, 0=Mon, 1=Tue, 2=Wed, 3=Thu, 4=Fri, 5=Sat, 6=Sun; omit for any day

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool searches azair.eu and is limited to European low-cost airlines, and it highlights advanced search capabilities. This adds meaningful behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and every word adds value. It efficiently summarizes the tool's scope without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 29 parameters and no output schema, yet the description focuses mainly on search features. It does not explain the return format, error handling, or potential limitations beyond airline scope, leaving some gaps for such a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of parameters, so the baseline is 3. The description adds value by explaining special codes like 'MIL_ALL' and 'XXX' and summarizing filter categories (weekdays, time windows, stopover limits), which enriches parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: 'Search for cheap flights on azair.eu across European low-cost airlines.' It uses specific verbs and resources, and its focus on flight search differentiates it from the sibling tool search_airports.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by listing supported features like flexible date ranges, multiple airports, metro codes, anywhere (XXX), one-way or return, and advanced filters. It does not explicitly mention alternatives or exclusions, but the implied usage is clear for flight search scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.1.0Aug 7, 2026
- First observedsearch_airports
- First observedsearch_flights

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored 2026-08-07 08:45 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one searches for airport metadata (IATA/name), the other searches for flights. There is no overlap or ambiguity in their intended use.

Naming Consistency5/5

Both tools follow the consistent 'search_' verb + noun pattern (search_airports, search_flights), making the tool names predictable and easy to understand.

Tool Count4/5

With only two tools, the count is slightly below the typical range, but it is reasonable for a focused flight-search server. Each tool serves a necessary function and there is no bloat.

Completeness5/5

The tool set fully covers the stated domain of flight searching: airport lookup supports flight search, and flight search includes advanced filters for comprehensive results. There are no obvious missing operations for this purpose.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ALLFLYGHTS
io.github.dev-allflyghts
Geo-based flight search MCP server. Find more flights between any two places on earth
Travel & Transportation Location Services
2
Skiplagged MCP A
com.skiplagged
Skiplagged MCP Server for flight search, hotel booking, and travel planning
Travel & Transportation Search E-commerce & Retail
105
World Airfares Flight Search A
com.worldairfares
Flight search MCP server providing search, pagination, and itinerary details for AI assistants.
Travel & Transportation Search
32
Flight MCP
com.flight-mcp
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
Travel & Transportation Search
1

Related MCP Servers

Flights MCP
Search Travel & Transportation
maratsarbasov
A
license
A
quality
F
maintenance
MCP server searching flights with granular filtering, sorting options, and purchase integration.
Updated a year ago (2025-06-04 12:15 UTC)
4
15
Python
GPL 3.0
cheapflights-mcp
Travel & Transportation Search
saikandikatta
A
license
A
quality
C
maintenance
An MCP server that finds cheap flights with flexible dates and smart suggestions using the Google Flights API.
Updated 4 months ago (2026-05-20 01:12 UTC)
3
MIT
flights-mcp
Travel & Transportation Search
fastmcp-me
A
license
A
quality
D
maintenance
An MCP server that provides flight search capabilities using the Aviasales API, allowing users to search, filter, and get details on flights and generate booking links.
Updated 8 months ago (2026-01-19 06:48 UTC)
4
GPL 3.0
air_choose
Travel & Transportation Web Scraping
bitwiresys
F
license
A
quality
C
maintenance
MCP server that watches flight and train fares across multiple provider APIs, with tools to manage watched routes and a background scheduler that re-checks hourly for new offers.
Updated 2 months ago (2026-07-10 23:02 UTC)
8
-

✈️ azair-eu-mcp

Features

Quick start

Tools

search_flights

search_airports

Installation

Usage

Claude Desktop

Cursor / Windsurf

Any MCP client

Development

How it works

Notes

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Flights MCP

cheapflights-mcp

flights-mcp

air_choose

`search_flights`

`search_airports`