Un servidor MCP de Claude Desktop que te ayuda a rastrear vuelos en tiempo real con datos de Flightradar24. ¡Perfecto para entusiastas de la aviación, planificadores de viajes o cualquier persona interesada en los vuelos aéreos!
🔍Sigue cualquier vuelo en tiempo real
⏰ Obtenga horarios de llegada y salida de vuelos específicos
🌉 Ver el estado de los vuelos en un aeropuerto
🚨 Monitorizar vuelos de emergencia
Related MCP server: airplanes-live-mcp
Claude Desktop instalado en tu ordenador
Una clave API de Flightradar24 (obtenga una en el sitio web de Flightradar24 )*
Clona este repositorio en algún lugar de tu computadora:
git clone https://github.com/sunsetcoder/flightradar24-mcp-server.gitInstalar dependencias y compilar el proyecto:
cd flightradar24-mcp-server
npm install
npm run buildAbra el archivo de configuración de Claude Desktop:
# On Mac:
~/Library/Application Support/Claude/claude_desktop_config.json
# On Windows:
%APPDATA%/Claude/claude_desktop_config.jsonAgregue lo siguiente al objeto mcpServers en su configuración:
{
"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"
}
}
}
}Pasos importantes:
Reemplace /FULL/PATH/TO/flightradar24-mcp-server con la ruta completa real a donde clonó el repositorio
Agregue su clave API de Flightradar24 en la sección env
Asegúrese de utilizar barras diagonales ( / ) en la ruta, incluso en Windows
Reinicie Claude Desktop para que los cambios surtan efecto.
Copiar .env.example a .env :
cp .env.example .envActualice el archivo .env con su clave API de Flightradar24 real:
FR24_API_KEY=your_actual_api_key_hereNota: Nunca envíes tu clave API al control de versiones. Git ignora el archivo .env por seguridad.
Una vez configurado el servidor, puedes hacerle a Claude preguntas como:
"¿Cuál es el tiempo estimado de llegada (ETA) del vuelo UA123 de United Airlines?"
"Muéstrame todos los vuelos actuales en SFO"
¿Hay algún vuelo de emergencia en la zona?
"Muéstrame todos los vuelos internacionales que llegan a SFO en las próximas 2 horas"
¿Cuántos vuelos comerciales hay actualmente sobre el Océano Pacífico?
Identificar cualquier vuelo que haya declarado emergencia en la región de California.
Ejemplo de conversación con 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]Comprueba si la ruta en claude_desktop_config.json es correcta
Asegúrese de utilizar la ruta absoluta completa
Verifique que su clave API sea correcta
Intente reiniciar Claude Desktop
Asegúrese de que su clave API de Flightradar24 sea válida
Compruebe si la URL de la API es correcta
Busque mensajes de error en los registros del servidor
Nota: El uso de la API de Flightradar24 requiere una suscripción.
Asegúrese de que Claude Desktop esté instalado correctamente
Verifique que su clave API de Flightradar24 esté activa
Comprueba que la ruta en tu archivo de configuración sea correcta
Busque mensajes de error en los registros del servidor MCP
Instituto Tecnológico de Massachusetts (MIT)
Hecho con ❤️ para entusiastas de la aviación
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
