Airside Labs Aviation Tools
Aviation identity resolution and an AI use-case atlas, with provenance and temporal validity
| Endpoint | https://mcp.airsidelabs.com/mcp (streamable-http) |
|---|---|
| Registry version | 1.3.0 |
| Now | 29 tools · grade F (30) · pin ts_d37ae2ff9f5fd85af8faa1719b31ca33 · protocol 2025-06-18 |
| First / last listed | 2026-10-24 19:29 UTC / 2026-10-24 19:29 UTC |
| Grade over time | 2026-10-24: F (30), 29 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: resolve_airport resolve_airline resolve_aircraft_type resolve_registration parse_flight_identifier flight_airframes airframe_flights validate_identifiers report_unmet_need use_case_landscape search_use_cases get_use_case similar_use_cases data_requirements trace_data_lineage trace_workflow easa_ai_framework scenarios get_scenario airport_network_integration airport_operator airport_operations_status airport_connectivity airport_size_band airport_runways route_capacity airport_fleet_mix submit_suggestion feedback_status
resolve_airport | Which aerodrome does this airport code or name refer to on a given date?
Accepts an IATA three-letter code, an ICAO four-letter code, an airport
name fragment or a city name. Returns the aerodrome with its codes,
location, elevation, IANA timezone and type (large, medium, small,
heliport or closed).
Pass `as_of` whenever the question concerns a past date. Airport codes move
between aerodromes: A params: identifier*, as_of, country_hint |
resolve_airline | Which airline does this designator, name or callsign refer to on a date?
Accepts an IATA two-character designator, an ICAO three-letter designator,
an airline name or a callsign. Returns the operator with both designators,
country, operational status and, where an airline ceased, its successor.
`as_of` matters more here than for any other tool. IATA two-character
designators are heavily reused: params: identifier*, as_of |
resolve_aircraft_type | Which aircraft type does this designator or marketing name refer to?
Accepts an ICAO type designator (A21N) or a marketing name people actually
say ("A321neo", "Dash 8-400", "777-300ER", "Q400"). Returns the ICAO
designator, manufacturer, model, engine count and type, aircraft class, and
the ICAO wake turbulence category.
A name that identifies a family rather than a variant -- "Dreamliner",
"77 params: identifier*, as_of |
resolve_registration | Which airframe wore this registration on a given date?
Accepts a tail number in any common form: VH-OQA, VHOQA, lowercase, padded
with whitespace. Returns the aircraft with its country of registry, ICAO
type designator, an embedded resolved aircraft type, operator, owner,
serial number and Mode-S hex address.
A registration is a slot rather than a permanent name: marks are
surrendered and reissu params: registration*, as_of |
parse_flight_identifier | Split a flight designator into carrier and number, and identify the carrier.
Accepts the forms that arrive in real message traffic: TK1979, BAW276,
"U2 8341", BA02490, BA2490A. Returns the parsed carrier with its resolved
airline, the flight number, any operational suffix, which scheme was used
(IATA or ICAO), and both normalised forms.
Two things this tool will not do. It will not tell you who params: text*, date, context |
flight_airframes | Which airframes have been heard operating this airline flight, how often and when --
from Airside Labs' own ADS-B receiver?
Accepts a flight in any common form: BA49, BAW49, "BA 49", VS105. Returns each airframe
heard broadcasting that Flight ID within the receiver's footprint, with its Mode-S
address, registration and ICAO type (joined from the registrations dataset), how many
receiver poll cycl params: flight* |
airframe_flights | Which flights has this airframe been heard or filed operating, how often and when --
the inverse of flight_airframes, from Airside Labs' own ADS-B receiver and the FAA
flight-plan feed?
Accepts a registration in any common form (G-XWBA, N101DU, PH-BHA) or a Mode-S address
(406a3d). A registration is resolved first, so `as_of` matters for a re-issued mark: the
answer names the airframe it resolved params: identifier*, as_of |
validate_identifiers | Do these aviation identifiers describe the same thing on this date?
Give any combination of a registration (tail number), a Mode-S 24-bit
address, an ICAO type designator, an operator name, an airline designator
(IATA or ICAO), a callsign and a flight designator, plus `as_of`. Each
pair that can be checked is checked, and every check comes back with a
verdict -- `consistent`, `contradicted` or `u params: registration, mode_s_hex, icao_type, operator, airline, callsign, flight, as_of |
report_unmet_need | Tell us what you came looking for and could not get from these tools.
Call this when you needed something aviation-related that this toolset did
not give you. It is not an error channel and it is not a retry: it is how
the next version of these tools learns what is missing. A need reported
here is appended to this service's own feedback store, on the same server
that answered you, and reviewed la params: sought*, gap_kind*, tool_tried, identifier, detail |
use_case_landscape | How many use cases are there, sliced one way? Counts you can quote.
`group_by` is one of org_type (16 canonical organisation types: Airport,
Airline, Air Navigation Service Provider, Ground Handling, Regulator /
Authority, Aerospace Manufacturing, MRO / Maintenance …), sector, role
(500+ roles), ai_level, hazard_class, or cadence_class (counts data
requirements rather than use cases). Filters AND params: group_by, org_type, sector, role, ai_level, hazard_class, screened_only, limit |
search_use_cases | Which aviation AI use cases match this text? Find candidates by keyword.
Full-text search (BM25, stemmed) over 6,500 use cases spanning airports,
airlines, ANSPs, ground handlers, regulators, manufacturers and more, each
attached to a role and an organisation type. Returns summaries only --
id, short text, role, organisation type, EASA screen -- capped at 25.
Use get_use_case for the full record params: query*, org_type, sector, role, ai_level, hazard_class, screened_only, limit |
get_use_case | The full record for one use case, by id from a search or landscape result.
Returns the use-case text; the role that owns it with its description; the
organisation type (canonical and as the corpus names it); every data
requirement -- title, description, nominal update rate with a normalised
cadence class (real_time … annual), and the kind of system it typically
comes from; the EASA screen (AI lev params: use_case_id* |
similar_use_cases | What else in the catalogue is like this use case? Nearest neighbours by meaning.
Returns up to 20 use cases closest in embedding space (bge-base cosine
over the use-case text), as summaries with a `similarity`. Good for "what
else is like the one we picked", for finding the same idea stated for a
different role or organisation type, and for spotting near-duplicates
before counting them as two.
S params: use_case_id*, org_type, screened_only, limit |
data_requirements | What data does this use case, role or organisation type need, and how fresh?
Three modes. With `use_case_id`: that use case's requirements verbatim --
title, normalised title_family, description, nominal update rate,
normalised cadence class and the kind of source system. With `query`:
REVERSE lineage -- full-text search over requirement titles and
descriptions (the inputs, not the use-case text) params: use_case_id, query, role, org_type, sector, screened_only, limit |
trace_data_lineage | Which standard operational messages would evidence this data need?
The lineage spine is use case -> data requirement -> requirement family ->
standard message type -> data elements. Four modes. With `use_case_id`:
that use case's requirements grouped by family, each family with the
standard messages that evidence it (relevance primary/supporting, cadence,
element count) -- plus `requirements_with params: use_case_id, family, message_id |
trace_workflow | What happens before and after this use case, and who hands off to whom?
The catalogue is otherwise flat -- role, use case, data requirement -- with
no edges. This is the edges: named operational sequences with their steps in
order, the role at each step, the `gate` that must hold before the next one
may start, and what passes between roles at each handoff (headset, radio,
hand signal, system, vis params: workflow_id, use_case_id, phase |
easa_ai_framework | The EASA AI-level and hazard-class tables, page-cited, to read a screen against.
Returns the AI levels (0, 1A, 1B, 2A, 2B, 3A, 3B: what the system does and
how much authority the end user keeps), the hazard classes (H1-H5: worst
credible effect and the assurance level it implies at acceptable and
moderate risk), the technique ceilings (which AI techniques the Concept
Paper accepts up to which lev params: level, hazard_class |
scenarios | Which real operational episodes does the catalogue carry, to illustrate use cases with?
A scenario is one real day reconstructed from data Airside Labs holds and
may publish: FAA SWIM flight plans, FAA NOTAMs, its own ADS-B receiver. Each
is a UTC window at a place, a timeline whose every event names the raw
record it came from, and a set of lenses -- one use case's cut of the day,
with the actua params: none |
get_scenario | One real episode end to end: what happened, where and when (UTC), the actors,
what it shows and what it must not be read as; the timeline, every event with its
actor, source and the reference of the raw record it came from; and the lenses,
each a use case's cut of the day with a small evidence table, an implication, and
the use cases it illustrates with a reason for each.
Use it when a brief need params: scenario_id*, events, lenses |
airport_network_integration | What level of network integration does this airport have with the EUROCONTROL Network
Manager, or with the FAA's TFDM programme, as of a date?
Answers with one value: `ani` (Advanced Network Integrated: A-CDM with the higher level of
integration), `acdm` (all DPI message types sent to the network, so a TOBT and TSAT stream
exists), `adv_twr` (Advanced ATC TWR: E-DPI, C-DPI and A-DPI only, no TOBT params: identifier*, as_of |
airport_operator | Who operates this airport, which group would take the commercial meeting, and who owns
it?
Returns operator_name, operator_group (the parent that a sales or partnership conversation
lands with, spelled consistently: Aena, MAG, Groupe ADP, Fraport, VINCI Airports, Adani and
so on), ownership_class (public-national, public-regional, private-group,
private-individual, concession-mixed or unknown), o params: identifier* |
airport_operations_status | Is there a positive, sourced reason this airport is not open for ordinary commercial
engagement: closed to civil traffic, in a sanctioned jurisdiction, or a general-aviation
field with no scheduled service?
Returns `closed` (no civil passenger operations), `restricted` (the airport operates but
sits under UK sanctions guidance for its jurisdiction, with the guidance page cited),
`general-aviation params: identifier* |
airport_connectivity | How many nonstop destinations does this airport publish, and in which countries?
Returns the count of nonstop destinations from the airport's published destination table,
the number resolved to a country, the destinations by country, and the counts to the United
States, the Gulf and the UAE, with the date of the read.
This is presence, not frequency: one weekly seasonal service and a daily trunk params: identifier* |
airport_size_band | Which ACI passenger size band is this airport in, on its latest published annual total?
Returns the passengers figure, its year, and the band on ACI World's published ASQ size
categories: under 2M, 2 to 5M, 5 to 15M, 15 to 25M, 25 to 40M, over 40M passengers per year.
The figure comes from the airport's Wikipedia infobox (its latest published annual total),
not from ACI, so airports are not on a params: identifier* |
airport_runways | What runways does this aerodrome publish in its state AIP, with what dimensions,
surface, bearings, thresholds and declared distances, and for which AIRAC cycle?
Returns every runway the state's export lists for the aerodrome: designator, length
and width, surface and PCN, the runway strip, and per direction the threshold
coordinates, true and magnetic bearing, the approach slope indicator (PAPI params: identifier* |
route_capacity | How much scheduled capacity is flown nonstop from one airport to another, by whom and
on what, over the last N months of BTS T-100 data?
Returns monthly departures performed, seats and passengers with the load factor, and the
same broken down by carrier and aircraft type with seats per departure and the sector
distance (BTS statute miles, and nautical miles converted). The pair is DIRECTIONAL:
SE params: origin*, dest*, months, scheduled_only |
airport_fleet_mix | What aircraft types fly from (or into) an airport, how often, with how many seats, and
at what load factor, over the last N months of BTS T-100 data?
Returns each type's departures performed and share of the airport's departures, seats,
passengers, load factor, seats per departure, and how many carriers and destinations it
serves, plus airport totals. `direction` is `departures` (default) or `arr params: airport*, months, direction |
submit_suggestion | Record a suggestion about this toolset or its use-case catalogue. No API
key is needed for this tool.
The suggestion is written as one record into this server's own local
feedback store and nothing else happens: no message, notification, email
or request goes to any website, person or other system, now or later, and
the tool does not read the store back. Airside Labs reads the store when
preparin params: suggestion*, category, use_case_id, page_slug, contact |
feedback_status | What happened to a suggestion or unmet-need report filed here? No API key is needed.
Pass the `fingerprint` from a submit_suggestion or report_unmet_need receipt (12 hex
characters). Returns `status`: `shipped` (a person acted on it and the change is live, with
what shipped and when), `declined` (read and not taken up, with the reason), `acknowledged`
(read, still open) or `open` (recorded, not y params: fingerprint* |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.