MCP Server
Airside Labs Aviation Tools
com.airsidelabs/aviation-tools
What this MCP does
Resolves aviation identities and provides airport, airline, aircraft, route capacity, fleet, connectivity, operations, and aviation AI use-case data.
Capabilities
Tools
29
tools
airframe_flights
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 to and the Mode-S address(es) it looked up. Returns
each Flight ID the airframe was heard broadcasting within the receiver's footprint, or was
filed under in FAA flight plans, with sightings (receiver poll cycles in view), distinct
days seen, first and last seen, and which instrument observed it. `most_seen` and
`most_recent` name the services it is usually on; `flight_count` how many distinct Flight
IDs it carried in the window.
Why this matters: it is the most-asked question the resolution tools could not answer --
movement history for a tail. A fleet-watching, lessor or MRO agent that has resolved a
registration wants to know what it has been doing, and this is the only place that comes
from observation rather than a schedule or a tracking service.
Coverage is the station's footprint (about 180 nm, taking in Heathrow and Gatwick traffic
and the westbound Heathrow departure flow) plus departures filed from JFK, Newark and
Seattle. `not_heard` means the airframe was not observed in the window and says nothing
about whether it flew. A Flight ID identifies the service, not the route or the position:
this is not a track log and never a current location. Do NOT use it to assert where an
aircraft is or will be; say what it has been heard operating.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'airframe_flightsArguments', 'required': ['identifier'], 'properties': {'as_of': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'As Of', 'default': None}, 'identifier': {'type': 'string', 'title': 'Identifier'}}}
airport_connectivity
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 route count
the same. It is right for "does this airport connect to the US at all" and wrong for
"how much traffic does it exchange with the US"; frequency needs a schedule source, which
this dataset is not. Seasonal and suspended routes are counted when the table lists them.
`not_covered` means the airport is outside the public set or no destination table was
parsed.
`identifier` is an IATA or ICAO code, or an airport name; a name is resolved to its code first and the answer says so in its first note. Reading the answer: `status` is resolved, unresolved or not_covered. `confidence` is verified (named on an official list or read on the operator's own page), programmatic (derived from a public structured source and only as current as that source) or unknown. `provenance` names each source behind the answer; `source_url` and `as_of` are the citation. Unknown is never filled from the airport's country or size. `not_covered` means the airport is outside the public set rather than anything about the airport; report_unmet_need records which airport was wanted.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'airport_connectivityArguments', 'required': ['identifier'], 'properties': {'identifier': {'type': 'string', 'title': 'Identifier'}}}
airport_fleet_mix
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 `arrivals`.
`months` defaults to the last 12 of the window; pass null for the whole window.
Scheduled passenger service only.
This is the fleet-mix question a planner asks before sizing a route or a gate: what the
airport is actually flown with, from the census of segments carriers file, not from a
schedule or a fleet list.
Airports may be given as an IATA code, an ICAO code or a name. T-100 is filed under three-character codes that follow IATA, so an ICAO code or a name is resolved to the airport's IATA code first and the answer says so in its first note; `query` echoes the code that was looked up. Reading the answer: `status` is resolved, no_service or unresolved. `unresolved` means nothing was looked up (no airport matches, or it has no IATA code) and is never a statement about service. `totals` and `monthly` are sums of BTS-reported departures performed, seats and passengers; `load_factor` is passengers over seats. `provenance.edition` is the latest month held and `provenance.window` the months summed -- BTS publishes about three months in arrears, so this is accurate for its period and NOT current. Aircraft are given as the ICAO designator where the BTS type code is verified against FAA JO 7360.1K, otherwise as BTS's own description with `icao_designator` null and a note; never invent the designator. Pass an ICAO designator to resolve_aircraft_type for the type's certified and typical seating. Coverage is T-100's: US carriers everywhere, foreign carriers only to and from the US. Fares are not held; report_unmet_need records what was wanted.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'airport_fleet_mixArguments', 'required': ['airport'], 'properties': {'months': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Months', 'default': 12}, 'airport': {'type': 'string', 'title': 'Airport'}, 'direction': {'type': 'string', 'title': 'Direction', 'default': 'departures'}}}
airport_network_integration
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 or TSAT stream),
`tfdm_a` or `tfdm_b` (FAA Terminal Flight Data Manager configurations), `standard` (removed
from the Network Manager list by a notice), or `not_listed`. Each value carries its
definition, the notice that establishes it, the date it has held since, and the history of
changes across the notice chain.
The source is the Network Manager's own Information Notice "Updated list of A-CDM, Advanced
ATC TWR and ANI airports", parsed from each PDF in the chain from IN/25-001 (10 January 2025)
to the current one. Pass `as_of` for a historical question: Berlin Brandenburg and Barcelona
were `acdm` until 24 July 2025 and `ani` from 25 July; Edinburgh was removed on 4 December
2025 and back as `adv_twr` from 11 March 2026. Without a date you get today's list.
Do NOT read `not_listed` as "no A-CDM": the list records integration with the network, and
an airport can run a local A-CDM programme that never sends a DPI. Do NOT use this for the
airport's live status, slots or runway data, and do not infer it from airport size or a
vendor's press release; that inference is the confusion this tool exists to remove. The US
part rests on the DOT OIG report of 17 July 2024, the only public site list; the FAA names
no sites.
`identifier` is an IATA or ICAO code, or an airport name; a name is resolved to its code first and the answer says so in its first note. Reading the answer: `status` is resolved, unresolved or not_covered. `confidence` is verified (named on an official list or read on the operator's own page), programmatic (derived from a public structured source and only as current as that source) or unknown. `provenance` names each source behind the answer; `source_url` and `as_of` are the citation. Unknown is never filled from the airport's country or size. `not_covered` means the airport is outside the public set rather than anything about the airport; report_unmet_need records which airport was wanted.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'airport_network_integrationArguments', 'required': ['identifier'], 'properties': {'as_of': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'As Of', 'default': None}, 'identifier': {'type': 'string', 'title': 'Identifier'}}}
airport_operations_status
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` (no scheduled passenger service), or `no_exception_recorded`. The last
is exactly that: this dataset records exceptions with their sources; it does not confirm
that scheduled service exists, and a `no_exception_recorded` answer should not be quoted
as "open".
Read `method` before quoting a `closed`. `sanctions-register` and the other airport-level
methods are hand-read against a named source and carry the date the airport closed: Kyiv
Boryspil since 24 February 2022, Istanbul Atatürk since April 2019. `curated-airports-type`
means the airport's own record types it as closed and usually carries no date, so it
establishes that the aerodrome is closed and not when. `general-aviation` is only ever
airport-level: the absence of scheduled service is never inferred from an airport's type
or size.
The `restricted` value can come from a country-level rule (Russia, Iran) rather than an
airport-level fact; `method` is `jurisdiction-rule` when it does, the rule is applied to
the country the airport resolves to, and it is the UK's guidance, not a statement about
any other jurisdiction's law. An airport in one of those jurisdictions that nobody has
read individually still answers `restricted` on the country rule alone, and its notes say
so. Do NOT use this for daily operational status, NOTAMs or temporary closures.
`identifier` is an IATA or ICAO code, or an airport name; a name is resolved to its code first and the answer says so in its first note. Reading the answer: `status` is resolved, unresolved or not_covered. `confidence` is verified (named on an official list or read on the operator's own page), programmatic (derived from a public structured source and only as current as that source) or unknown. `provenance` names each source behind the answer; `source_url` and `as_of` are the citation. Unknown is never filled from the airport's country or size. `not_covered` means the airport is outside the public set rather than anything about the airport; report_unmet_need records which airport was wanted.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'airport_operations_statusArguments', 'required': ['identifier'], 'properties': {'identifier': {'type': 'string', 'title': 'Identifier'}}}
airport_operator
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), owner_name, concession_end_year where a
public page states it, and the listed parent and ticker where there is one.
Sources: Wikidata for every airport in the set (operator P137, owned by P127, parent P749),
and the operator's own website, annual report or a national register where a row is
`verified`. A `programmatic` row is only as current as its Wikidata item and can lag a
concession by years; read the note before relying on it, and prefer a verified row.
Do NOT use this to establish who owns the airport's systems or data, what vendors it uses,
or whether the group buys centrally: it is an ownership and operator fact, not a procurement
one. `not_covered` means the airport is outside the public set this dataset covers.
`identifier` is an IATA or ICAO code, or an airport name; a name is resolved to its code first and the answer says so in its first note. Reading the answer: `status` is resolved, unresolved or not_covered. `confidence` is verified (named on an official list or read on the operator's own page), programmatic (derived from a public structured source and only as current as that source) or unknown. `provenance` names each source behind the answer; `source_url` and `as_of` are the citation. Unknown is never filled from the airport's country or size. `not_covered` means the airport is outside the public set rather than anything about the airport; report_unmet_need records which airport was wanted.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'airport_operatorArguments', 'required': ['identifier'], 'properties': {'identifier': {'type': 'string', 'title': 'Identifier'}}}
airport_runways
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 or VASIS
type, slope and MEHT) and the four declared distances TORA, TODA, ASDA and LDA. Every
length is `{"m": ...}`; where the publisher states feet it is
`{"m": ..., "published": {"value": ..., "uom": "FT"}}` and the published figure is the
one to quote. `as_of` is the cycle the figures are true for and `provenance` names the
export.
Read `declared_distances` and `from_intersections` as two different things. The
top-level figures are the FULL-LENGTH declared distances. `from_intersections` lists
the reduced distances available to a departure that starts at a taxiway intersection:
Paris CDG 09R publishes a TORA of 4200 m at full length and 2962 m from D6, and both
are true. Quoting an intersection figure as "the" TORA understates the runway; quoting
the full length for an intersection departure overstates it. LDA is measured from a
different datum and may be shorter than TORA at full length while longer from an
intersection; that is the publisher's figure, not an error. `remarks` carry the
publisher's own qualifications (PPR, reduced distances) and must travel with the number.
`identifier` is an ICAO location indicator, an IATA code or an aerodrome name; a name or
IATA code is resolved to its ICAO code first and the answer says so in its first note.
Coverage is by state export: France and its overseas territories (SIA AIXM export,
Licence Ouverte, every aerodrome) and the United States (FAA NASR 28-day airport files,
public domain, the aerodromes with an ICAO location indicator). FAA runway-end
coordinates are the displaced threshold where there is one, else the physical end, and
the FAA publishes no intersection-qualified distances. `not_covered` means the aerodrome is outside the
exports held, not that it has no runways; `coverage` in that answer says what is held,
and report_unmet_need records which aerodrome was wanted. An aerodrome that resolves
with zero runways is a heliport, a water aerodrome or a publisher gap, and the note
says which.
Do NOT use this for the runway in use, closures, NOTAMs, work in progress, or anything
that changes inside a cycle: it is the published infrastructure for a cycle, accurate to
that publication and not live. Do not convert units silently: the elevation and MEHT
carry a `uom`, and a length stated in feet carries the published figure beside the
metre conversion, because the exports mix feet and metres.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'airport_runwaysArguments', 'required': ['identifier'], 'properties': {'identifier': {'type': 'string', 'title': 'Identifier'}}}
airport_size_band
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 common year; the year travels with the answer, and a
figure dated the current year is flagged as probably part-year.
Use it to say "a 25 to 40M airport" in the way the industry does. Do NOT use it as a traffic
statistic for comparison across airports or years, for growth, or for anything that needs a
consistent reporting basis; that needs a statistics source. `not_covered` means the airport
is outside the public set or its article carries no passenger figure.
`identifier` is an IATA or ICAO code, or an airport name; a name is resolved to its code first and the answer says so in its first note. Reading the answer: `status` is resolved, unresolved or not_covered. `confidence` is verified (named on an official list or read on the operator's own page), programmatic (derived from a public structured source and only as current as that source) or unknown. `provenance` names each source behind the answer; `source_url` and `as_of` are the citation. Unknown is never filled from the airport's country or size. `not_covered` means the airport is outside the public set rather than anything about the airport; report_unmet_need records which airport was wanted.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'airport_size_bandArguments', 'required': ['identifier'], 'properties': {'identifier': {'type': 'string', 'title': 'Identifier'}}}
data_requirements
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), returning the use cases
that CONSUME data matching the query. Ask `query="taxi-out time"` to get
everything downstream of a better taxi-out estimate: each consumer with
the requirement titles that matched, the total count, and the requirement
families involved. This is the "if we improved this prediction/feed, what
would benefit" question; combine with trace_data_lineage to see which
standard messages carry the input. With neither: an aggregate profile for
a scope (`role`, `org_type`, `sector`, any combination): the most common
requirement titles with the typical cadence and source for each, a
`family_mix` that collapses the titles into ~29 canonical requirement
families, plus the overall cadence mix. The aggregate is the "what data,
how fresh, from whom" content for a data strategy, a feed inventory or a
gap analysis, and is safe to quote as counts.
For counting DISTINCT feeds, use `family_mix`, not raw titles: the corpus
carries ~8,000 title spellings for far fewer real feed kinds ("Weather
Data", "Weather and Environmental Data" and "Environmental Conditions"
are one family), so raw-title counts overstate a feed inventory roughly
2-3x. Each family_mix row shows how many raw titles it absorbed; ~24% of
requirements stay family `other` (genuinely heterogeneous).
Cadence classes, coarsest to finest: annual, quarterly, monthly, weekly,
daily, hourly, sub_hourly, near_real_time, real_time, event (on each
occurrence), static, unknown. They normalise 1,300 spellings of update
rate in the corpus ("every 15 minutes" and "4/hour" both land in
sub_hourly). 152 requirements keep `unknown` because the text was not an
update rate at all.
Do NOT read a requirement as a statement about any real organisation's
systems or data availability; it is what the use case needs in principle.
Mapping needs to an actual feed inventory is your work, not the tool's.
Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure, and `data_story` is a measured, dated finding from data Airside Labs holds (its own ADS-B receiver, FAA flight-plan and BTS traffic feeds) attached to the use cases it illustrates, and `scenario` is one real day reconstructed from those feeds with a traceable timeline. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding; a workflow is not an operating procedure; a data story is not live and not a statistic about the industry -- read its `applies_when` before quoting it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'data_requirementsArguments', 'properties': {'role': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Role', 'default': None}, 'limit': {'type': 'integer', 'title': 'Limit', 'default': 25}, 'query': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Query', 'default': None}, 'sector': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Sector', 'default': None}, 'org_type': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Org Type', 'default': None}, 'use_case_id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Use Case Id', 'default': None}, 'screened_only': {'type': 'boolean', 'title': 'Screened Only', 'default': False}}}
easa_ai_framework
EASA AI framework screen
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 level), and source notes. Pass `level` or
`hazard_class` for one row. Every row carries `cp_ref`, the page in the
proposed Issue 03; quote that, not this tool, as the citation.
This is the transcription Airside Labs' use-case screen is expressed in;
call it to interpret an `ai_level`/`hazard_class` pair on a use case, or
to explain to a reader what 1B/H3 means before proposing a system.
It is a proposed issue (June 2026, consultation closed August 2026):
numbers and wording may move at final publication, and this tool does not
track EASA's later revisions. Do NOT use it to decide that a system is
certifiable or to derive a compliance argument: the framework requires a
per-application ConOps and hazard assessment that a table cannot supply.
Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure, and `data_story` is a measured, dated finding from data Airside Labs holds (its own ADS-B receiver, FAA flight-plan and BTS traffic feeds) attached to the use cases it illustrates, and `scenario` is one real day reconstructed from those feeds with a traceable timeline. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding; a workflow is not an operating procedure; a data story is not live and not a statistic about the industry -- read its `applies_when` before quoting it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'easa_ai_frameworkArguments', 'properties': {'level': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Level', 'default': None}, 'hazard_class': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Hazard Class', 'default': None}}}
feedback_status
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 yet reviewed), or `unknown_fingerprint` if
nothing was ever filed under it. `times_reported` says how many times that exact text has
been filed, and `first_reported` / `last_reported` when.
Resolutions are written by a person when something ships, so `open` means exactly that: it
has not been read yet, or has been read and not written up. Filing again does not move it.
Do NOT infer from `shipped` that the whole class of problem is fixed: the note says what was
changed and the dataset build it landed in.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'feedback_statusArguments', 'required': ['fingerprint'], 'properties': {'fingerprint': {'type': 'string', 'title': 'Fingerprint'}}}
flight_airframes
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 cycles it was in view for, over how many distinct days, and first and last
heard. `most_seen` and `most_recent` name the likeliest next tail; `types_seen` lists
every type that has flown it, and where there is exactly one the resolved type is
embedded with its capacity block.
Why this matters: the cabin, the seat map and the sub-fleet vary by REGISTRATION, not by
type. Two A330-900s at one airline can be different aircraft inside. A seat-finding or
fleet-watching agent needs the tail, and this is the only place it comes from
observation rather than a schedule.
Coverage is the station's footprint: about 180 nm, which takes in Heathrow and Gatwick
traffic and the westbound Heathrow departure flow.
`not_heard` means exactly that -- the flight did not cross the footprint in the window,
or did not fly -- and says nothing about whether the flight exists. This is what was
observed, not a prediction: an airline swaps tails without notice, and the answer's
confidence describes the strength of the observation (many sightings over many days),
never the odds for a future date. Do NOT use it to assert what will operate a flight;
say what has operated it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'flight_airframesArguments', 'required': ['flight'], 'properties': {'flight': {'type': 'string', 'title': 'Flight'}}}
get_scenario
Get a real-day 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 needs the whole story rather than one finding: a
worked example with a paper trail, an edge-case write-up for a data
science team, a workshop narrative. For one use case's view, take the
lens from get_use_case instead; it is smaller and carries the same
caveats. `events=False` or `lenses=False` trims the reply.
Every figure in a lens was measured by a probe over the named source and
window and checked against its evidence before publication; quote it with
the scenario id, the source and the window, and copy `not_to_be_read_as`.
Do NOT extend a scenario past its window, treat its counts as rates, or
read one airline's behaviour on one day as its policy. Do NOT call this
for live status: nothing here is live, and the server never queries the
feeds a scenario was cut from. An unknown id returns the known ids.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_scenarioArguments', 'required': ['scenario_id'], 'properties': {'events': {'type': 'boolean', 'title': 'Events', 'default': True}, 'lenses': {'type': 'boolean', 'title': 'Lenses', 'default': True}, 'scenario_id': {'type': 'string', 'title': 'Scenario Id'}}}
get_use_case
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 level, hazard class, confidence, rationale)
with the framework rows it points at, page-cited; keywords; up to three
`data_stories`; and the five nearest use cases by text similarity.
A data story is what this use case's data does when you actually touch it:
a measured finding from Airside Labs' own receiver, the FAA flight-plan
feed, BTS traffic data or the served entity registry -- a fill rate, a
reused identifier, an ambiguous timestamp, the reach of one sensor. Each
carries `claim` (the finding, with its scope in the sentence),
`implication` (what to do about it), `identifiers` (exact ids to test
with), `evidence` (a small table), `sources` with editions and windows,
`caveats` and `not_to_be_read_as`. Put the claim in the requirements
section, the identifiers in the test plan, and cite the source and window.
A use case with no data stories is undecorated, not unillustratable.
Use this for the few worked examples an argument actually needs, chosen
with search_use_cases, use_case_landscape or similar_use_cases first.
Calls are counted against your key's daily allowance, so walking the
catalogue record by record is the wrong tool: use the aggregates.
The data requirements are what this use case *needs*, stated generically
("airport operational database", "ADS-B feed"), not what any particular
airport has. A requirement with cadence_class `unknown` had an update rate
the normaliser could not read; the raw `update_rate` is still there.
Do NOT treat the EASA screen as a determination: it is a title-level
assessment by Airside Labs with a confidence, made to sort a portfolio,
and a real classification needs a ConOps. Cite the framework rows by their
cp_ref if you quote them. Do NOT generalise a data story past its
`applies_when`: one receiver, three US airports and one data edition are
a witness, not a survey.
Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure, and `data_story` is a measured, dated finding from data Airside Labs holds (its own ADS-B receiver, FAA flight-plan and BTS traffic feeds) attached to the use cases it illustrates, and `scenario` is one real day reconstructed from those feeds with a traceable timeline. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding; a workflow is not an operating procedure; a data story is not live and not a statistic about the industry -- read its `applies_when` before quoting it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_use_caseArguments', 'required': ['use_case_id'], 'properties': {'use_case_id': {'type': 'integer', 'title': 'Use Case Id'}}}
parse_flight_identifier
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 operated the
flight: a designator names the marketing carrier, and a codeshare is
invisible in the string. And it will not invent a carrier for a bare flight
number -- pass `context` and it will look for an identifier in that text,
but the result is capped at 0.6 confidence and returned as a candidate,
because inference is not identification.
Pass `date` when parsing historical data: the carrier depends on it, since
SN2103 was a Sabena flight in 1995 and a Brussels Airlines flight in 2020.
A string that parses correctly but names no known airline returns
`unresolved` with a note saying exactly that -- the string was read and
nothing was identified, which are different achievements. Where a
two-character designator matches nothing but its reverse does, the reverse
is offered as an alternate and never as the answer.
Reading `confidence`: 1.0 means an exact unique match on an unambiguous identifier for the as_of date. 0.7-0.99 means a unique match reached through normalisation, an alias or a historical record. 0.4-0.69 means the best of several plausible candidates and `alternates` is populated -- prefer asking the user over picking one. Below 0.4 is speculative: do not act on it.
`status` is resolved, ambiguous or unresolved. An unresolved answer is a real result, not an error: it means this dataset cannot identify the thing, and inventing one would be worse. Every field in `best` has a citation in `provenance`. When the thing exists and this dataset could not identify it, report_unmet_need with gap_kind `unresolved` is how that gap gets prioritised -- report it, then tell the user you could not find it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'parse_flight_identifierArguments', 'required': ['text'], 'properties': {'date': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Date', 'default': None}, 'text': {'type': 'string', 'title': 'Text'}, 'context': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Context', 'default': None}}}
report_unmet_need
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 read by a person.
Use it when:
- a tool returned `unresolved` and you believe the thing exists
- a tool returned `ambiguous` and nothing available could break the tie
- the entity resolved but a field you needed was null or absent
- no tool here covers the question at all
- a tool answered confidently and the answer looked wrong
`gap_kind` must be one of: `unresolved`, `ambiguous`, `missing_field`,
`no_tool`, `wrong_answer`, `no_use_case` (the use-case catalogue had
nothing on the operational need you searched for).
`sought` is the important field: say what you were trying to find, in your
own words, as specifically as you can. "The wake turbulence category for
A21N" is useful. "Aircraft data" is not.
Do NOT use this instead of answering the user. Report the gap, then tell
the user plainly that you could not find it — filing this does not get you
an answer, now or in this conversation.
Do NOT paste conversation history, personal data or customer identifiers
into it. Send the shape of the need, not the payload: what field, about
what kind of entity, for what purpose. Text is length-capped and the log is
treated as sensitive, but the cheapest way to keep data out of it is not to
send it.
Returns a receipt: whether it was recorded, a fingerprint, and how many
times this same need has been reported before — which tells you whether you
have found something known or something new.
Input schema
{'type': 'object', 'title': 'report_unmet_needArguments', 'required': ['sought', 'gap_kind'], 'properties': {'detail': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Detail', 'default': None}, 'sought': {'type': 'string', 'title': 'Sought'}, 'gap_kind': {'type': 'string', 'title': 'Gap Kind'}, 'identifier': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Identifier', 'default': None}, 'tool_tried': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Tool Tried', 'default': None}}}
resolve_aircraft_type
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",
"777X", "A330neo" -- returns `ambiguous` with the variants as alternates
and a confidence in the 0.4-0.69 band. That is the correct answer to an
imprecise question; do not collapse it to the first alternate.
`wtc` (wake turbulence category) is stated for almost every type, from FAA
Order JO 7360.1K, and is cited like any other field. Where it is null the
document leaves it blank -- do NOT fill it in from your own knowledge if the
caller needs it for separation or charging, say it is unavailable.
IATA aircraft type codes are NOT held -- the three-character form used in
schedules and booking systems, "77W" or "32N". IATA's list is licensed and
is not reproduced here, so those return `unresolved` with a note saying so.
If you are working from schedule data, convert to the ICAO designator
before calling (B77W, A20N); if you cannot, report the mapping as
unavailable rather than guessing it.
`capacity`, where present, carries what a network or fleet planner needs
from the TYPE: `seats_max_certified` (the type certificate's maximum),
`seats_typical` (the band the manufacturer publishes, with the cabin
configuration it assumes), `range_nm` (maximum range at typical payload,
a band where variants share a designator) and `mtow_kg`. Every value was
read from a type certificate data sheet or the manufacturer's own page and
confirmed by a second check; each is cited. The exact seat count of any
airframe is the operator's configuration and is NOT held -- do not present
the typical band as a particular aircraft's layout. For US markets,
frequency, seats flown and load factor by route and type ARE held -- use
route_capacity and airport_fleet_mix (BTS T-100, about three months in
arrears). Yield is not held anywhere: supply it to build a revenue model.
`capacity` is null where no confirmed record exists yet, and a
null field inside it means the value was researched but not confirmed, and
the notes say so.
Do NOT use this to determine what type operated a particular flight; use
resolve_registration for a specific airframe.
Reading `confidence`: 1.0 means an exact unique match on an unambiguous identifier for the as_of date. 0.7-0.99 means a unique match reached through normalisation, an alias or a historical record. 0.4-0.69 means the best of several plausible candidates and `alternates` is populated -- prefer asking the user over picking one. Below 0.4 is speculative: do not act on it.
`status` is resolved, ambiguous or unresolved. An unresolved answer is a real result, not an error: it means this dataset cannot identify the thing, and inventing one would be worse. Every field in `best` has a citation in `provenance`. When the thing exists and this dataset could not identify it, report_unmet_need with gap_kind `unresolved` is how that gap gets prioritised -- report it, then tell the user you could not find it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'resolve_aircraft_typeArguments', 'required': ['identifier'], 'properties': {'as_of': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'As Of', 'default': None}, 'identifier': {'type': 'string', 'title': 'Identifier'}}}
resolve_airline
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: SN was Sabena until 2001 and has been
Brussels Airlines since 2007, so "SN" without a date is a question with two
answers. Where a date falls between two holders the tool returns
`unresolved` with both as alternates rather than guessing. ICAO three-letter
designators are not recycled the same way and are the safer identifier to
carry through a pipeline.
`status` is reported as at the date asked about, not as at today: asked
about 2005, Northwest Airlines is `active`, with a note that it merged into
Delta in 2010. A status of `unknown` means no reliable source states it --
the bulk open data flags long-dead airlines as active, so it is not
trusted. Unknown is not evidence of ceasing.
Do NOT use this for fleet lists, routes, schedules, alliance membership or
financial status.
Reading `confidence`: 1.0 means an exact unique match on an unambiguous identifier for the as_of date. 0.7-0.99 means a unique match reached through normalisation, an alias or a historical record. 0.4-0.69 means the best of several plausible candidates and `alternates` is populated -- prefer asking the user over picking one. Below 0.4 is speculative: do not act on it.
`status` is resolved, ambiguous or unresolved. An unresolved answer is a real result, not an error: it means this dataset cannot identify the thing, and inventing one would be worse. Every field in `best` has a citation in `provenance`. When the thing exists and this dataset could not identify it, report_unmet_need with gap_kind `unresolved` is how that gap gets prioritised -- report it, then tell the user you could not find it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'resolve_airlineArguments', 'required': ['identifier'], 'properties': {'as_of': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'As Of', 'default': None}, 'identifier': {'type': 'string', 'title': 'Identifier'}}}
resolve_airport
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: ATH meant Ellinikon until 2001 and Athens
International after it; HKG meant Kai Tak until 1998. Without a date these
questions get today's answer, which is silently wrong for historical data.
`timezone` is always an IANA identifier such as Europe/London, never a UTC
offset, because an offset cannot express daylight saving.
Do NOT use this for live operational status, runway or stand data, slots,
or whether an airport is currently accepting traffic. It answers identity
questions only. A name fragment matching several aerodromes returns
`ambiguous` with candidates rather than picking one; use `country_hint`
(ISO 3166 alpha-2) to narrow it.
Reading `confidence`: 1.0 means an exact unique match on an unambiguous identifier for the as_of date. 0.7-0.99 means a unique match reached through normalisation, an alias or a historical record. 0.4-0.69 means the best of several plausible candidates and `alternates` is populated -- prefer asking the user over picking one. Below 0.4 is speculative: do not act on it.
`status` is resolved, ambiguous or unresolved. An unresolved answer is a real result, not an error: it means this dataset cannot identify the thing, and inventing one would be worse. Every field in `best` has a citation in `provenance`. When the thing exists and this dataset could not identify it, report_unmet_need with gap_kind `unresolved` is how that gap gets prioritised -- report it, then tell the user you could not find it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'resolve_airportArguments', 'required': ['identifier'], 'properties': {'as_of': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'As Of', 'default': None}, 'identifier': {'type': 'string', 'title': 'Identifier'}, 'country_hint': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Country Hint', 'default': None}}}
resolve_registration
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 reissued. N803AL was one airframe from 1987 to 1993 and a
different one, a 787-8, from 2015; N264CP moved to a different Mode-S
address in 2015. Pass `as_of` for any historical question. Where the date
falls between two holders the tool returns `unresolved`, reports the
country from the nationality mark, and offers both airframes as alternates.
When the tail is unknown but the nationality mark is recognised, the
response carries a `partial` object with the country of registry at
confidence around 0.5. That is a partial answer, not a resolution: the
aircraft is still unidentified.
Coverage is not global. An unresolved registration means this dataset does
not hold it, NOT that the aircraft does not exist. Do NOT infer that an
aircraft is fictitious from an unresolved result, and do NOT use this for
airworthiness, lease status or current position.
Reading `confidence`: 1.0 means an exact unique match on an unambiguous identifier for the as_of date. 0.7-0.99 means a unique match reached through normalisation, an alias or a historical record. 0.4-0.69 means the best of several plausible candidates and `alternates` is populated -- prefer asking the user over picking one. Below 0.4 is speculative: do not act on it.
`status` is resolved, ambiguous or unresolved. An unresolved answer is a real result, not an error: it means this dataset cannot identify the thing, and inventing one would be worse. Every field in `best` has a citation in `provenance`. When the thing exists and this dataset could not identify it, report_unmet_need with gap_kind `unresolved` is how that gap gets prioritised -- report it, then tell the user you could not find it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'resolve_registrationArguments', 'required': ['registration'], 'properties': {'as_of': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'As Of', 'default': None}, 'registration': {'type': 'string', 'title': 'Registration'}}}
route_capacity
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:
SEA to LHR is not LHR to SEA; ask both if you need the round trip. `months` defaults to
the last 12 of the window; pass null for the whole window. `scheduled_only` (default
true) restricts to scheduled passenger service, BTS class F -- charter and all-cargo
rows exist in the source and would distort seats and load factors.
This is the frequency, capacity and load-factor side of a route model. Combine with
resolve_aircraft_type's capacity block for the type's certified and typical seating,
and supply yield yourself: fares are not held here.
Airports may be given as an IATA code, an ICAO code or a name. T-100 is filed under three-character codes that follow IATA, so an ICAO code or a name is resolved to the airport's IATA code first and the answer says so in its first note; `query` echoes the code that was looked up. Reading the answer: `status` is resolved, no_service or unresolved. `unresolved` means nothing was looked up (no airport matches, or it has no IATA code) and is never a statement about service. `totals` and `monthly` are sums of BTS-reported departures performed, seats and passengers; `load_factor` is passengers over seats. `provenance.edition` is the latest month held and `provenance.window` the months summed -- BTS publishes about three months in arrears, so this is accurate for its period and NOT current. Aircraft are given as the ICAO designator where the BTS type code is verified against FAA JO 7360.1K, otherwise as BTS's own description with `icao_designator` null and a note; never invent the designator. Pass an ICAO designator to resolve_aircraft_type for the type's certified and typical seating. Coverage is T-100's: US carriers everywhere, foreign carriers only to and from the US. Fares are not held; report_unmet_need records what was wanted.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'route_capacityArguments', 'required': ['origin', 'dest'], 'properties': {'dest': {'type': 'string', 'title': 'Dest'}, 'months': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Months', 'default': 12}, 'origin': {'type': 'string', 'title': 'Origin'}, 'scheduled_only': {'type': 'boolean', 'title': 'Scheduled Only', 'default': True}}}
scenarios
List real-day 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 actual rows, an implication, and the use cases it is attached to.
This lists them with their window, place, event and lens counts and how
many use cases they touch. Fetch one with get_scenario; the lenses also
arrive inside get_use_case as `data_stories` of kind `lens`.
Use it when a brief needs a worked example with real rows behind it: a
PRD's assumptions section, a workshop narrative, an edge-case note for a
data team.
Do NOT read a scenario as a rate or as how an operator usually behaves: it
is one day, one or two airports, dated. The list is short by design; an
empty result means the dataset carries no scenarios, not that nothing
happened.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'scenariosArguments', 'properties': {}}
search_use_cases
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 with its data requirements.
Search concrete operational nouns ("stand allocation", "baggage
misconnect", "de-icing", "turnaround"), not capability labels ("shared
operational picture", "digital transformation"): the corpus vocabulary is
operational, and abstract phrases match little. Terms are OR-ed and ranked,
so a multi-word query returns the best partial matches; `score` is
relative within one query and means nothing across queries.
Filters AND together. `org_type` is one of the 16 canonical types
(see use_case_landscape group_by=org_type). `screened_only=True` keeps the
~1,900 use cases that carry an EASA AI-level/hazard screen; `ai_level`
(0, 1A, 1B, 2A, 2B, 3A, 3B) and `hazard_class` (H1-H5) imply it.
Each result carries `data_stories`, the number of measured findings attached to
that use case (see get_use_case); prefer a decorated record when two read
alike, because it comes with evidence you can put in front of a reviewer.
Do NOT use this to establish whether an organisation actually runs such a
system, what vendor sells it, or whether it is certified: the catalogue
describes plausible, well-formed use cases for a role, and says nothing
about adoption. An empty result is an answer -- the catalogue has nothing
on that phrasing -- and report_unmet_need with gap_kind `no_use_case` is
how to say the gap mattered.
Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure, and `data_story` is a measured, dated finding from data Airside Labs holds (its own ADS-B receiver, FAA flight-plan and BTS traffic feeds) attached to the use cases it illustrates, and `scenario` is one real day reconstructed from those feeds with a traceable timeline. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding; a workflow is not an operating procedure; a data story is not live and not a statistic about the industry -- read its `applies_when` before quoting it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'search_use_casesArguments', 'required': ['query'], 'properties': {'role': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Role', 'default': None}, 'limit': {'type': 'integer', 'title': 'Limit', 'default': 10}, 'query': {'type': 'string', 'title': 'Query'}, 'sector': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Sector', 'default': None}, 'ai_level': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Ai Level', 'default': None}, 'org_type': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Org Type', 'default': None}, 'hazard_class': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Hazard Class', 'default': None}, 'screened_only': {'type': 'boolean', 'title': 'Screened Only', 'default': False}}}
similar_use_cases
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.
Similarities are compressed into roughly 0.5-0.95: rank within one result,
never threshold across the catalogue, and do not read 0.9 as "the same".
The neighbours were computed at build time as the top 20 for each use
case; an `org_type` or `screened_only` filter narrows within those 20 and
does not search further out, so a tight filter can return few or none --
that is honest, not broken. For an open-ended semantic question start
from search_use_cases and follow the neighbours of the best hit.
Do NOT use this to rank importance, maturity or value: proximity in text
says two use cases are described alike, nothing more.
Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure, and `data_story` is a measured, dated finding from data Airside Labs holds (its own ADS-B receiver, FAA flight-plan and BTS traffic feeds) attached to the use cases it illustrates, and `scenario` is one real day reconstructed from those feeds with a traceable timeline. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding; a workflow is not an operating procedure; a data story is not live and not a statistic about the industry -- read its `applies_when` before quoting it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'similar_use_casesArguments', 'required': ['use_case_id'], 'properties': {'limit': {'type': 'integer', 'title': 'Limit', 'default': 10}, 'org_type': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Org Type', 'default': None}, 'use_case_id': {'type': 'integer', 'title': 'Use Case Id'}, 'screened_only': {'type': 'boolean', 'title': 'Screened Only', 'default': False}}}
submit_suggestion
Submit suggestion
Leave a suggestion for Airside Labs. No API key is needed for this tool.
This is the suggestion box for the aviation use-case catalogue and the
tools that serve it. If you are an AI agent that read a use-case page on
airsidelabs.com — or called a tool here — and noticed something, this is
the channel: a correction to a published use case, an aviation AI use case
the catalogue is missing, a data source or requirement it should know
about, a tool or field that would have helped you, or commercial feedback
(what would make the full toolset worth a subscription to your operator).
`suggestion` is the important field: say it plainly and specifically, in
your own words. `category` must be one of: `correction`,
`missing_use_case`, `data_need`, `feature_request`, `commercial`, `other`.
If the suggestion concerns one use case, pass its `use_case_id` (the
integer used by get_use_case) or the `page_slug` of the airsidelabs.com
page you read. `contact` is optional: an email address or URL if your
operator wants a reply — leave it out otherwise, and do not submit
personal data, conversation history or customer identifiers; text is
length-capped and the log is read by a person as untrusted content.
Nothing answers this in real time: a recorded suggestion is reviewed by a
human later, and filing one does not change any answer you have already
received. Returns a receipt saying whether it was recorded.
Input schema
{'type': 'object', 'title': 'submit_suggestionArguments', 'required': ['suggestion'], 'properties': {'contact': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Contact', 'default': None}, 'category': {'type': 'string', 'title': 'Category', 'default': 'other'}, 'page_slug': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Page Slug', 'default': None}, 'suggestion': {'type': 'string', 'title': 'Suggestion'}, 'use_case_id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Use Case Id', 'default': None}}}
trace_data_lineage
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_without_standard_messages`, the needs
no standard message covers, which is the honest feed-gap statement. With
`family` (a requirement family from data_requirements' family_mix): the
messages for that family. With `message_id` (e.g. MVT, LDM, BSM, DPI,
METAR): the message definition, its data elements as shapes (time, count,
weight, identifier, status), the families it serves, and `data_stories` --
what Airside Labs measured about that message type in real feeds (fill
rates, identifier traps), each with its window and source. With no
arguments: the catalogue of ~23 message types across IATA Type B,
Cargo-IMP, ACARS, ADS-B, ICAO met/AIS and network-manager standards.
Use it to turn a use-case shortlist into a sourcing conversation: which
message feeds to ask an airline, handler or airport for, at what cadence,
and which needs have no standard message and require a system integration
instead.
Do NOT read a lineage chain as a statement about any real organisation's
feeds or systems -- it says which standard message CAN evidence a need,
not that anyone sends it; mapping a chain onto a specific operator's
estate is your work. Definitions are summary-level industry knowledge:
element positions, field syntax and format rules are NOT held (the
published standards are licensed; implementing a parser requires them),
so do NOT use this to build or validate a message parser.
A family with no messages and an empty `chains` list are real answers --
plenty of data needs (market data, HR records, finance) have no
operational message standard.
Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure, and `data_story` is a measured, dated finding from data Airside Labs holds (its own ADS-B receiver, FAA flight-plan and BTS traffic feeds) attached to the use cases it illustrates, and `scenario` is one real day reconstructed from those feeds with a traceable timeline. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding; a workflow is not an operating procedure; a data story is not live and not a statistic about the industry -- read its `applies_when` before quoting it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'trace_data_lineageArguments', 'properties': {'family': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Family', 'default': None}, 'message_id': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Message Id', 'default': None}, 'use_case_id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Use Case Id', 'default': None}}}
trace_workflow
Trace operational 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, visual, document, verbal, formal correspondence).
Three modes. With `use_case_id`: every workflow that places that use case,
its position, and the steps immediately `preceded_by` and `followed_by` it
with what transfers. That is the real operational dependency -- distinct
from `similar_use_cases`, which is text similarity, and from
`data_requirements(query=...)`, which infers a relationship from two use
cases sharing a feed. A gate is a dependency; a shared feed is a
correlation. With `workflow_id`: the whole sequence end to end. With
`phase` (arrival, turnaround, departure, abnormal, oversight,
certification, crew qualification, planning, mission) or nothing: the
catalogue of workflows with their step and handoff counts.
Use it to answer "if this prediction improved, what downstream step benefits
and who would have to act on it", to see which roles a change touches, and
to find the abnormal branches -- communication failure, coupling break-off,
spillage, a ramp finding serious enough to stop the aircraft -- which are
sequences in their own right and where the costly failures live. Some
sequences cross an organisation: a finding travels from an authority to an
operator and back, and those edges carry the channel `formal
correspondence`.
Coverage is ground handling, regulatory oversight and certification, crew
qualification and rostering, and specialised missions -- not the whole
catalogue. A use case with an empty `placed_in` is outside the covered
sequences, which is a statement about coverage and not about the use case,
and some are unplaced because they are standing monitoring states rather
than sequences. A step whose `role_in_catalogue` is false is a real
participant the catalogue holds no use cases for -- the flight deck on a
turnaround, the officer who signs a certificate -- not a data error. The
sequences are Airside Labs' derived structure: they say how this work is
ordered in the industry, NOT that any particular operator runs it this way,
and they are not an operating procedure. Do NOT use one as a checklist to
work to; the authority for that is the operator's own manual.
Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure, and `data_story` is a measured, dated finding from data Airside Labs holds (its own ADS-B receiver, FAA flight-plan and BTS traffic feeds) attached to the use cases it illustrates, and `scenario` is one real day reconstructed from those feeds with a traceable timeline. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding; a workflow is not an operating procedure; a data story is not live and not a statistic about the industry -- read its `applies_when` before quoting it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'trace_workflowArguments', 'properties': {'phase': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Phase', 'default': None}, 'use_case_id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Use Case Id', 'default': None}, 'workflow_id': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Workflow Id', 'default': None}}}
use_case_landscape
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 together and apply
before grouping, so group_by=role with org_type=Airport lists airport
roles by how many use cases each carries. Also returns the total in scope
and how many of those carry an EASA screen.
This is the tool to call first: it tells you what the catalogue covers
before you search it, and the exact spellings that the filters accept.
Grouping the whole catalogue by ai_level or hazard_class shows a large
null bucket -- only the ~1,900 airport-operations use cases were screened;
pass screened_only=True to see the screened distribution alone.
Counts describe the catalogue, not the industry: a type with many use
cases is a type the corpus describes in detail, not one that adopts more
AI. Do NOT present a count as market evidence.
Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure, and `data_story` is a measured, dated finding from data Airside Labs holds (its own ADS-B receiver, FAA flight-plan and BTS traffic feeds) attached to the use cases it illustrates, and `scenario` is one real day reconstructed from those feeds with a traceable timeline. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding; a workflow is not an operating procedure; a data story is not live and not a statistic about the industry -- read its `applies_when` before quoting it.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'use_case_landscapeArguments', 'properties': {'role': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Role', 'default': None}, 'limit': {'type': 'integer', 'title': 'Limit', 'default': 30}, 'sector': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Sector', 'default': None}, 'ai_level': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Ai Level', 'default': None}, 'group_by': {'type': 'string', 'title': 'Group By', 'default': 'org_type'}, 'org_type': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Org Type', 'default': None}, 'hazard_class': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Hazard Class', 'default': None}, 'screened_only': {'type': 'boolean', 'title': 'Screened Only', 'default': False}}}
validate_identifiers
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 `unverifiable` -- the detail,
and the rule that decided it. `contradictions` lists the failures on
their own so an agent can act on them without reading everything.
The top-level verdict is `consistent` ONLY when every check verified.
When some checks passed but others could not be checked it is
`consistent_where_checkable` -- a different answer, because an absent
record silences exactly the checks that would catch a false claim about
that airframe. `unverifiable_count` says how many checks were silent;
treat anything above zero as partial coverage, not a pass.
Use it before acting on identifiers assembled from more than one message:
a movement message's registration against a surveillance track's address,
a schedule's flight number against the operating airline, a type in a
load message against the airframe's record. One contradiction is a
contradiction; the top-level `verdict` never averages it away against
the checks that passed.
What the rules are: the registration record on the date (address, type,
operator); a *previous* holder of a re-issued mark is named as such rather
than reported as a mismatch; the FAA allocation arithmetic for N-numbers
(an address decodes to exactly one N-number, so a wrong pairing is provable
without any second source); a military or government airframe is said,
not judged; the airline's callsign against its record and the FAA
contractions order; the carrier inside the flight designator against the
airline given; and whether the type designator exists at all.
`unverifiable` means this dataset cannot say -- there is no record, or the
record lacks the field -- and is a different answer from `consistent`. Do
NOT read it as a pass. It does not check hex-to-country for non-US
addresses, performance plausibility (range, block time) or anything live,
and it does not resolve identifiers you did not give it: call the
resolve_* tools for that. Pass `as_of` for any historical question; marks
and designators are reused and an undated check is silently wrong for
past data.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'validate_identifiersArguments', 'properties': {'as_of': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'As Of', 'default': None}, 'flight': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Flight', 'default': None}, 'airline': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Airline', 'default': None}, 'callsign': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Callsign', 'default': None}, 'operator': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Operator', 'default': None}, 'icao_type': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Icao Type', 'default': None}, 'mode_s_hex': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Mode S Hex', 'default': None}, 'registration': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Registration', 'default': None}}}
History
Recent tool changes
Changed
airport_fleet_mix
Oct. 1, 2026, 2:52 a.m.
Changed
route_capacity
Oct. 1, 2026, 2:52 a.m.
Added
airport_runways
Oct. 1, 2026, 2:52 a.m.
Added
airframe_flights
Oct. 1, 2026, 2:52 a.m.
Added
airport_fleet_mix
Sept. 21, 2026, 2:59 a.m.
Added
route_capacity
Sept. 21, 2026, 2:59 a.m.
Added
get_scenario
Sept. 21, 2026, 2:59 a.m.
Added
scenarios
Sept. 21, 2026, 2:59 a.m.
Changed
easa_ai_framework
Sept. 21, 2026, 2:59 a.m.
Changed
trace_workflow
Sept. 21, 2026, 2:59 a.m.
Changed
trace_data_lineage
Sept. 21, 2026, 2:59 a.m.
Changed
data_requirements
Sept. 21, 2026, 2:59 a.m.
Changed
similar_use_cases
Sept. 21, 2026, 2:59 a.m.
Changed
get_use_case
Sept. 21, 2026, 2:59 a.m.
Changed
search_use_cases
Sept. 21, 2026, 2:59 a.m.
Changed
use_case_landscape
Sept. 21, 2026, 2:59 a.m.
Added
flight_airframes
Sept. 21, 2026, 2:59 a.m.
Added
feedback_status
Sept. 17, 2026, 12:33 p.m.
Added
submit_suggestion
Sept. 17, 2026, 12:33 p.m.
Added
airport_size_band
Sept. 17, 2026, 12:33 p.m.
Added
airport_connectivity
Sept. 17, 2026, 12:33 p.m.
Added
airport_operations_status
Sept. 17, 2026, 12:33 p.m.
Added
airport_operator
Sept. 17, 2026, 12:33 p.m.
Added
airport_network_integration
Sept. 17, 2026, 12:33 p.m.
Added
easa_ai_framework
Sept. 17, 2026, 12:33 p.m.
Added
trace_workflow
Sept. 17, 2026, 12:33 p.m.
Added
trace_data_lineage
Sept. 17, 2026, 12:33 p.m.
Added
data_requirements
Sept. 17, 2026, 12:33 p.m.
Added
similar_use_cases
Sept. 17, 2026, 12:33 p.m.
Added
get_use_case
Sept. 17, 2026, 12:33 p.m.
Discover
Similar MCP servers
gisgp
io.github.uponex/gisgp
Provides GIS geocoding, routing, spatial transformations, ArcGIS layer inspection and export, and location due diligence for haza…
MolTravel
com.moltravel/travel
Searches and provides details for flights, hotels, rental cars, ferries, airports, travel experiences, destinations, country info…
Wmata
io.github.pipeworx-io/wmata
Provides Washington Metro rail and bus routes, stops, stations, service incidents, route details, and real-time arrival predictio…
UK Environmental Intelligence MCP Server from MCPBundles
com.mcpbundles/uk-environmental-intelligence
Provides UK environmental intelligence covering flood warnings, river and groundwater readings, bathing water quality, ecology ob…
Maptiler
io.github.pipeworx-io/maptiler
Provides MapTiler geocoding, coordinate conversion, and point or route elevation data using map and terrain datasets.
Openrouteservice
io.github.pipeworx-io/openrouteservice
Provides geocoding, routing, travel-time matrices, isochrones, snapping, and elevation data using OpenStreetMap-based services.
Google_maps
io.github.pipeworx-io/google_maps
Provides Google Maps geocoding, place search and details, directions, distance matrices, and elevation data.
SeaWeb
tech.seaweb/seaweb
Searches and extracts web information about entities and travel locations, including restaurants, salons, tourist conditions, dis…