The AENA Flights MCP server provides real-time flight data for all 50 Spanish airports managed by AENA.
Search flights (search_flights): Query arrivals or departures by IATA code (e.g. MAD, BCN), filter by flight number, date (defaults to today), local time window, and hours back/forward. Automatically collapses codeshares and allows choosing data source: auto, website (up to 14 days ahead), or rest (past 54 hours + 24 hours ahead). Times are local Madrid time.
Get flight (get_flight): Retrieve detailed information for a specific flight by number, airport, and direction (arrivals/departures), including status, gates, terminals, and aircraft.
List airports (list_airports): Get all AENA airports with IATA/ICAO codes and city names.
The server automatically selects the best API source or allows manual override.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AENA Flights MCP Show me departures from Madrid-Barajas."
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.
Español: README.es.md
Live flight data for the 50 Spanish airports run by AENA, as an MCP server. Ask Claude things like "what departures leave Santiago this afternoon?" or "is IB0459 delayed?" and it answers from real airport data: times, gates, terminals, aircraft, status and codeshares.
It puts both of AENA's flight APIs behind one clean set of tools, so an agent asks for flights and gets back the same flight shape no matter which API answered.
The server runs publicly at https://aena-mcp.carlos-ls.workers.dev/mcp. Add it to Claude with one click:
That link opens claude.ai with the connector prefilled; just confirm. Works on every plan, Free included, and once added it is available in the Claude apps too, phone included. No account, no API key, nothing to configure.
Prefer to add it by hand? Claude → Settings → Connectors → Add custom connector, name it AENA Flights and paste the URL above.
ChatGPT has no one-click install link, but the same server works there (Plus, Pro and Business plans, web only):
Settings → Apps → Advanced settings → enable Developer mode
In the Apps panel press + and add the server with URL https://aena-mcp.carlos-ls.workers.dev/mcp, authentication: none
Related MCP server: flight-tracker
🛫 "Departures from MAD between 16:00 and 18:00"
🛬 "What flights arrive at BCN from London tomorrow afternoon?"
🔍 "Where is flight UX7235 right now, which gate?"
🏝️ "List all AENA airports in the Canary Islands"
How | For whom | Setup |
☁️ Remote connector (above) | Everyone, iPhone included | One click |
📦 Desktop extension | Claude Desktop | Download |
🟩 npm | Claude Code, Cursor, any MCP client |
|
🔧 From source | Developers | See below |
Config for npm-based clients:
{
"mcpServers": {
"aena": {
"command": "npx",
"args": ["-y", "mcp-aena"]
}
}
}For Claude Code it is one command:
claude mcp add aena -- npx -y mcp-aenasearch_flights — arrivals or departures for an airport. Filter by flight number, by date, or by a local-time window (afternoon = fromLocal 12:00, toLocal 20:00). Codeshares of the same physical flight collapse into one entry, and every time in the output is local Madrid time.
get_flight — one flight by number at an airport.
list_airports — every AENA airport with IATA/ICAO codes, fetched live.
AENA exposes two ways to read flights, and each covers a gap the other leaves open.
🌐 The website API is public and needs no credentials. It sees roughly 14 days ahead but has no past data. Good for discovery.
🔐 The REST API uses OAuth2 and needs a client secret. It sees about 54 hours into the past and 24 ahead, and tells you the real operating flight behind a codeshare. Good for tracking.
The server picks the right one for you (source: "auto"), or you can force either. Without a secret it runs in website-only mode and still works. The public remote server has full REST access already configured.
pnpm install
pnpm build # tsc → dist/
pnpm test # unit tests over captured fixtures, no network, no credentials
pnpm inspect # drive a live stdio session with the MCP inspectorCopy .env.example to .env. The website API needs nothing. For the REST API set AENA_CLIENT_SECRET; AENA_CLIENT_ID and AENA_TENANT_ID already have working defaults.
The public remote server lives in worker/ (Cloudflare Workers, Streamable HTTP, no auth). To host your own:
cd worker
pnpm install
npx wrangler deploy
npx wrangler secret put AENA_CLIENT_SECRET # optional, enables the REST sourceParsing lives in pure normalizers (normalizeWebsiteRow, normalizeRestRow) so the mapping is tested without a live call. See CONTRIBUTING.md.
CI runs the tests on Node 20 and 22 plus an MCP inspector smoke. Tagged pushes (v*) publish to npm (OIDC trusted publishing), the MCP Registry, and attach a .mcpb bundle to the GitHub release.
Arrivals is "A" in the REST API but "L" in the website API. The server hides this.
The REST airlineIATA field actually carries the ICAO code. The server resolves both.
Flight numbers differ by source: the REST API names flights by ICAO (VLG1674), the website by IATA (VY1674).
Neither API filters by flight number on the server, so searches pull the whole airport and filter locally.
Neither gives real takeoff or landing times, only scheduled and estimated. For wheels-off and wheels-on you need a source like FlightRadar24.
MIT
Find one flight by number at an airport. Convenience wrapper over search_flights that returns the single best match.
| Name | Required | Description | Default |
|---|---|---|---|
| airport | Yes | Airport IATA code | |
| direction | Yes | ||
| flightNumber | Yes | e.g. IB0459, UX7235 |
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 returns a single best match and acts as a wrapper, but it omits details on error behavior, what happens when no match is found, or how 'best match' is determined, leaving some ambiguity.
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 two sentences, front-loaded with the core purpose and followed by a useful context statement about being a wrapper. No unnecessary words.
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?
For a simple lookup tool with three parameters and no output schema, the description covers the essential elements: what it does, how it relates to search_flights, and its single-match behavior. Missing error-case details, but overall sufficient for the tool's simplicity.
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 schema already documents airport and flightNumber, and direction has an enum but no description. The description adds little to parameter understanding—it only mentions 'by number at an airport' and doesn't clarify the role of direction or the requirement for all three parameters. With 67% schema coverage, it doesn't compensate for the missing direction explanation.
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 clearly states 'Find one flight by number at an airport' with a specific verb and resource. It distinguishes itself as a convenience wrapper over search_flights that returns a single best match, making its unique purpose evident.
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?
It explicitly identifies itself as a wrapper over search_flights and notes that it returns 'the single best match', implying it should be used when a specific flight is needed rather than a broad search. However, it doesn't provide explicit when-not-to-use guidance or compare with list_airports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Spanish airports in the AENA network with IATA/ICAO codes and city. Fetched live, so always current.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses live fetching ('Fetched live, so always current'), which is useful behavioral context. For a simple read-only list tool, this is adequate, though it doesn't detail return formats or potential limitations.
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 two concise sentences. The first sentence front-loads the essential purpose, and the second adds a relevant behavioral note. Every word earns its place with no redundancy.
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's low complexity, zero parameters, and no output schema, the description is complete. It provides the core purpose and the live-fetch detail, which is sufficient for an agent to select and invoke this tool correctly.
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 tool has zero parameters, and the schema is empty. As per baseline, with no parameters the description does not need to add parameter information. It correctly notes that the tool lists airports, which aligns with no input requirements.
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 clearly states the verb 'List', the resource 'all Spanish airports in the AENA network', and includes specific attributes (IATA/ICAO codes and city). This makes it distinct from sibling tools like search_flights and get_flight, which deal with flights.
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 implies that this tool is for retrieving airport lists, and given context signals, siblings are flight-related. However, it does not explicitly state when to use this tool over alternatives or mention exclusions. The usage context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List flights for an AENA airport (arrivals or departures). Codeshares of the same physical flight are collapsed into one entry by default. Filter by flight number and/or a local-time window (e.g. afternoon = fromLocal 12:00, toLocal 20:00). Times in the output are local Madrid time.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Only flights on this local date (YYYY-MM-DD). Defaults to today when fromLocal/toLocal is set. | |
| source | No | auto | |
| airport | Yes | Airport IATA code, e.g. MAD, BCN, SCQ | |
| toLocal | No | Only flights scheduled at or before this local time (HH:MM), e.g. 20:00 for afternoon | |
| direction | Yes | ||
| fromLocal | No | Only flights scheduled at or after this local time (HH:MM), e.g. 12:00 for afternoon | |
| hoursBack | No | REST window: hours into the past | |
| flightNumber | No | Filter client-side, e.g. IB0459 or UX7235 | |
| hoursForward | No | REST window: hours into the future | |
| collapseCodeshares | No | Collapse codeshares of the same flight into one entry (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses several useful behaviors: codeshares are collapsed by default, output times are in local Madrid time, and filtering supports flight number and local-time windows. These go beyond the schema and help the agent anticipate output quirks. Minor omissions like pagination or error behavior exist, but the description is still above average.
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 three sentences, front-loaded with the primary action, and every sentence adds distinct information (scope, codeshare behavior, filters, timezone). No padding or repetition. Ideal conciseness for a tool of this complexity.
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?
For a tool with 10 parameters and no output schema, the description covers the core use case but omits some important context. It does not explain the two filtering modes (local-time window vs. REST window with hoursBack/hoursForward), nor the 'source' parameter (auto/website/rest). The date fallback behavior is also missing. These gaps may lead to under-utilization or misuse, so completeness is adequate but not thorough.
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?
Schema coverage is high (80%), so baseline is 3. The description adds semantic value by clarifying how fromLocal/toLocal work together ('afternoon = 12:00 to 20:00'), explicitly mentioning the flightNumber filter, and restating the default codeshare collapse behavior. This supplements the schema descriptions without being redundant.
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 clearly states the action ('List flights') and the specific resource ('AENA airport' with arrivals/departures). It also differentiates from siblings: get_flight (likely a single flight lookup) and list_airports (airport list), by explicitly scoping to flights with direction and filters.
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 provides clear context on when to use the tool (listing flights for an AENA airport with direction and optional filters). It does not explicitly mention alternatives or exclusion criteria, but the context is strong enough to guide selection among siblings. No misleading usage guidance is present.
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. Dates show when Glama detected each change.
v0.1.3search_flights5 fields changedInput schema / properties / airport / descriptionPrevious value: -"Airport IATA code, e.g. MAD, BCN, LCG"New value: +"Airport IATA code, e.g. MAD, BCN, SCQ"Input schema / properties / collapseCodesharesAdded value: +{
+ "default": true,
+ "description": "Collapse codeshares of the same flight into one entry (default true)",
+ "type": "boolean"
+}Input schema / properties / dateAdded value: +{
+ "description": "Only flights on this local date (YYYY-MM-DD). Defaults to today when fromLocal/toLocal is set.",
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}Input schema / properties / fromLocalAdded value: +{
+ "description": "Only flights scheduled at or after this local time (HH:MM), e.g. 12:00 for afternoon",
+ "pattern": "^\\d{1,2}:\\d{2}$",
+ "type": "string"
+}Input schema / properties / toLocalAdded value: +{
+ "description": "Only flights scheduled at or before this local time (HH:MM), e.g. 20:00 for afternoon",
+ "pattern": "^\\d{1,2}:\\d{2}$",
+ "type": "string"
+}v0.1.1get_flightlist_airportssearch_flightsEach tool has a distinct purpose: search_flights returns a list, get_flight returns a single flight, and list_airports provides airport data. While get_flight is a convenience wrapper over search_flights, the intent is clear and the usage patterns are unambiguous.
All tool names use verb_noun snake_case: search_flights, get_flight, list_airports. The verbs vary (search, get, list) but the pattern is consistent and the naming is predictable.
With only 3 tools, the server is tightly focused on flight and airport information. This is a well-scoped count for the domain—neither too sparse nor overloaded, and each tool serves a clear function.
The domain is read-only flight lookup and airport listing. The set covers listing all airports, searching flights with flexible filters, and retrieving a specific flight. There are no obvious dead ends or missing core operations for this purpose.
Airports MCP — wraps AirportGap API (free, no auth required)
Flights MCP — wraps OpenSky Network API (free, no auth required)
14 Korean airports flight info + Incheon arrival/departure congestion + facility search.
Aviationstack MCP — global flight + airport + airline data
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MrGo2/aena-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
