Skip to main content
Glama
enesjakozh
sunsetcoder

flightradar24-mcp-server

by sunsetcoder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Flightradar24 MCP 서버 🛩️

Flightradar24 데이터를 사용하여 실시간으로 항공편을 추적할 수 있는 Claude Desktop MCP 서버입니다. 항공 애호가, 여행 기획자, 또는 상공 비행에 관심 있는 모든 분께 안성맞춤입니다!

이게 뭘 할 수 있나요? ✨

  • 🔍 실시간으로 모든 항공편을 추적하세요

  • ⏰ 특정 항공편의 도착 및 출발 시간을 확인하세요

  • 🌉 공항의 항공편 상태 보기

  • 🚨 비상 비행 모니터링

Related MCP server: airplanes-live-mcp

설정 가이드 🚀

1. 필수 조건

2. 설치

  1. 컴퓨터의 어딘가에 이 저장소를 복제하세요.

    지엑스피1

  2. 종속성을 설치하고 프로젝트를 빌드합니다.

    cd flightradar24-mcp-server
npm install
npm run build

3. Claude Desktop과의 통합

  1. Claude Desktop 구성 파일을 엽니다.

    # On Mac:
~/Library/Application Support/Claude/claude_desktop_config.json

# On Windows:
%APPDATA%/Claude/claude_desktop_config.json

  2. config의 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"
      }
    }
  }
}

  3. 중요 단계:

    • /FULL/PATH/TO/flightradar24-mcp-server 저장소를 복제한 실제 전체 경로로 바꾸십시오.

    • env 섹션에 Flightradar24 API 키를 추가하세요.

    • Windows에서도 경로에 슬래시( / )를 사용해야 합니다.

  4. 변경 사항을 적용하려면 Claude Desktop을 다시 시작하세요.

환경 설정

  1. .env.example``.env 로 복사합니다.

    cp .env.example .env

  2. 실제 Flightradar24 API 키로 .env 파일을 업데이트하세요.

    FR24_API_KEY=your_actual_api_key_here

참고: 실제 API 키를 버전 관리 시스템에 커밋하지 마세요. 보안상의 이유로 .env 파일은 git에서 무시됩니다.

한번 시도해 보세요! 🎮

서버가 구성되면 Claude에게 다음과 같은 질문을 할 수 있습니다.

  1. "유나이티드 항공 UA123편의 예상 도착 시간은 얼마인가요?"

  2. "현재 SFO에 있는 모든 항공편을 보여주세요"

  3. "이 지역에 비상 항공편이 있나요?"

  4. "다음 2시간 안에 SFO에 도착하는 모든 국제선 항공편을 보여주세요"

  5. "현재 태평양을 통과하는 상업 항공편은 몇 편이나 됩니까?"

  6. "캘리포니아 지역에서 비상사태를 선언한 항공편을 식별하세요"

클로드와의 대화 예시:

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이 올바른지 확인하세요

  • 서버 로그에서 오류 메시지를 찾아보세요.

FlightRadar API 액세스

  • 참고: Flightradar24의 API를 사용하려면 구독이 필요합니다.

더 많은 도움이 필요하신가요? 🆘

  1. Claude Desktop이 제대로 설치되었는지 확인하세요.

  2. Flightradar24 API 키가 활성화되어 있는지 확인하세요.

  3. 구성 파일의 경로가 올바른지 확인하세요

  4. MCP 서버 로그에서 오류 메시지를 찾으세요.

라이센스 📄

MIT

항공 매니아들을 위해 ❤️로 만들었습니다

Available Tools

2 tools
get_flight_etaB

Get estimated arrival time for a specific flight

ParametersJSON Schema
NameRequiredDescriptionDefault
flightNumberYesFlight number (e.g., UA123)

TDQS

B3.4/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_flight_positionsC

Get real-time flight positions with various filtering options

ParametersJSON Schema
NameRequiredDescriptionDefault
airportsNoComma-separated list of airport ICAO codes
boundsNoGeographical bounds (lat1,lon1,lat2,lon2)
categoriesNoAircraft categories (P,C,J)
limitNoMaximum number of results

TDQS

C2.7/5.0
Behavior2/5

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.

Conciseness2/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

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 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedget_flight_eta
    • First observedget_flight_positions
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

B3.2/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow the same 'get_flight_' prefix and snake_case pattern, ensuring predictable naming.

Tool Count3/5

With only 2 tools, the server is on the borderline of being too thin for a flight tracking service, but not extremely mismatched.

Completeness2/5

Obvious gaps exist: missing tools for searching flights, getting detailed flight info, or accessing historical data, making the surface incomplete for flight tracking.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches