Which integrations are available for this server?

Provides tools for searching one-way and return flights, exploring destinations, and retrieving flight details from Ryanair's live network.

Flyan

by victorlane

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Flyan SDK

PyPI version Python versions CodeQL PyPI downloads License

An open-source unofficial API wrapper to get flight data from Ryanair.

TIP

New: MCP server for AI agents. Plug Flyan into Claude Desktop, Claude Code, or Cursor and search Ryanair flights in natural language. Jump to the MCP Quickstart.

Related MCP server: Google Flights MCP

Installation

pip install Flyan

Or using uv:

uv add Flyan

Quick Start

from datetime import datetime
from flyan import RyanAir, FlightSearchParams

# Initialize the client
client = RyanAir(currency="EUR")

# Set up search parameters
search_params = FlightSearchParams(
    from_airport="DUB",  # Dublin
    to_airport="BCN",    # Barcelona
    from_date=datetime(2025, 8, 15),
    to_date=datetime(2025, 8, 20),
    max_price=200
)

# Search for one-way flights
flights = client.get_oneways(search_params)

# Display results
for flight in flights:
    print(f"Flight {flight.flight_number}: {flight.departure_airport.name} → {flight.arrival_airport.name}")
    print(f"Departure: {flight.departure_date}")
    print(f"Price: {flight.price} {flight.currency}")
    print("---")

API Reference

RyanAir Class

Constructor

RyanAir(currency: str = "EUR")

Creates a new RyanAir client instance.

Parameters:

currency (str, optional): Preferred currency for pricing. Defaults to "EUR". Must be a valid currency code from the supported currencies list.

Example:

# Default EUR currency
client = RyanAir()

# Specific currency
client = RyanAir(currency="USD")

Methods

`get_oneways(params: FlightSearchParams) -> list[Flight]`

Search for one-way flights.

Parameters:

params (FlightSearchParams): Search parameters

Returns:

list[Flight]: List of available flights

FlightSearchParams Class

Parameters for searching flights.

FlightSearchParams(
    from_airport: str,
    from_date: datetime,
    to_date: datetime,
    destination_country: Optional[str] = None,
    max_price: Optional[int] = None,
    to_airport: Optional[str] = None,
    departure_time_from: Optional[str] = "00:00",
    departure_time_to: Optional[str] = "23:59"
)

Parameters:

from_airport (str): IATA code of departure airport (e.g., "DUB")
from_date (datetime): Earliest departure date
to_date (datetime): Latest departure date
destination_country (str, optional): Country code for destination
max_price (int, optional): Maximum price filter
to_airport (str, optional): IATA code of arrival airport
departure_time_from (str, optional): Earliest departure time (HH:MM format)
departure_time_to (str, optional): Latest departure time (HH:MM format)

Example:

from datetime import datetime

params = FlightSearchParams(
    from_airport="DUB",
    from_date=datetime(2025, 8, 15),
    to_date=datetime(2025, 8, 20),
    to_airport="BCN",
    max_price=150,
    departure_time_from="08:00",
    departure_time_to="18:00"
)

ReturnFlightSearchParams Class

Extended parameters for return flight searches.

ReturnFlightSearchParams(
    # All FlightSearchParams fields plus:
    return_date_from: datetime,
    return_date_to: datetime,
    inbound_departure_time_from: Optional[str] = "00:00",
    inbound_departure_time_to: Optional[str] = "23:59"
)

Data Models

Flight

Represents a single flight.

Attributes:

departure_airport (Airport): Departure airport information
arrival_airport (Airport): Arrival airport information
departure_date (datetime): Departure date and time
arrival_date (datetime): Arrival date and time
price (float): Flight price
currency (str): Price currency
flight_key (str): Unique flight identifier
flight_number (str): Flight number
previous_price (Optional[str | float]): Previous price if available

Airport

Represents airport information.

Attributes:

country_name (str): Country name
iata_code (str): IATA airport code
name (str): Airport name
seo_name (str): SEO-friendly name
city_name (str): City name
city_code (str): City code
city_country_code (str): Country code

ReturnFlight

Represents a return flight booking.

Attributes:

outbound (Flight): Outbound flight
inbound (Flight): Return flight
summary_price (float): Total price for both flights
summary_currency (str): Currency for total price
previous_price (str | float): Previous total price if available

NetworkAirport

Represents an airport in Ryanair's live network. Returned by the explore methods.

Attributes:

iata_code (str): IATA airport code
name (str): Airport name
seo_name (str): SEO-friendly name
country_code (str): Lowercase ISO2 country code (e.g. "ie", "es")
city_code (str): City code (e.g. "LONDON", "DUBLIN")
region_code (Optional[str]): Region code (e.g. "SCOTLAND", "ANDALUSIA")
currency_code (str): Local currency code
time_zone (str): IANA timezone (e.g. "Europe/Dublin")
base (bool): True if this is a Ryanair base
latitude (float), longitude (float): Coordinates
routes (list[str]): Raw route strings (year-round)
seasonal_routes (list[str]): Raw route strings (seasonal-only)
categories (list[str]): Marketing categories assigned by Ryanair
aliases (list[str]): Alternative names

Helpers: airport_routes(), country_routes(), seasonal_airport_routes(), typed_routes(), typed_seasonal_routes().

DestinationFare

Returned by explore_with_fares(). Pairs a reachable destination with its cheapest sampled fare, if one was returned by the price probe.

Attributes:

airport (NetworkAirport): The destination airport
fare (Optional[Flight]): The cheapest sampled fare in the window, or None if the route is in the network but no priced inventory came back (no flights in the window, sold out, etc.)

Examples

Search by Country

# Search flights to any airport in Spain
params = FlightSearchParams(
    from_airport="DUB",
    destination_country="ES",
    from_date=datetime(2025, 9, 1),
    to_date=datetime(2025, 9, 7)
)

flights = client.get_oneways(params)

Filter by Time and Price

# Morning flights under €100
params = FlightSearchParams(
    from_airport="STN",  # London Stansted
    to_airport="DUB",    # Dublin
    from_date=datetime(2025, 8, 1),
    to_date=datetime(2025, 8, 5),
    max_price=100,
    departure_time_from="06:00",
    departure_time_to="12:00"
)

flights = client.get_oneways(params)

Error Handling

from flyan import RyanairException

try:
    flights = client.get_oneways(params)
    if not flights:
        print("No flights found for the given criteria")
except RyanairException as e:
    print(f"Ryanair API error: {e}")
except Exception as e:
    print(f"Unexpected error: {e}")

Explore Mode

Explore Mode answers the question "where can I actually fly from here?". It reads Ryanair's live network metadata once and exposes the reachable destinations from any airport, optionally grouped, filtered, or joined with the cheapest fare in a date window.

All methods below are available on both RyanAir and AsyncRyanAir.

List every destination

destinations = client.get_destinations("DUB")

for airport in destinations:
    print(f"{airport.iata_code} {airport.name} ({airport.country_code})")

Filter by country, region or city

# All Scottish airports DUB flies to
in_scotland = client.get_destinations_in_region("DUB", "SCOTLAND")

# All London airports DUB flies to (LGW, LTN, STN)
in_london = client.get_destinations_in_city("DUB", "LONDON")

# All Spanish airports DUB flies to
in_spain = client.get_destinations_in_country("DUB", "es")

Country codes are lowercase ISO2. Region and city codes come from the live network (uppercase, e.g. SCOTLAND, ANDALUSIA, COSTA_DE_SOL, LONDON, MILAN).

Group destinations

# {country_code: [airports]}
by_country = client.explore_by_country("DUB")

print(f"DUB flies to {len(by_country)} countries")
for country, airports in sorted(by_country.items()):
    codes = ", ".join(a.iata_code for a in airports)
    print(f"  {country}: {codes}")

# {region_code: [airports]}
by_region = client.explore_by_region("DUB")

Airports without a region_code are collected under the empty-string key, so callers can decide whether to surface or drop them.

Seasonal-only destinations

seasonal = client.get_seasonal_destinations("DUB")

Ryanair's seasonalRoutes list is sparsely populated upstream, so this often returns [] outside of summer/winter schedule transitions. The method is provided so callers do not need to peek at the raw route strings.

Destinations with their cheapest fare

explore_with_fares() joins the network destinations with a oneWayFares probe, so each destination comes back with its cheapest sampled Flight (or None if no fare was returned for that route in the window). It costs one network call plus one fare call.

from datetime import datetime, timedelta

start = datetime.now() + timedelta(days=14)
end = start + timedelta(days=7)

results = client.explore_with_fares("DUB", start, end, max_price=100)

priced = [d for d in results if d.fare is not None]
cheapest_first = sorted(priced, key=lambda d: d.fare.price)

for d in cheapest_first[:10]:
    print(f"{d.airport.iata_code} {d.airport.name}: "
          f"{d.fare.price} {d.fare.currency}")

Async usage

AsyncRyanAir mirrors every explore method:

import asyncio
from flyan import AsyncRyanAir

async def main():
    async with AsyncRyanAir() as client:
        by_country = await client.explore_by_country("DUB")
        print(f"{len(by_country)} countries reachable from DUB")

asyncio.run(main())

If you call multiple explore methods in a row, wrap the transport in CachingTransport so the network metadata is fetched once and reused.

Use with Claude, Cursor, and other MCP clients

IMPORTANT

Two commands and you're done:

uv tool install "Flyan[mcp]"
claude mcp add flyan flyan-mcp

Now your agent can search Ryanair flights in natural language. No API keys, no accounts.

Flyan ships an optional Model Context Protocol server so your agent can search Ryanair fares from natural-language prompts like "find me a cheap flight from Dublin to Spain in August under €150" or "what's the cheapest day in July to fly DUB to BCN".

Quickstart

1. Install Flyan with the MCP extra:

uv tool install "Flyan[mcp]"

Or with pip:

pipx install "Flyan[mcp]"

This installs a flyan-mcp console script on your PATH.

2. Add it to your agent:

Claude Code (one-liner):

claude mcp add flyan flyan-mcp

Claude Desktop: open ~/Library/Application Support/Claude/claude_desktop_config.json on macOS (or %APPDATA%\Claude\claude_desktop_config.json on Windows) and add:

{
  "mcpServers": {
    "flyan": {
      "command": "flyan-mcp"
    }
  }
}

Then restart Claude Desktop.

Cursor: Settings → MCP → Add new server, name flyan, command flyan-mcp.

Currency

The server returns prices in EUR by default. To get them in another currency, set the FLYAN_CURRENCY env var to any supported ISO 4217 code before launching flyan-mcp:

FLYAN_CURRENCY=GBP flyan-mcp

Or pass it through your agent's MCP config:

{
  "mcpServers": {
    "flyan": {
      "command": "flyan-mcp",
      "env": { "FLYAN_CURRENCY": "GBP" }
    }
  }
}

Unknown or unsupported codes silently fall back to EUR.

3. Try it. Ask your agent:

"Find me a one-way from Dublin to anywhere in Spain in the first week of August under €150."

The agent should call find_flights with destination_country="es", then summarize the cheapest options.

Exposed tools

The server exposes four curated tools so the agent can pick reliably:

find_flights for one-way searches with optional country, IATA, or price filters
find_anywhere_under for "where can I go for under £X" prompts
explore_destinations for "what countries can I reach from X"
cheapest_per_day for "what's the cheapest day this month to fly X to Y"

No API keys, accounts, or rate-limit setup. Ryanair's API is anonymous and the server reuses a single RyanAir client across calls.

Supported Airports

The SDK supports all airports in Ryanair's network. Airport codes must be valid 3-letter IATA codes. The live list is fetched from Ryanair's aggregate endpoint via client.get_network(); iterate network.airports for the full set.

Popular airports include:

DUB - Dublin
STN - London Stansted
BCN - Barcelona
MAD - Madrid
FCO - Rome Fiumicino
BRU - Brussels
AMS - Amsterdam

Supported Currencies

The SDK supports multiple currencies. Some popular ones include:

EUR - Euro
USD - US Dollar
GBP - British Pound
CHF - Swiss Franc

See currencies.json for the complete list.

Rate Limiting

The SDK includes automatic retry logic with exponential backoff to handle rate limiting and temporary API issues. It will retry failed requests up to 5 times before giving up.

Contributing

This is an open-source project. Contributions are welcome!

Disclaimer

This is an unofficial API wrapper and is not affiliated with Ryanair. Use at your own risk and ensure you comply with Ryanair's terms of service.

Available Tools

4 tools

cheapest_per_dayA

Cheapest fare per day for one route across a single calendar month.

month is the first of the month in ISO format (YYYY-MM-01). Powers "what's the cheapest day in July to fly DUB->BCN" style prompts. Days with no flight or no price come back with price=None.

ParametersJSON Schema

Name	Required	Description	Default
`origin`	Yes
`destination`	Yes
`month`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are present, so the description must carry the full burden. It explicitly states that days with no flight or price return 'price=None', which is a key behavioral detail. It also specifies the month parameter format. However, it does not disclose potential costs, rate limits, or authentication requirements, leaving some gaps for a tool with no annotations.

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 three sentences long, with each sentence serving a clear purpose: stating the tool's function, clarifying the month parameter format, and explaining behavior for missing prices. There is no redundant or irrelevant information, making it highly concise and well-structured.

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?

Given the presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers the main use case, the month parameter format, and the behavior for missing data. It could mention potential constraints like maximum date range, but overall it is complete for a simple tool with a limited scope.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaning for the month parameter by specifying the ISO format (YYYY-MM-01). For origin and destination, it only provides an example (DUB->BCN) and mentions 'one route', but does not explicitly state that they should be airport codes or expected format. This is partial compensation.

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 that the tool provides the cheapest fare per day for one route across a single calendar month, using specific verbs ('cheapest fare per day') and a resource ('one route'). It distinguishes itself from sibling tools (explore_destinations, find_anywhere_under, find_flights) by focusing on a fixed-route monthly calendar view, as evidenced by the example 'what's the cheapest day in July to fly DUB->BCN'.

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 a concrete use case example ('powers ... style prompts'), which implies the intended scenario. However, it does not explicitly mention when not to use the tool or directly compare it to sibling tools. The example is sufficient to guide usage, but lacks explicit exclusions or alternatives.

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

explore_destinationsA

Every destination Ryanair flies to from origin, grouped by country.

Returns {country_code: [{iata, name, city, region}]}. No fare lookup, just the network. Good for answering "what countries can I reach from X" or "does origin fly to destination at all".

ParametersJSON Schema

Name	Required	Description	Default
`origin`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Discloses no fare lookup, purely network exploration; with no annotations, this adequately conveys behavior for a read-only query.

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?

Two concise sentences front-loading purpose and including return format example; no wasted words.

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

Completeness5/5

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

Output schema exists and description explains return structure; single parameter, no additional context needed.

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?

Single parameter 'origin' is clearly implied as the starting airport via backticks; schema coverage is 0% but description adds meaning to the parameter.

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?

Clear verb 'explore' and specific resource 'destinations from origin'; distinguishes from sibling tools by stating 'no fare lookup, just the network'.

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?

Explicit examples of when to use: answering reachable countries or if a destination is served. No explicit when-not-to-use, but sibling context implies alternatives for pricing.

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

find_anywhere_underA

Cheapest fares from from_airport to anywhere under max_price.

Useful for "where can I go for under £50 this weekend" style prompts.

ParametersJSON Schema

Name	Required	Description	Default
`from_airport`	Yes
`max_price`	Yes
`from_date`	Yes
`to_date`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It explains the core behavior (cheapest fares under a price) but does not specify return format, result count, or limitations (e.g., airline exclusions). It is adequate but not detailed.

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?

Two short sentences: first defines the core function, second gives an illustrative use case. No filler or redundancy.

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?

For a tool with 4 required params and no schema descriptions, the description leaves out the date parameters. While an output schema exists, the description should explain all inputs. Adequate but incomplete.

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

Parameters2/5

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

Schema coverage is 0%; the description only indirectly explains 'from_airport' and 'max_price' while omitting 'from_date' and 'to_date' entirely. These are required, and their purpose is only hinted at by the example 'this weekend'. Missing explicit parameter definitions.

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 it finds cheapest fares from a given airport to any destination under a max price, using a specific verb and resource. It distinguishes from siblings (e.g., 'find_flights' for specific flights) by emphasizing budget flexibility.

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 a concrete example ('where can I go for under £50 this weekend') and implies the tool is for open-ended budget searches. However, it does not explicitly state when not to use or compare to siblings.

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

find_flightsA

Search Ryanair one-way fares.

from_airport and to_airport are 3-letter IATA codes (e.g. DUB). destination_country is a lowercase ISO2 code (e.g. es, gb); uppercase silently returns no fares.

Dates are ISO format (YYYY-MM-DD) and bound a departure window: the API returns the cheapest fare per route per day inside the window.

ParametersJSON Schema

Name	Required	Description	Default
`from_airport`	Yes
`from_date`	Yes
`to_date`	Yes
`to_airport`	No
`destination_country`	No
`max_price`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

The description discloses that uppercase country codes silently return no fares and that dates define a departure window returning cheapest fare per route per day. However, it omits other behavioral traits such as rate limits, authentication requirements, or the effect of optional parameters like max_price. With no annotations, the description provides adequate but not comprehensive transparency.

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, with a clear front-loaded purpose followed by parameter details in a few sentences. No redundant information is present, and every sentence adds value.

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?

Given the tool has 6 parameters (3 required), sibling tools, and an output schema, the description sufficiently explains the core function and key parameters. It misses only a brief explanation of max_price, which is a minor gap. The output schema exists but is not described, which is acceptable per rules.

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 description explains that from_airport and to_airport are IATA codes, destination_country is lowercase ISO2, and dates are ISO format. However, it does not cover max_price at all, and the relationship between to_airport and destination_country is unclear. With 0% schema coverage, the description partly compensates but leaves gaps.

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 explicitly states 'Search Ryanair one-way fares', identifying the specific airline and fare type. It clearly distinguishes from sibling tools like 'cheapest_per_day' and 'find_anywhere_under' by focusing on one-way fare searching with a departure window.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus its siblings (cheapest_per_day, explore_destinations, find_anywhere_under). There is no mention of when to choose this tool over alternatives or any when-not-to-use advice.

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.

4 tool updatesv0.4.3Jun 19, 2026
- First observedcheapest_per_day
- First observedexplore_destinations
- First observedfind_anywhere_under
- First observedfind_flights

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-06-19 13:50 across 4 tools

Disambiguation5/5

Each tool serves a distinct purpose: cheapest_per_day finds the cheapest day on a specific route per month, explore_destinations lists all destinations from an origin, find_anywhere_under searches for cheap flights to anywhere, and find_flights searches one-way fares within a window. No overlap in functionality.

Naming Consistency4/5

All tool names use snake_case and a verb-first pattern: cheapest_per_day, explore_destinations, find_anywhere_under, find_flights. The verb forms are clear and descriptive, though 'cheapest' is an adjective rather than a verb, slightly breaking consistency.

Tool Count5/5

With 4 tools, the server covers essential flight discovery tasks: route-specific cheapest day, network exploration, budget search, and general search. The count is well-scoped for a flight info assistant, not too few or too many.

Completeness4/5

The tool set covers core discovery workflows: cheapest day, destinations, cheap anywhere, and general one-way search. Missing round-trip or multi-segment searches, but these are reasonable gaps given the focus on one-way Ryanair fares.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

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
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
Google Flights Search (Real-Time Fares)AOAuth
com.flightpowers
Real-time Google Flights fares for agents. Three things people do with this server. Scan for deals: one call takes a date range and a list of destination airports, expands every combination server side, and returns each fare with Google's own low, typical or high verdict. Put live search in your app: flat JSON with a bookable link on every result, and round trips priced as paired legs. Run a 24/7 AI travel agent: add the server, sign in with Google, and schedule it. No ads, no sponsored content. You bring your own RapidAPI key, so every search is billed to your plan and never to anyone else's. Add https://flights.flightpowers.com/mcp , click Sign in, sign in with Google, and paste your RapidAPI key once on the page that opens. Scripts and clients without a sign-in button send the key as x-rapidapi-key on the same URL.
Search Travel & Transportation
211
google-flightsOAuth
io.github.johnisanerd
Google Flights search data: fares, routes, stops, and price insights via a hosted MCP server.
Travel & Transportation Search
21

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
Google Flights MCP
Travel & Transportation Search App Automation
impca201
F
license
Not graded
quality
Not graded
maintenance
A remote MCP server that searches Google Flights for flight information and airport codes. It enables users to find flights, locate airports, and generate travel dates through natural language interactions.
Updated 5 months ago (2026-04-13 08:15 UTC)
-
FlightFinder
Travel & Transportation Search
wolfiesch
A
license
Not graded
quality
D
maintenance
A Python client for searching flights and hotels without API keys, providing an MCP server for AI agents to search flights, hotels, and plan trips.
Updated 4 months ago (2026-05-17 14:40 UTC)
3
MIT
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
-

Flyan SDK

Contents

Installation

Quick Start

API Reference

RyanAir Class

Constructor

Methods

get_oneways(params: FlightSearchParams) -> list[Flight]

FlightSearchParams Class

ReturnFlightSearchParams Class

Data Models

Flight

Airport

ReturnFlight

NetworkAirport

DestinationFare

Examples

Search by Country

Filter by Time and Price

Error Handling

Explore Mode

List every destination

Filter by country, region or city

Group destinations

Seasonal-only destinations

Destinations with their cheapest fare

Async usage

Use with Claude, Cursor, and other MCP clients

Quickstart

Currency

Exposed tools

Supported Airports

Supported Currencies

Rate Limiting

Contributing

Disclaimer

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`get_oneways(params: FlightSearchParams) -> list[Flight]`