Claude Desktop MCP 服务器，可帮助您使用 Flightradar24 数据实时追踪航班。非常适合航空爱好者、旅行规划师或任何对飞行感兴趣的人！
🔍 实时追踪任何航班
⏰ 获取特定航班的到达和起飞时间
🌉 查看机场的航班状态
🚨 监控紧急航班
Related MCP server: airplanes-live-mcp
您的计算机上已安装Claude Desktop
Flightradar24 API 密钥（从Flightradar24 网站获取）*
将此存储库克隆到您的计算机上的某个位置：
git clone https://github.com/sunsetcoder/flightradar24-mcp-server.git安装依赖项并构建项目：
cd flightradar24-mcp-server
npm install
npm run build打开您的 Claude Desktop 配置文件：
# On Mac:
~/Library/Application Support/Claude/claude_desktop_config.json
# On Windows:
%APPDATA%/Claude/claude_desktop_config.json将以下内容添加到配置中的mcpServers对象：
{
"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"
}
}
}
}重要步骤：
将/FULL/PATH/TO/flightradar24-mcp-server替换为您克隆存储库的实际完整路径
在env部分添加您的 Flightradar24 API 密钥
确保在路径中使用正斜杠 ( / )，即使在 Windows 上
重新启动 Claude Desktop 以使更改生效
将.env.example复制到.env ：
cp .env.example .env使用您的实际 Flightradar24 API 密钥更新.env文件：
FR24_API_KEY=your_actual_api_key_here注意：切勿将实际的 API 密钥提交到版本控制。出于安全原因，git 会忽略.env文件。
服务器配置完成后，您可以向 Claude 询问以下问题：
“联合航空 UA123 航班的预计到达时间是什么时候？”
“显示目前在旧金山国际机场的所有航班”
“该地区有紧急航班吗？”
“显示未来 2 小时内抵达旧金山国际机场的所有国际航班”
“目前有多少商业航班飞越太平洋？”
“确定在加州地区宣布紧急状态的所有航班”
与 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]检查claude_desktop_config.json中的路径是否正确
确保使用完整的绝对路径
验证您的 API 密钥是否正确
尝试重启 Claude Desktop
确保您的 Flightradar24 API 密钥有效
检查API URL是否正确
在服务器日志中查找任何错误消息
注意：使用 Flightradar24 的 API 需要订阅
确保 Claude Desktop 已正确安装
验证您的 Flightradar24 API 密钥是否有效
检查配置文件中的路径是否正确
在 MCP 服务器日志中查找错误消息
麻省理工学院
为航空爱好者倾情打造
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_flight_etaget_flight_positionsScored across 2 tools
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.
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
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
Flights MCP — live aircraft tracking + aircraft/route registry
