This server provides real-time flight tracking and information using Flightradar24 data. With it, you can:
Track flights in real-time with filtering options by geographical bounds, airport ICAO codes, or aircraft categories
Get estimated arrival times (ETA) for specific flight numbers
View the status of flights currently at or around specific airports
Identify and monitor emergency flights
Uses .env files for configuration management, particularly for storing sensitive Flightradar24 API credentials securely outside of version control.
Allows tracking and querying United Airlines flights specifically, as demonstrated in the example query 'What's the status of flight UA123?'
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., "@flightradar24-mcp-server What's the status of flight UA123?"
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.
A Claude Desktop MCP server that helps you track flights in real-time using Flightradar24 data. Perfect for aviation enthusiasts, travel planners, or anyone curious about flights overhead!
đ Track any flight in real-time
â° Get arrival and departure times for specific flights
đ View the status of flights at an airport
đ¨ Monitor emergency flights
Related MCP server: airplanes-live-mcp
Claude Desktop installed on your computer
A Flightradar24 API key (get one from Flightradar24's website)*
Clone this repository somewhere on your computer:
git clone https://github.com/sunsetcoder/flightradar24-mcp-server.gitInstall dependencies & build the project:
cd flightradar24-mcp-server
npm install
npm run buildOpen your Claude Desktop configuration file:
# On Mac:
~/Library/Application Support/Claude/claude_desktop_config.json
# On Windows:
%APPDATA%/Claude/claude_desktop_config.jsonAdd the following to the mcpServers object in your config:
{
"mcpServers": {
"flightradar24-server": {
"command": "node",
"args": [
"/Users/<username>/<FULL_PATH...>/flightradar24-mcp-server/dist/index.js"
],
"env": {
"FR24_API_KEY": "your_api_key_here",
"FR24_API_URL": "https://fr24api.flightradar24.com"
}
}
}
}Important Steps:
Replace /FULL/PATH/TO/flightradar24-mcp-server with the actual full path to where you cloned the repository
Add your Flightradar24 API key in the env section
Make sure to use forward slashes (/) in the path, even on Windows
Restart Claude Desktop for the changes to take effect
Copy .env.example to .env:
cp .env.example .envUpdate the .env file with your actual Flightradar24 API key:
FR24_API_KEY=your_actual_api_key_hereNote: Never commit your actual API key to version control. The .env file is ignored by git for security reasons.
Once the server is configured, you can ask Claude questions like:
"What's the ETA for United Airlines flight UA123?"
"Show me all flights currently at SFO"
"Are there any emergency flights in the area?"
"Show me all international flights arriving at SFO in the next 2 hours"
"How many commercial flights are currently over the Pacific Ocean?"
"Identify any flights that have declared an emergency in the California region"
Example conversation with Claude:
You: What's the status of flight UA123?
Claude: Let me check that for you...
[Claude will use the MCP server to fetch real-time flight information]Check if the path in claude_desktop_config.json is correct
Make sure you're using the full absolute path
Verify your API key is correct
Try restarting Claude Desktop
Make sure your Flightradar24 API key is valid
Check if the API URL is correct
Look for any error messages in server logs
Note: Using Flightradar24's API requires a subscription
Make sure Claude Desktop is properly installed
Verify your Flightradar24 API key is active
Check the path in your configuration file is correct
Look for error messages in MCP server logs
MIT
Made with â¤ī¸ for aviation enthusiasts
Get estimated arrival time for a specific flight
| Name | Required | Description | Default |
|---|---|---|---|
| flightNumber | Yes | Flight number (e.g., UA123) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavior like data freshness, error handling, or that it is a read operation.
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?
Single, short sentence with no wasted words; perfectly concise.
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?
Low complexity but missing output description; agent cannot know what the tool returns (e.g., estimated arrival time format). Also lacks guidance on usage context.
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 100% with a description for flightNumber; tool description adds no extra parameter meaning, so baseline 3.
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?
Description clearly states verb 'Get' and resource 'estimated arrival time for a specific flight', differentiating from sibling 'get_flight_positions' which likely provides positions.
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?
Implies usage for a specific flight but provides no explicit when-to-use or when-not-to-use compared to sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time flight positions with various filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| airports | No | Comma-separated list of airport ICAO codes | |
| bounds | No | Geographical bounds (lat1,lon1,lat2,lon2) | |
| categories | No | Aircraft categories (P,C,J) | |
| limit | No | Maximum number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It indicates 'real-time' but does not disclose data freshness, update frequency, or any behavioral traits such as rate limits or data scope. The minimal description fails to provide necessary behavioral context beyond the obvious.
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 very short (one sentence) but underspecified for a tool with 4 parameters. It lacks structure and front-loads only the core purpose. The brevity sacrifices necessary detail, making it inadequate for effective tool use.
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 4 optional parameters and lack of output schema, the description is incomplete. It does not explain filtering behavior, default values, output format, or how parameters interact. This leaves significant gaps for an agent to invoke the 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?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it merely mentions 'filtering options' without elaborating on parameter usage or constraints. No improvement over the schema alone.
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 tool's purpose: 'Get real-time flight positions'. The addition of 'with various filtering options' hints at functionality but does not explicitly differentiate from the sibling tool 'get_flight_eta', which is about ETA. The distinction is implicit but not stated.
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?
No guidance is provided on when to use this tool versus alternatives. The phrase 'various filtering options' is vague and does not specify contexts, prerequisites, or exclusions. The sibling 'get_flight_eta' is not mentioned, missing an opportunity to clarify usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect: one provides ETA for a specific flight, the other gives real-time positions with filtering. No overlap in purpose.
Both tools follow the same 'get_flight_' prefix and snake_case pattern, ensuring predictable naming.
With only 2 tools, the server is on the borderline of being too thin for a flight tracking service, but not extremely mismatched.
Obvious gaps exist: missing tools for searching flights, getting detailed flight info, or accessing historical data, making the surface incomplete for flight tracking.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Flight search MCP server providing search, pagination, and itinerary details for AI assistants.
Geo-based flight search MCP server. Find more flights between any two places on earth
Flights MCP â wraps OpenSky Network API (free, no auth required)
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sunsetcoder/flightradar24-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
