MCP Server for Flight Data — Connect Aviation Data to AI Agents

The official AirLabs MCP server connects real-time flight data to AI assistants like Claude and Cursor. Learn what the Model Context Protocol is, how it differs from function calling, and how to install and use the AirLabs flight data MCP server.

Sergey St.

Published on Jun 25th 26

Share:

• 
• 
• 

Flight Data, Now Native to Your AI Assistant

If you have already read our guide on the Flight Data API for AI Agents and LLM Applications, you know why AI agents need a structured aviation data layer: a language model cannot invent a live gate number or an actual arrival time, so it must call an external API. That article covered the broad picture of tool use and which AirLabs endpoints map to which agent capabilities. This guide focuses on the mechanism that has become the standard way to make that connection — the Model Context Protocol (MCP) — and on the official AirLabs MCP server, which is now available and open source at github.com/airlabs-co/airlabs-mcp.

MCP is an open standard, introduced by Anthropic in late 2024 and adopted across the AI ecosystem through 2025 and 2026, that defines a uniform way for an AI application to discover and call external tools and data sources. Where a REST API describes how a program fetches data, MCP describes how an AI agent fetches data — including how the agent learns what tools exist, what arguments they take, and how to interpret what comes back.

The practical consequence is powerful: instead of writing bespoke tool definitions inside every agent you build, an MCP server exposes flight data as a set of well-described tools, and any MCP-compatible client — Claude Desktop, Cursor, an IDE assistant, or a custom agent — can connect and immediately use them. With the AirLabs MCP server, you do not even have to write that server yourself: install it, add your API key, and your assistant can answer aviation questions out of the box.

"Function calling taught models to use one tool at a time inside one application. MCP turns tools into infrastructure — a server you connect once, that every agent can plug into. The AirLabs MCP server is that infrastructure for flight data, ready to install."

MCP vs Function Calling: What Actually Changes

Developers familiar with OpenAI function calling or Anthropic tool use often ask how MCP is different, since both let a model call external functions. The distinction is architectural, and it explains why a shared server is the better design for a data capability.

With classic function calling, the tool definitions live inside your application code. You hard-code a JSON schema describing each function, pass those schemas to the model on every request, and your application receives the model's chosen call, executes it, and feeds the result back. Every application that needs flight data re-implements this wiring. Build three agents, and you write the flight tool schemas three times.

With MCP, the tool definitions live in a separate server process that speaks a standard protocol. The server advertises its tools through a discovery mechanism, so any compatible client can ask "what can you do?" and receive the full list of tools and their schemas at runtime. The same server can serve many different agents and applications at once.

Neither approach is "better" in the abstract. If you are adding a flight lookup to one specific chatbot, function calling against the AirLabs API directly — as described in our AI agents guide — is perfectly sufficient. But when you want aviation data to be a reusable capability that several agents, tools or teammates can share, an MCP server is the cleaner design — and the AirLabs MCP server gives you that without building it from scratch.

Installing the AirLabs MCP Server

The AirLabs MCP server is published as an npm package and installs in one line. You will need Node.js 18 or higher and a free AirLabs API key from airlabs.co/signup.

npm install -g @airlabs-co/airlabs-mcp

To connect it to Claude Desktop, add the server to your claude_desktop_config.json, supplying your API key as an environment variable:

{
  "mcpServers": {
    "airlabs": {
      "command": "npx",
      "args": ["@airlabs-co/airlabs-mcp@latest"],
      "env": {
        "AIRLABS_API_KEY": "your_api_key_here"
      }
    }
  }
}

After restarting the client, the assistant can answer aviation questions directly. The same server works with Cursor and any other MCP-compatible client over the standard stdio transport — point the client at the package and provide the key. Because the entire server is a single open-source file, you can also clone the repository, inspect exactly what it does, and run it from source if you prefer.

What the Server Exposes: Tools Mapped to Endpoints

An MCP server exposes tools — actions the model can invoke, each with a name, a description, and an input schema. The AirLabs server defines one tool per endpoint, with self-documenting names so the model can match a user's question to the right operation. The current tool set:

The principle of one tool per endpoint is deliberate. It is tempting to expose a single generic call_airlabs tool, but a model selects far more reliably among several specifically-named tools than when asked to construct an arbitrary call to one catch-all. get_flight_status and find_nearest_airport describe themselves; an opaque single tool does not.

Each tool's description also documents when to use it and how tools chain together, because AirLabs identifies everything by IATA/ICAO codes. The recurring pattern is resolve-then-query: turn a name into a code, then query with that code. For "which airports does Wizz Air fly to from Sofia soon?", the server's descriptions guide the model to resolve the airline name to a code via get_airline_info, the city to an airport code via search_airport_code, then call get_airport_schedule and expand destination codes with get_airport_info.

What a Tool Call Looks Like

When the server receives a get_flight_status call from the model, it translates that into a single AirLabs request and returns the structured result. The underlying call is exactly the REST request you would make directly:

GET https://airlabs.co/api/v9/flight?flight_iata=LH401&_fields=status,arr_estimated,arr_delayed,arr_terminal,arr_gate&api_key={KEY}

{
  "response": {
    "flight_iata": "LH401",
    "status": "active",
    "arr_estimated": "2026-06-21 06:55",
    "arr_delayed": 25,
    "arr_terminal": "1",
    "arr_gate": "B43"
  }
}

The server takes the model's tool call, fills in the AirLabs request, executes it, and hands the JSON back to the model, which phrases the answer. Note the use of _fields: the tool can request only the fields it needs, so the response is a handful of values rather than a full object — a small detail that matters when an agent chains several calls inside one conversation turn.

Because every AirLabs endpoint shares the same authentication (a single API key), the same predictable JSON wrapper, and the same versioned /v9/ URLs, the server stays simple: no per-tool OAuth flow, no token refresh, and no risk that a model-facing schema drifts when the API changes, since breaking changes land in a new version path rather than altering the current one.

How the Server Connects to AI Clients

Once installed, connecting the server to a client is configuration rather than coding — which is the payoff of the MCP approach.

For a local, desktop setup, the server runs on your machine and communicates over stdio. A client such as Claude Desktop or an MCP-capable IDE assistant like Cursor is pointed at the package in its configuration, and on the next launch the client performs the handshake — asking the server what tools it offers — and surfaces the flight tools automatically. From the user's side, they simply start asking the assistant aviation questions, and it now has live flight capabilities.

The crucial point is that the client needs no aviation-specific code. All knowledge of how to call flight data — the endpoints, the parameters, the field selections — lives in the server. As the server is updated (new tools, refined descriptions), every connected client benefits without any change on its side.

A Lighter Alternative: The AirLabs Skill File

The MCP server is the right choice when you want a reusable capability shared across clients. For a single agent that just needs fast, accurate access to AirLabs endpoints, there is a lighter complement.

AirLabs publishes a ready-made Skill file at airlabs.co/skill.md, following the open SKILL.md standard for AI agent skills. It is a single markdown file containing endpoint descriptions, parameter explanations, common request patterns and example responses, written for AI agents to load and follow. Compatible agents — including Claude Code, Cursor and Copilot — can read it and immediately know how to call AirLabs endpoints correctly.

The two approaches sit well together. The Skill file is the fastest way to make a single agent aviation-aware; the MCP server is the way to make flight data shared infrastructure that many agents connect to. Many teams prototype with the Skill file, then adopt the MCP server when flight data needs to be a reusable capability across several products.

Why the AirLabs API Is a Good MCP Backend

A flight-data MCP server is only as good as the API behind it. Several characteristics of the AirLabs API make it a clean foundation for the tool layer.

The predictable JSON schema with consistent field names across endpoints means each tool result is easy for the model to parse, and the response wrapper is uniform whether the model called get_flight_status or find_routes. Single-key authentication keeps the server simple, with no OAuth flow to maintain per tool. Field selection via _fields lets each tool return only what it needs, which is essential for keeping an agent's context window efficient across chained calls. Self-documenting endpoint names — /flights, /airports, /airlines, /routes — translate naturally into self-documenting tool names. And stable, versioned URLs mean the deployed server keeps working as the API evolves, because changes arrive in new version paths rather than altering the endpoints the tools depend on.

Get Started with the AirLabs MCP Server

If you are building AI agents that need aviation data — whether a single assistant via the Skill file or a reusable MCP server feeding many clients — AirLabs gives you both the structured backend and the ready-to-install server.

Supported API Features

The MCP server exposes these endpoints as tools:

• Flight Information API for single-flight status — the get_flight_status tool.
• Schedules API for departures and arrivals — the get_airport_schedule tool.
• Flight Delays API for delayed flights — the monitor_delays tool.
• Real-Time Flights API for live positions — the track_live_flights tool.
• NearBy API for airport search by coordinates — the find_nearest_airport tool.
• Name Suggestion API for resolving place names to codes — the search_airport_code tool.
• Airlines and Airports databases — the get_airline_info and get_airport_info tools.
• Fleets Database for aircraft lookup — the lookup_aircraft tool.
• Routes Database for network queries — the find_routes tool.
• A ready-made Skill file for the fast path to an aviation-aware agent.

The server is open source at github.com/airlabs-co/airlabs-mcp — install it, star it, or contribute. Get a free flight API key and connect it to your assistant in minutes.

If you need more information, don't hesitate to contact us. We are always happy to help you design the right integration for your AI application.