Flightradar24のデータを使ってリアルタイムでフライトを追跡できるClaudeデスクトップMCPサーバー。航空愛好家、旅行プランナー、上空を飛ぶ飛行機に興味がある方など、どなたにも最適です。
🔍 あらゆるフライトをリアルタイムで追跡
⏰ 特定のフライトの到着時刻と出発時刻を取得する
🌉 空港のフライト状況を確認する
🚨 緊急飛行を監視する
Related MCP server: airplanes-live-mcp
お使いのコンピュータにClaude Desktopがインストールされています
Flightradar24 API キー ( Flightradar24 の Web サイトから取得)*
このリポジトリをコンピューターのどこかにクローンします:
git clone https://github.com/sunsetcoder/flightradar24-mcp-server.git依存関係をインストールしてプロジェクトをビルドします。
cd flightradar24-mcp-server
npm install
npm run buildClaude 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キーをバージョン管理にコミットしないでください。.envファイル.envセキュリティ上の理由からGitによって無視されます。
サーバーが設定されると、次のような質問を Claude に尋ねることができます。
「ユナイテッド航空UA123便の到着予定時刻は？」
「現在SFOにあるすべてのフライトを表示」
「この地域に緊急飛行はありますか？」
「今後2時間以内にサンフランシスコ国際空港に到着するすべての国際便を表示」
「現在、太平洋上空を飛行している商業便は何便ありますか？」
「カリフォルニア地域で緊急事態を宣言した航空便を特定する」
クロードとの会話の例:
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
