Endpoints: 28,729MCP servers: 18,413Payout addresses: 2,071Paid calls: 1,534Letters: 13Defects: 1,322counted just now
teppi

Server definition

Hash
sha256:c4d561b390725d3e0451f50c65fca8b8831b3e5e74093443a311b022b6a844d9
What it is
What a remote MCP server returned when asked what it offers: 29 tools

The blob, as servednamed by its sha256

{ "instructions": "Aviation tools from Airside Labs. Identity: five tools resolve identifiers -- airports, airlines, aircraft types, registrations, flight designators -- to canonical entities with confidence, alternates, temporal validity and per-field provenance, and validate_identifiers checks a set of them against each other on a date. Context: ten use-case atlas tools answer what AI use cases exist for an organisation type or role, what data each needs and how fresh, which standard messages would carry it, where it sits in an operational sequence, how it screens against the EASA AI-level and hazard framework, and what else is like it -- start with use_case_landscape, search with operational nouns, fetch the few full records an argument needs. A full record may carry data stories: measured, dated findings from Airside Labs' own receiver and approved public feeds showing what that data does when touched; scenarios and get_scenario give whole real days with a traceable timeline and the lenses cut from them. Quote a story or a scenario with its source and window, never as live data or an industry statistic. use_case_landscape, get_use_case and submit_suggestion need no API key (a per-address daily cap applies). report_unmet_need is how to tell us what you could not get; submit_suggestion is the open suggestion box — corrections, missing use cases, data sources, feature or commercial feedback. Internally three more tools adjudicate airport charges against encoded contract clauses. Pass as_of for any historical identity question: codes are reused and an undated answer is silently wrong for past data. An unresolved, empty or unadjudicable result is a real answer, not an error.", "tools": [ { "description": "Which flights has this airframe been heard or filed operating, how often and when --\nthe inverse of flight_airframes, from Airside Labs' own ADS-B receiver and the FAA\nflight-plan feed?\n\nAccepts a registration in any common form (G-XWBA, N101DU, PH-BHA) or a Mode-S address\n(406a3d). A registration is resolved first, so `as_of` matters for a re-issued mark: the\nanswer names the airframe it resolved to and the Mode-S address(es) it looked up. Returns\neach Flight ID the airframe was heard broadcasting within the receiver's footprint, or was\nfiled under in FAA flight plans, with sightings (receiver poll cycles in view), distinct\ndays seen, first and last seen, and which instrument observed it. `most_seen` and\n`most_recent` name the services it is usually on; `flight_count` how many distinct Flight\nIDs it carried in the window.\n\nWhy this matters: movement history for a tail. A fleet-watching, lessor or MRO agent that\nhas resolved a registration wants to know what it has been doing; this answer comes from\nwhat the receiver heard and what was filed, within the footprint below, not from a\nschedule.\n\nCoverage is the station's footprint (about 180 nm, taking in Heathrow and Gatwick traffic\nand the westbound Heathrow departure flow) plus departures filed from JFK, Newark and\nSeattle. `not_heard` means the airframe was not observed in the window and says nothing\nabout whether it flew. A Flight ID identifies the service, not the route or the position:\nthis is not a track log and never a current location. Do NOT use it to assert where an\naircraft is or will be; say what it has been heard operating.", "inputSchema": { "properties": { "as_of": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "As Of" }, "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "airframe_flightsArguments", "type": "object" }, "name": "airframe_flights", "outputSchema": null }, { "description": "How many nonstop destinations does this airport publish, and in which countries?\n\nReturns the count of nonstop destinations from the airport's published destination table,\nthe number resolved to a country, the destinations by country, and the counts to the United\nStates, the Gulf and the UAE, with the date of the read.\n\nThis is presence, not frequency: one weekly seasonal service and a daily trunk route count\nthe same. It is right for \"does this airport connect to the US at all\" and wrong for\n\"how much traffic does it exchange with the US\"; frequency needs a schedule source, which\nthis dataset is not. Seasonal and suspended routes are counted when the table lists them.\n`not_covered` means the airport is outside the public set or no destination table was\nparsed.\n\n`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.", "inputSchema": { "properties": { "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "airport_connectivityArguments", "type": "object" }, "name": "airport_connectivity", "outputSchema": null }, { "description": "What aircraft types fly from (or into) an airport, how often, with how many seats, and\nat what load factor, over the last N months of BTS T-100 data?\n\nReturns each type's departures performed and share of the airport's departures, seats,\npassengers, load factor, seats per departure, and how many carriers and destinations it\nserves, plus airport totals. `direction` is `departures` (default) or `arrivals`.\n`months` defaults to the last 12 of the window; pass null for the whole window.\nScheduled passenger service only.\n\nThis is the fleet-mix question a planner asks before sizing a route or a gate: what the\nairport is actually flown with, from the census of segments carriers file, not from a\nschedule or a fleet list.\n\n\nAirports 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.", "inputSchema": { "properties": { "airport": { "title": "Airport", "type": "string" }, "direction": { "default": "departures", "title": "Direction", "type": "string" }, "months": { "anyOf": [ { "type": "integer" }, { "type": "null" } ], "default": 12, "title": "Months" } }, "required": [ "airport" ], "title": "airport_fleet_mixArguments", "type": "object" }, "name": "airport_fleet_mix", "outputSchema": null }, { "description": "What level of network integration does this airport have with the EUROCONTROL Network\nManager, or with the FAA's TFDM programme, as of a date?\n\nAnswers with one value: `ani` (Advanced Network Integrated: A-CDM with the higher level of\nintegration), `acdm` (all DPI message types sent to the network, so a TOBT and TSAT stream\nexists), `adv_twr` (Advanced ATC TWR: E-DPI, C-DPI and A-DPI only, no TOBT or TSAT stream),\n`tfdm_a` or `tfdm_b` (FAA Terminal Flight Data Manager configurations), `standard` (removed\nfrom the Network Manager list by a notice), or `not_listed`. Each value carries its\ndefinition, the notice that establishes it, the date it has held since, and the history of\nchanges across the notice chain.\n\nThe source is the Network Manager's own Information Notice \"Updated list of A-CDM, Advanced\nATC TWR and ANI airports\", parsed from each PDF in the chain from IN/25-001 (10 January 2025)\nto the current one. Pass `as_of` for a historical question: Berlin Brandenburg and Barcelona\nwere `acdm` until 24 July 2025 and `ani` from 25 July; Edinburgh was removed on 4 December\n2025 and back as `adv_twr` from 11 March 2026. Without a date you get today's list.\n\nDo NOT read `not_listed` as \"no A-CDM\": the list records integration with the network, and\nan airport can run a local A-CDM programme that never sends a DPI. Do NOT use this for the\nairport's live status, slots or runway data, and do not infer it from airport size or a\nvendor's press release; that inference is the confusion this tool exists to remove. The US\npart rests on the DOT OIG report of 17 July 2024, the only public site list; the FAA names\nno sites.\n\n`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.", "inputSchema": { "properties": { "as_of": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "As Of" }, "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "airport_network_integrationArguments", "type": "object" }, "name": "airport_network_integration", "outputSchema": null }, { "description": "Is there a positive, sourced reason this airport is not open for ordinary commercial\nengagement: closed to civil traffic, in a sanctioned jurisdiction, or a general-aviation\nfield with no scheduled service?\n\nReturns `closed` (no civil passenger operations), `restricted` (the airport operates but\nsits under UK sanctions guidance for its jurisdiction, with the guidance page cited),\n`general-aviation` (no scheduled passenger service), or `no_exception_recorded`. The last\nis exactly that: this dataset records exceptions with their sources; it does not confirm\nthat scheduled service exists, and a `no_exception_recorded` answer should not be quoted\nas \"open\".\n\nRead `method` before quoting a `closed`. `sanctions-register` and the other airport-level\nmethods are hand-read against a named source and carry the date the airport closed: Kyiv\nBoryspil since 24 February 2022, Istanbul Atatürk since April 2019. `curated-airports-type`\nmeans the airport's own record types it as closed and usually carries no date, so it\nestablishes that the aerodrome is closed and not when. `general-aviation` is only ever\nairport-level: the absence of scheduled service is never inferred from an airport's type\nor size.\n\nThe `restricted` value can come from a country-level rule (Russia, Iran) rather than an\nairport-level fact; `method` is `jurisdiction-rule` when it does, the rule is applied to\nthe country the airport resolves to, and it is the UK's guidance, not a statement about\nany other jurisdiction's law. An airport in one of those jurisdictions that nobody has\nread individually still answers `restricted` on the country rule alone, and its notes say\nso. Do NOT use this for daily operational status, NOTAMs or temporary closures.\n\n`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.", "inputSchema": { "properties": { "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "airport_operations_statusArguments", "type": "object" }, "name": "airport_operations_status", "outputSchema": null }, { "description": "Who operates this airport, which group would take the commercial meeting, and who owns\nit?\n\nReturns operator_name, operator_group (the parent that a sales or partnership conversation\nlands with, spelled consistently: Aena, MAG, Groupe ADP, Fraport, VINCI Airports, Adani and\nso on), ownership_class (public-national, public-regional, private-group,\nprivate-individual, concession-mixed or unknown), owner_name, concession_end_year where a\npublic page states it, and the listed parent and ticker where there is one.\n\nSources: Wikidata for every airport in the set (operator P137, owned by P127, parent P749),\nand the operator's own website, annual report or a national register where a row is\n`verified`. A `programmatic` row is only as current as its Wikidata item and can lag a\nconcession by years; read the note before relying on it, and prefer a verified row.\n\nDo NOT use this to establish who owns the airport's systems or data, what vendors it uses,\nor whether the group buys centrally: it is an ownership and operator fact, not a procurement\none. `not_covered` means the airport is outside the public set this dataset covers.\n\n`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.", "inputSchema": { "properties": { "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "airport_operatorArguments", "type": "object" }, "name": "airport_operator", "outputSchema": null }, { "description": "What runways does this aerodrome publish in its state AIP, with what dimensions,\nsurface, bearings, thresholds and declared distances, and for which AIRAC cycle?\n\nReturns every runway the state's export lists for the aerodrome: designator, length\nand width, surface and PCN, the runway strip, and per direction the threshold\ncoordinates, true and magnetic bearing, the approach slope indicator (PAPI or VASIS\ntype, slope and MEHT) and the four declared distances TORA, TODA, ASDA and LDA. Every\nlength is `{\"m\": ...}`; where the publisher states feet it is\n`{\"m\": ..., \"published\": {\"value\": ..., \"uom\": \"FT\"}}` and the published figure is the\none to quote. `as_of` is the cycle the figures are true for and `provenance` names the\nexport.\n\nRead `declared_distances` and `from_intersections` as two different things. The\ntop-level figures are the FULL-LENGTH declared distances. `from_intersections` lists\nthe reduced distances available to a departure that starts at a taxiway intersection:\nParis CDG 09R publishes a TORA of 4200 m at full length and 2962 m from D6, and both\nare true. Quoting an intersection figure as \"the\" TORA understates the runway; quoting\nthe full length for an intersection departure overstates it. LDA is measured from a\ndifferent datum and may be shorter than TORA at full length while longer from an\nintersection; that is the publisher's figure, not an error. `remarks` carry the\npublisher's own qualifications (PPR, reduced distances) and must travel with the number.\n\n`identifier` is an ICAO location indicator, an IATA code or an aerodrome name; a name or\nIATA code is resolved to its ICAO code first and the answer says so in its first note.\nCoverage is by state export: France and its overseas territories (SIA AIXM export,\nLicence Ouverte, every aerodrome) and the United States (FAA NASR 28-day airport files,\npublic domain, the aerodromes with an ICAO location indicator). FAA runway-end\ncoordinates are the displaced threshold where there is one, else the physical end, and\nthe FAA publishes no intersection-qualified distances. `not_covered` means the aerodrome is outside the\nexports held, not that it has no runways; `coverage` in that answer says what is held,\nand report_unmet_need records which aerodrome was wanted. An aerodrome that resolves\nwith zero runways is a heliport, a water aerodrome or a publisher gap, and the note\nsays which.\n\nDo NOT use this for the runway in use, closures, NOTAMs, work in progress, or anything\nthat changes inside a cycle: it is the published infrastructure for a cycle, accurate to\nthat publication and not live. Do not convert units silently: the elevation and MEHT\ncarry a `uom`, and a length stated in feet carries the published figure beside the\nmetre conversion, because the exports mix feet and metres.", "inputSchema": { "properties": { "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "airport_runwaysArguments", "type": "object" }, "name": "airport_runways", "outputSchema": null }, { "description": "Which ACI passenger size band is this airport in, on its latest published annual total?\n\nReturns the passengers figure, its year, and the band on ACI World's published ASQ size\ncategories: under 2M, 2 to 5M, 5 to 15M, 15 to 25M, 25 to 40M, over 40M passengers per year.\nThe figure comes from the airport's Wikipedia infobox (its latest published annual total),\nnot from ACI, so airports are not on a common year; the year travels with the answer, and a\nfigure dated the current year is flagged as probably part-year.\n\nUse it to say \"a 25 to 40M airport\" in the way the industry does. Do NOT use it as a traffic\nstatistic for comparison across airports or years, for growth, or for anything that needs a\nconsistent reporting basis; that needs a statistics source. `not_covered` means the airport\nis outside the public set or its article carries no passenger figure.\n\n`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.", "inputSchema": { "properties": { "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "airport_size_bandArguments", "type": "object" }, "name": "airport_size_band", "outputSchema": null }, { "description": "What data does this use case, role or organisation type need, and how fresh?\n\nThree modes. With `use_case_id`: that use case's requirements verbatim --\ntitle, normalised title_family, description, nominal update rate,\nnormalised cadence class and the kind of source system. With `query`:\nREVERSE lineage -- full-text search over requirement titles and\ndescriptions (the inputs, not the use-case text), returning the use cases\nthat CONSUME data matching the query. Ask `query=\"taxi-out time\"` to get\neverything downstream of a better taxi-out estimate: each consumer with\nthe requirement titles that matched, the total count, and the requirement\nfamilies involved. This is the \"if we improved this prediction/feed, what\nwould benefit\" question; combine with trace_data_lineage to see which\nstandard messages carry the input. With neither: an aggregate profile for\na scope (`role`, `org_type`, `sector`, any combination): the most common\nrequirement titles with the typical cadence and source for each, a\n`family_mix` that collapses the titles into ~29 canonical requirement\nfamilies, plus the overall cadence mix. The aggregate is the \"what data,\nhow fresh, from whom\" content for a data strategy, a feed inventory or a\ngap analysis, and is safe to quote as counts.\n\nFor counting DISTINCT feeds, use `family_mix`, not raw titles: the corpus\ncarries ~8,000 title spellings for far fewer real feed kinds (\"Weather\nData\", \"Weather and Environmental Data\" and \"Environmental Conditions\"\nare one family), so raw-title counts overstate a feed inventory roughly\n2-3x. Each family_mix row shows how many raw titles it absorbed; ~24% of\nrequirements stay family `other` (genuinely heterogeneous).\n\nCadence classes, coarsest to finest: annual, quarterly, monthly, weekly,\ndaily, hourly, sub_hourly, near_real_time, real_time, event (on each\noccurrence), static, unknown. They normalise 1,300 spellings of update\nrate in the corpus (\"every 15 minutes\" and \"4/hour\" both land in\nsub_hourly). 152 requirements keep `unknown` because the text was not an\nupdate rate at all.\n\nDo NOT read a requirement as a statement about any real organisation's\nsystems or data availability; it is what the use case needs in principle.\nMapping needs to an actual feed inventory is your work, not the tool's.\n\nEvery 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.", "inputSchema": { "properties": { "limit": { "default": 25, "title": "Limit", "type": "integer" }, "org_type": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Org Type" }, "query": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Query" }, "role": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Role" }, "screened_only": { "default": false, "title": "Screened Only", "type": "boolean" }, "sector": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Sector" }, "use_case_id": { "anyOf": [ { "type": "integer" }, { "type": "null" } ], "default": null, "title": "Use Case Id" } }, "title": "data_requirementsArguments", "type": "object" }, "name": "data_requirements", "outputSchema": null }, { "description": "The EASA AI-level and hazard-class tables, page-cited, to read a screen against.\n\nReturns the AI levels (0, 1A, 1B, 2A, 2B, 3A, 3B: what the system does and\nhow much authority the end user keeps), the hazard classes (H1-H5: worst\ncredible effect and the assurance level it implies at acceptable and\nmoderate risk), the technique ceilings (which AI techniques the Concept\nPaper accepts up to which level), and source notes. Pass `level` or\n`hazard_class` for one row. Every row carries `cp_ref`, the page in the\nproposed Issue 03; quote that, not this tool, as the citation.\n\nThis is the transcription Airside Labs' use-case screen is expressed in;\ncall it to interpret an `ai_level`/`hazard_class` pair on a use case, or\nto explain to a reader what 1B/H3 means before proposing a system.\n\nIt is a proposed issue (June 2026, consultation closed August 2026):\nnumbers and wording may move at final publication, and this tool does not\ntrack EASA's later revisions. Do NOT use it to decide that a system is\ncertifiable or to derive a compliance argument: the framework requires a\nper-application ConOps and hazard assessment that a table cannot supply.\n\nEvery 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.", "inputSchema": { "properties": { "hazard_class": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Hazard Class" }, "level": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Level" } }, "title": "easa_ai_frameworkArguments", "type": "object" }, "name": "easa_ai_framework", "outputSchema": null }, { "description": "What happened to a suggestion or unmet-need report filed here? No API key is needed.\n\nPass the `fingerprint` from a submit_suggestion or report_unmet_need receipt (12 hex\ncharacters). Returns `status`: `shipped` (a person acted on it and the change is live, with\nwhat shipped and when), `declined` (read and not taken up, with the reason), `acknowledged`\n(read, still open) or `open` (recorded, not yet reviewed), or `unknown_fingerprint` if\nnothing was ever filed under it. `times_reported` says how many times that exact text has\nbeen filed, and `first_reported` / `last_reported` when.\n\nResolutions are written by a person when something ships, so `open` means exactly that: it\nhas not been read yet, or has been read and not written up. Filing again does not move it.\nDo NOT infer from `shipped` that the whole class of problem is fixed: the note says what was\nchanged and the dataset build it landed in.", "inputSchema": { "properties": { "fingerprint": { "title": "Fingerprint", "type": "string" } }, "required": [ "fingerprint" ], "title": "feedback_statusArguments", "type": "object" }, "name": "feedback_status", "outputSchema": null }, { "description": "Which airframes have been heard operating this airline flight, how often and when --\nfrom Airside Labs' own ADS-B receiver?\n\nAccepts a flight in any common form: BA49, BAW49, \"BA 49\", VS105. Returns each airframe\nheard broadcasting that Flight ID within the receiver's footprint, with its Mode-S\naddress, registration and ICAO type (joined from the registrations dataset), how many\nreceiver poll cycles it was in view for, over how many distinct days, and first and last\nheard. `most_seen` and `most_recent` name the likeliest next tail; `types_seen` lists\nevery type that has flown it, and where there is exactly one the resolved type is\nembedded with its capacity block.\n\nWhy this matters: the cabin, the seat map and the sub-fleet vary by REGISTRATION, not by\ntype. Two A330-900s at one airline can be different aircraft inside. A seat-finding or\nfleet-watching agent needs the tail; this answer comes from what the receiver observed, not\nfrom a schedule.\n\nCoverage is the station's footprint: about 180 nm, which takes in Heathrow and Gatwick\ntraffic and the westbound Heathrow departure flow.\n`not_heard` means exactly that -- the flight did not cross the footprint in the window,\nor did not fly -- and says nothing about whether the flight exists. This is what was\nobserved, not a prediction: an airline swaps tails without notice, and the answer's\nconfidence describes the strength of the observation (many sightings over many days),\nnever the odds for a future date. Do NOT use it to assert what will operate a flight;\nsay what has operated it.", "inputSchema": { "properties": { "flight": { "title": "Flight", "type": "string" } }, "required": [ "flight" ], "title": "flight_airframesArguments", "type": "object" }, "name": "flight_airframes", "outputSchema": null }, { "description": "One real episode end to end: what happened, where and when (UTC), the actors,\nwhat it shows and what it must not be read as; the timeline, every event with its\nactor, source and the reference of the raw record it came from; and the lenses,\neach a use case's cut of the day with a small evidence table, an implication, and\nthe use cases it illustrates with a reason for each.\n\nUse it when a brief needs the whole story rather than one finding: a\nworked example with a paper trail, an edge-case write-up for a data\nscience team, a workshop narrative. For one use case's view, take the\nlens from get_use_case instead; it is smaller and carries the same\ncaveats. `events=False` or `lenses=False` trims the reply.\n\nEvery figure in a lens was measured by a probe over the named source and\nwindow and checked against its evidence before publication; quote it with\nthe scenario id, the source and the window, and copy `not_to_be_read_as`.\n\nDo NOT extend a scenario past its window, treat its counts as rates, or\nread one airline's behaviour on one day as its policy. Do NOT call this\nfor live status: nothing here is live, and the server never queries the\nfeeds a scenario was cut from. An unknown id returns the known ids.", "inputSchema": { "properties": { "events": { "default": true, "title": "Events", "type": "boolean" }, "lenses": { "default": true, "title": "Lenses", "type": "boolean" }, "scenario_id": { "title": "Scenario Id", "type": "string" } }, "required": [ "scenario_id" ], "title": "get_scenarioArguments", "type": "object" }, "name": "get_scenario", "outputSchema": null }, { "description": "The full record for one use case, by id from a search or landscape result.\n\nReturns the use-case text; the role that owns it with its description; the\norganisation type (canonical and as the corpus names it); every data\nrequirement -- title, description, nominal update rate with a normalised\ncadence class (real_time … annual), and the kind of system it typically\ncomes from; the EASA screen (AI level, hazard class, confidence, rationale)\nwith the framework rows it points at, page-cited; keywords; up to three\n`data_stories`; and the five nearest use cases by text similarity.\n\nA data story is what this use case's data does when you actually touch it:\na measured finding from Airside Labs' own receiver, the FAA flight-plan\nfeed, BTS traffic data or the served entity registry -- a fill rate, a\nreused identifier, an ambiguous timestamp, the reach of one sensor. Each\ncarries `claim` (the finding, with its scope in the sentence),\n`implication` (what to do about it), `identifiers` (exact ids to test\nwith), `evidence` (a small table), `sources` with editions and windows,\n`caveats` and `not_to_be_read_as`. Put the claim in the requirements\nsection, the identifiers in the test plan, and cite the source and window.\nA use case with no data stories is undecorated, not unillustratable.\n\nUse this for the few worked examples an argument actually needs, chosen\nwith search_use_cases, use_case_landscape or similar_use_cases first.\nCalls are counted against your key's daily allowance, so walking the\ncatalogue record by record is the wrong tool: use the aggregates.\n\nThe data requirements are what this use case *needs*, stated generically\n(\"airport operational database\", \"ADS-B feed\"), not what any particular\nairport has. A requirement with cadence_class `unknown` had an update rate\nthe normaliser could not read; the raw `update_rate` is still there.\n\nDo NOT treat the EASA screen as a determination: it is a title-level\nassessment by Airside Labs with a confidence, made to sort a portfolio,\nand a real classification needs a ConOps. Cite the framework rows by their\ncp_ref if you quote them. Do NOT generalise a data story past its\n`applies_when`: one receiver, three US airports and one data edition are\na witness, not a survey.\n\nEvery 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.", "inputSchema": { "properties": { "use_case_id": { "title": "Use Case Id", "type": "integer" } }, "required": [ "use_case_id" ], "title": "get_use_caseArguments", "type": "object" }, "name": "get_use_case", "outputSchema": null }, { "description": "Split a flight designator into carrier and number, and identify the carrier.\n\nAccepts the forms that arrive in real message traffic: TK1979, BAW276,\n\"U2 8341\", BA02490, BA2490A. Returns the parsed carrier with its resolved\nairline, the flight number, any operational suffix, which scheme was used\n(IATA or ICAO), and both normalised forms.\n\nTwo things this tool will not do. It will not tell you who operated the\nflight: a designator names the marketing carrier, and a codeshare is\ninvisible in the string. And it will not invent a carrier for a bare flight\nnumber -- pass `context` and it will look for an identifier in that text,\nbut the result is capped at 0.6 confidence and returned as a candidate,\nbecause inference is not identification.\n\nPass `date` when parsing historical data: the carrier depends on it, since\nSN2103 was a Sabena flight in 1995 and a Brussels Airlines flight in 2020.\n\nA string that parses correctly but names no known airline returns\n`unresolved` with a note saying exactly that -- the string was read and\nnothing was identified, which are different achievements. Where a\ntwo-character designator matches nothing but its reverse does, the reverse\nis offered as an alternate and never as the answer.\n\nReading `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.\n\n`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.", "inputSchema": { "properties": { "context": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Context" }, "date": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Date" }, "text": { "title": "Text", "type": "string" } }, "required": [ "text" ], "title": "parse_flight_identifierArguments", "type": "object" }, "name": "parse_flight_identifier", "outputSchema": null }, { "description": "Tell us what you came looking for and could not get from these tools.\n\nCall this when you needed something aviation-related that this toolset did\nnot give you. It is not an error channel and it is not a retry: it is how\nthe next version of these tools learns what is missing. A need reported\nhere is appended to this service's own feedback store, on the same server\nthat answered you, and reviewed later by Airside Labs; nothing is sent to\nany other system.\n\nUse it when:\n - a tool returned `unresolved` and you believe the thing exists\n - a tool returned `ambiguous` and nothing available could break the tie\n - the entity resolved but a field you needed was null or absent\n - no tool here covers the question at all\n - a tool answered confidently and the answer looked wrong\n\n`gap_kind` must be one of: `unresolved`, `ambiguous`, `missing_field`,\n`no_tool`, `wrong_answer`, `no_use_case` (the use-case catalogue had\nnothing on the operational need you searched for).\n\n`sought` is the important field: say what you were trying to find, in your\nown words, as specifically as you can. \"The wake turbulence category for\nA21N\" is useful. \"Aircraft data\" is not.\n\nDo NOT use this instead of answering the user. Report the gap, then tell\nthe user plainly that you could not find it — filing this does not get you\nan answer, now or in this conversation.\n\nDo NOT paste conversation history, personal data or customer identifiers\ninto it. Send the shape of the need, not the payload: what field, about\nwhat kind of entity, for what purpose. Text is length-capped and the log is\ntreated as sensitive, but the cheapest way to keep data out of it is not to\nsend it.\n\nReturns a receipt: whether it was recorded, a fingerprint, and how many\ntimes this same need has been reported before — which tells you whether you\nhave found something known or something new.", "inputSchema": { "properties": { "detail": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Detail" }, "gap_kind": { "title": "Gap Kind", "type": "string" }, "identifier": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Identifier" }, "sought": { "title": "Sought", "type": "string" }, "tool_tried": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Tool Tried" } }, "required": [ "sought", "gap_kind" ], "title": "report_unmet_needArguments", "type": "object" }, "name": "report_unmet_need", "outputSchema": null }, { "description": "Which aircraft type does this designator or marketing name refer to?\n\nAccepts an ICAO type designator (A21N) or a marketing name people actually\nsay (\"A321neo\", \"Dash 8-400\", \"777-300ER\", \"Q400\"). Returns the ICAO\ndesignator, manufacturer, model, engine count and type, aircraft class, and\nthe ICAO wake turbulence category.\n\nA name that identifies a family rather than a variant -- \"Dreamliner\",\n\"777X\", \"A330neo\" -- returns `ambiguous` with the variants as alternates\nand a confidence in the 0.4-0.69 band. That is the correct answer to an\nimprecise question; do not collapse it to the first alternate.\n\n`wtc` (wake turbulence category) is stated for almost every type, from FAA\nOrder JO 7360.1K, and is cited like any other field. Where it is null the\ndocument leaves it blank -- do NOT fill it in from your own knowledge if the\ncaller needs it for separation or charging, say it is unavailable.\n\nIATA aircraft type codes are NOT held -- the three-character form used in\nschedules and booking systems, \"77W\" or \"32N\". IATA's list is licensed and\nis not reproduced here, so those return `unresolved` with a note saying so.\nIf you are working from schedule data, convert to the ICAO designator\nbefore calling (B77W, A20N); if you cannot, report the mapping as\nunavailable rather than guessing it.\n\n`capacity`, where present, carries what a network or fleet planner needs\nfrom the TYPE: `seats_max_certified` (the type certificate's maximum),\n`seats_typical` (the band the manufacturer publishes, with the cabin\nconfiguration it assumes), `range_nm` (maximum range at typical payload,\na band where variants share a designator) and `mtow_kg`. Every value was\nread from a type certificate data sheet or the manufacturer's own page and\nconfirmed by a second check; each is cited. The exact seat count of any\nairframe is the operator's configuration and is NOT held -- do not present\nthe typical band as a particular aircraft's layout. For US markets,\nfrequency, seats flown and load factor by route and type ARE held -- use\nroute_capacity and airport_fleet_mix (BTS T-100, about three months in\narrears). Yield is not held anywhere: supply it to build a revenue model.\n`capacity` is null where no confirmed record exists yet, and a\nnull field inside it means the value was researched but not confirmed, and\nthe notes say so.\n\nDo NOT use this to determine what type operated a particular flight; use\nresolve_registration for a specific airframe.\n\nReading `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.\n\n`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.", "inputSchema": { "properties": { "as_of": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "As Of" }, "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "resolve_aircraft_typeArguments", "type": "object" }, "name": "resolve_aircraft_type", "outputSchema": null }, { "description": "Which airline does this designator, name or callsign refer to on a date?\n\nAccepts an IATA two-character designator, an ICAO three-letter designator,\nan airline name or a callsign. Returns the operator with both designators,\ncountry, operational status and, where an airline ceased, its successor.\n\n`as_of` matters more here than for any other tool. IATA two-character\ndesignators are heavily reused: SN was Sabena until 2001 and has been\nBrussels Airlines since 2007, so \"SN\" without a date is a question with two\nanswers. Where a date falls between two holders the tool returns\n`unresolved` with both as alternates rather than guessing. ICAO three-letter\ndesignators are not recycled the same way and are the safer identifier to\ncarry through a pipeline.\n\n`status` is reported as at the date asked about, not as at today: asked\nabout 2005, Northwest Airlines is `active`, with a note that it merged into\nDelta in 2010. A status of `unknown` means no reliable source states it --\nthe bulk open data flags long-dead airlines as active, so it is not\ntrusted. Unknown is not evidence of ceasing.\n\nDo NOT use this for fleet lists, routes, schedules, alliance membership or\nfinancial status.\n\nReading `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.\n\n`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.", "inputSchema": { "properties": { "as_of": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "As Of" }, "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "resolve_airlineArguments", "type": "object" }, "name": "resolve_airline", "outputSchema": null }, { "description": "Which aerodrome does this airport code or name refer to on a given date?\n\nAccepts an IATA three-letter code, an ICAO four-letter code, an airport\nname fragment or a city name. Returns the aerodrome with its codes,\nlocation, elevation, IANA timezone and type (large, medium, small,\nheliport or closed).\n\nPass `as_of` whenever the question concerns a past date. Airport codes move\nbetween aerodromes: ATH meant Ellinikon until 2001 and Athens\nInternational after it; HKG meant Kai Tak until 1998. Without a date these\nquestions get today's answer, which is silently wrong for historical data.\n\n`timezone` is always an IANA identifier such as Europe/London, never a UTC\noffset, because an offset cannot express daylight saving.\n\nDo NOT use this for live operational status, runway or stand data, slots,\nor whether an airport is currently accepting traffic. It answers identity\nquestions only. A name fragment matching several aerodromes returns\n`ambiguous` with candidates rather than picking one; use `country_hint`\n(ISO 3166 alpha-2) to narrow it.\n\nReading `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.\n\n`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.", "inputSchema": { "properties": { "as_of": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "As Of" }, "country_hint": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Country Hint" }, "identifier": { "title": "Identifier", "type": "string" } }, "required": [ "identifier" ], "title": "resolve_airportArguments", "type": "object" }, "name": "resolve_airport", "outputSchema": null }, { "description": "Which airframe wore this registration on a given date?\n\nAccepts a tail number in any common form: VH-OQA, VHOQA, lowercase, padded\nwith whitespace. Returns the aircraft with its country of registry, ICAO\ntype designator, an embedded resolved aircraft type, operator, owner,\nserial number and Mode-S hex address.\n\nA registration is a slot rather than a permanent name: marks are\nsurrendered and reissued. N803AL was one airframe from 1987 to 1993 and a\ndifferent one, a 787-8, from 2015; N264CP moved to a different Mode-S\naddress in 2015. Pass `as_of` for any historical question. Where the date\nfalls between two holders the tool returns `unresolved`, reports the\ncountry from the nationality mark, and offers both airframes as alternates.\n\nWhen the tail is unknown but the nationality mark is recognised, the\nresponse carries a `partial` object with the country of registry at\nconfidence around 0.5. That is a partial answer, not a resolution: the\naircraft is still unidentified.\n\nCoverage is not global. An unresolved registration means this dataset does\nnot hold it, NOT that the aircraft does not exist. Do NOT infer that an\naircraft is fictitious from an unresolved result, and do NOT use this for\nairworthiness, lease status or current position.\n\nReading `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.\n\n`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.", "inputSchema": { "properties": { "as_of": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "As Of" }, "registration": { "title": "Registration", "type": "string" } }, "required": [ "registration" ], "title": "resolve_registrationArguments", "type": "object" }, "name": "resolve_registration", "outputSchema": null }, { "description": "How much scheduled capacity is flown nonstop from one airport to another, by whom and\non what, over the last N months of BTS T-100 data?\n\nReturns monthly departures performed, seats and passengers with the load factor, and the\nsame broken down by carrier and aircraft type with seats per departure and the sector\ndistance (BTS statute miles, and nautical miles converted). The pair is DIRECTIONAL:\nSEA to LHR is not LHR to SEA; ask both if you need the round trip. `months` defaults to\nthe last 12 of the window; pass null for the whole window. `scheduled_only` (default\ntrue) restricts to scheduled passenger service, BTS class F -- charter and all-cargo\nrows exist in the source and would distort seats and load factors.\n\nThis is the frequency, capacity and load-factor side of a route model. Combine with\nresolve_aircraft_type's capacity block for the type's certified and typical seating,\nand supply yield yourself: fares are not held here.\n\n\nAirports 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.", "inputSchema": { "properties": { "dest": { "title": "Dest", "type": "string" }, "months": { "anyOf": [ { "type": "integer" }, { "type": "null" } ], "default": 12, "title": "Months" }, "origin": { "title": "Origin", "type": "string" }, "scheduled_only": { "default": true, "title": "Scheduled Only", "type": "boolean" } }, "required": [ "origin", "dest" ], "title": "route_capacityArguments", "type": "object" }, "name": "route_capacity", "outputSchema": null }, { "description": "Which real operational episodes does the catalogue carry, to illustrate use cases with?\n\nA scenario is one real day reconstructed from data Airside Labs holds and\nmay publish: FAA SWIM flight plans, FAA NOTAMs, its own ADS-B receiver. Each\nis a UTC window at a place, a timeline whose every event names the raw\nrecord it came from, and a set of lenses -- one use case's cut of the day,\nwith the actual rows, an implication, and the use cases it is attached to.\nThis lists them with their window, place, event and lens counts and how\nmany use cases they touch. Fetch one with get_scenario; the lenses also\narrive inside get_use_case as `data_stories` of kind `lens`.\n\nUse it when a brief needs a worked example with real rows behind it: a\nPRD's assumptions section, a workshop narrative, an edge-case note for a\ndata team.\n\nDo NOT read a scenario as a rate or as how an operator usually behaves: it\nis one day, one or two airports, dated. The list is short by design; an\nempty result means the dataset carries no scenarios, not that nothing\nhappened.", "inputSchema": { "properties": {}, "title": "scenariosArguments", "type": "object" }, "name": "scenarios", "outputSchema": null }, { "description": "Which aviation AI use cases match this text? Find candidates by keyword.\n\nFull-text search (BM25, stemmed) over 6,500 use cases spanning airports,\nairlines, ANSPs, ground handlers, regulators, manufacturers and more, each\nattached to a role and an organisation type. Returns summaries only --\nid, short text, role, organisation type, EASA screen -- capped at 25.\nUse get_use_case for the full record with its data requirements.\n\nSearch concrete operational nouns (\"stand allocation\", \"baggage\nmisconnect\", \"de-icing\", \"turnaround\"), not capability labels (\"shared\noperational picture\", \"digital transformation\"): the corpus vocabulary is\noperational, and abstract phrases match little. Terms are OR-ed and ranked,\nso a multi-word query returns the best partial matches; `score` is\nrelative within one query and means nothing across queries.\n\nFilters AND together. `org_type` is one of the 16 canonical types\n(see use_case_landscape group_by=org_type). `screened_only=True` keeps the\n~1,900 use cases that carry an EASA AI-level/hazard screen; `ai_level`\n(0, 1A, 1B, 2A, 2B, 3A, 3B) and `hazard_class` (H1-H5) imply it.\n\nEach result carries `data_stories`, the number of measured findings attached to\nthat use case (see get_use_case); prefer a decorated record when two read\nalike, because it comes with evidence you can put in front of a reviewer.\n\nDo NOT use this to establish whether an organisation actually runs such a\nsystem, what vendor sells it, or whether it is certified: the catalogue\ndescribes plausible, well-formed use cases for a role, and says nothing\nabout adoption. An empty result is an answer -- the catalogue has nothing\non that phrasing -- and report_unmet_need with gap_kind `no_use_case` is\nhow to say the gap mattered.\n\nEvery 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.", "inputSchema": { "properties": { "ai_level": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Ai Level" }, "hazard_class": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Hazard Class" }, "limit": { "default": 10, "title": "Limit", "type": "integer" }, "org_type": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Org Type" }, "query": { "title": "Query", "type": "string" }, "role": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Role" }, "screened_only": { "default": false, "title": "Screened Only", "type": "boolean" }, "sector": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Sector" } }, "required": [ "query" ], "title": "search_use_casesArguments", "type": "object" }, "name": "search_use_cases", "outputSchema": null }, { "description": "What else in the catalogue is like this use case? Nearest neighbours by meaning.\n\nReturns up to 20 use cases closest in embedding space (bge-base cosine\nover the use-case text), as summaries with a `similarity`. Good for \"what\nelse is like the one we picked\", for finding the same idea stated for a\ndifferent role or organisation type, and for spotting near-duplicates\nbefore counting them as two.\n\nSimilarities are compressed into roughly 0.5-0.95: rank within one result,\nnever threshold across the catalogue, and do not read 0.9 as \"the same\".\nThe neighbours were computed at build time as the top 20 for each use\ncase; an `org_type` or `screened_only` filter narrows within those 20 and\ndoes not search further out, so a tight filter can return few or none --\nthat is honest, not broken. For an open-ended semantic question start\nfrom search_use_cases and follow the neighbours of the best hit.\n\nDo NOT use this to rank importance, maturity or value: proximity in text\nsays two use cases are described alike, nothing more.\n\nEvery 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.", "inputSchema": { "properties": { "limit": { "default": 10, "title": "Limit", "type": "integer" }, "org_type": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Org Type" }, "screened_only": { "default": false, "title": "Screened Only", "type": "boolean" }, "use_case_id": { "title": "Use Case Id", "type": "integer" } }, "required": [ "use_case_id" ], "title": "similar_use_casesArguments", "type": "object" }, "name": "similar_use_cases", "outputSchema": null }, { "description": "Record a suggestion about this toolset or its use-case catalogue. No API\nkey is needed for this tool.\n\nThe suggestion is written as one record into this server's own local\nfeedback store and nothing else happens: no message, notification, email\nor request goes to any website, person or other system, now or later, and\nthe tool does not read the store back. Airside Labs reads the store when\npreparing the next version of the catalogue and the tools.\n\nUse it for: a correction to a catalogue use case, an aviation AI use case\nthe catalogue is missing, a data source or requirement it should know\nabout, a tool or field that would have helped you, or commercial feedback\n(what would make the full toolset worth a subscription).\n\n`suggestion` is the important field: say it plainly and specifically, in\nyour own words. `category` must be one of: `correction`,\n`missing_use_case`, `data_need`, `feature_request`, `commercial`, `other`.\nIf the suggestion concerns one use case, pass its `use_case_id` (the\ninteger used by get_use_case) or the `page_slug` of the catalogue page\nit came from. `contact` is an optional free-text field stored with the\nrecord and used for nothing else; leave it out unless the user asked for\nit. Do not submit personal data, conversation history or customer\nidentifiers; text is length-capped and the stored record is treated as\nuntrusted content.\n\nFiling a suggestion does not change any answer you have already received\nand produces no reply. Returns a receipt saying whether the record was\nstored.", "inputSchema": { "properties": { "category": { "default": "other", "title": "Category", "type": "string" }, "contact": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Contact" }, "page_slug": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Page Slug" }, "suggestion": { "title": "Suggestion", "type": "string" }, "use_case_id": { "anyOf": [ { "type": "integer" }, { "type": "null" } ], "default": null, "title": "Use Case Id" } }, "required": [ "suggestion" ], "title": "submit_suggestionArguments", "type": "object" }, "name": "submit_suggestion", "outputSchema": null }, { "description": "Which standard operational messages would evidence this data need?\n\nThe lineage spine is use case -> data requirement -> requirement family ->\nstandard message type -> data elements. Four modes. With `use_case_id`:\nthat use case's requirements grouped by family, each family with the\nstandard messages that evidence it (relevance primary/supporting, cadence,\nelement count) -- plus `requirements_without_standard_messages`, the needs\nno standard message covers, which is the honest feed-gap statement. With\n`family` (a requirement family from data_requirements' family_mix): the\nmessages for that family. With `message_id` (e.g. MVT, LDM, BSM, DPI,\nMETAR): the message definition, its data elements as shapes (time, count,\nweight, identifier, status), the families it serves, and `data_stories` --\nwhat Airside Labs measured about that message type in real feeds (fill\nrates, identifier traps), each with its window and source. With no\narguments: the catalogue of ~23 message types across IATA Type B,\nCargo-IMP, ACARS, ADS-B, ICAO met/AIS and network-manager standards.\n\nUse it to turn a use-case shortlist into a sourcing conversation: which\nmessage feeds to ask an airline, handler or airport for, at what cadence,\nand which needs have no standard message and require a system integration\ninstead.\n\nDo NOT read a lineage chain as a statement about any real organisation's\nfeeds or systems -- it says which standard message CAN evidence a need,\nnot that anyone sends it; mapping a chain onto a specific operator's\nestate is your work. Definitions are summary-level industry knowledge:\nelement positions, field syntax and format rules are NOT held (the\npublished standards are licensed; implementing a parser requires them),\nso do NOT use this to build or validate a message parser.\nA family with no messages and an empty `chains` list are real answers --\nplenty of data needs (market data, HR records, finance) have no\noperational message standard.\n\nEvery 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.", "inputSchema": { "properties": { "family": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Family" }, "message_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Message Id" }, "use_case_id": { "anyOf": [ { "type": "integer" }, { "type": "null" } ], "default": null, "title": "Use Case Id" } }, "title": "trace_data_lineageArguments", "type": "object" }, "name": "trace_data_lineage", "outputSchema": null }, { "description": "What happens before and after this use case, and who hands off to whom?\n\nThe catalogue is otherwise flat -- role, use case, data requirement -- with\nno edges. This is the edges: named operational sequences with their steps in\norder, the role at each step, the `gate` that must hold before the next one\nmay start, and what passes between roles at each handoff (headset, radio,\nhand signal, system, visual, document, verbal, formal correspondence).\n\nThree modes. With `use_case_id`: every workflow that places that use case,\nits position, and the steps immediately `preceded_by` and `followed_by` it\nwith what transfers. That is the real operational dependency -- distinct\nfrom `similar_use_cases`, which is text similarity, and from\n`data_requirements(query=...)`, which infers a relationship from two use\ncases sharing a feed. A gate is a dependency; a shared feed is a\ncorrelation. With `workflow_id`: the whole sequence end to end. With\n`phase` (arrival, turnaround, departure, abnormal, oversight,\ncertification, crew qualification, planning, mission) or nothing: the\ncatalogue of workflows with their step and handoff counts.\n\nUse it to answer \"if this prediction improved, what downstream step benefits\nand who would have to act on it\", to see which roles a change touches, and\nto find the abnormal branches -- communication failure, coupling break-off,\nspillage, a ramp finding serious enough to stop the aircraft -- which are\nsequences in their own right and where the costly failures live. Some\nsequences cross an organisation: a finding travels from an authority to an\noperator and back, and those edges carry the channel `formal\ncorrespondence`.\n\nCoverage is ground handling, regulatory oversight and certification, crew\nqualification and rostering, and specialised missions -- not the whole\ncatalogue. A use case with an empty `placed_in` is outside the covered\nsequences, which is a statement about coverage and not about the use case,\nand some are unplaced because they are standing monitoring states rather\nthan sequences. A step whose `role_in_catalogue` is false is a real\nparticipant the catalogue holds no use cases for -- the flight deck on a\nturnaround, the officer who signs a certificate -- not a data error. The\nsequences are Airside Labs' derived structure: they say how this work is\nordered in the industry, NOT that any particular operator runs it this way,\nand they are not an operating procedure. Do NOT use one as a checklist to\nwork to; the authority for that is the operator's own manual.\n\nEvery 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.", "inputSchema": { "properties": { "phase": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Phase" }, "use_case_id": { "anyOf": [ { "type": "integer" }, { "type": "null" } ], "default": null, "title": "Use Case Id" }, "workflow_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Workflow Id" } }, "title": "trace_workflowArguments", "type": "object" }, "name": "trace_workflow", "outputSchema": null }, { "description": "How many use cases are there, sliced one way? Counts you can quote.\n\n`group_by` is one of org_type (16 canonical organisation types: Airport,\nAirline, Air Navigation Service Provider, Ground Handling, Regulator /\nAuthority, Aerospace Manufacturing, MRO / Maintenance …), sector, role\n(500+ roles), ai_level, hazard_class, or cadence_class (counts data\nrequirements rather than use cases). Filters AND together and apply\nbefore grouping, so group_by=role with org_type=Airport lists airport\nroles by how many use cases each carries. Also returns the total in scope\nand how many of those carry an EASA screen.\n\nThis is the tool to call first: it tells you what the catalogue covers\nbefore you search it, and the exact spellings that the filters accept.\nGrouping the whole catalogue by ai_level or hazard_class shows a large\nnull bucket -- only the ~1,900 airport-operations use cases were screened;\npass screened_only=True to see the screened distribution alone.\n\nCounts describe the catalogue, not the industry: a type with many use\ncases is a type the corpus describes in detail, not one that adopts more\nAI. Do NOT present a count as market evidence.\n\nEvery 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.", "inputSchema": { "properties": { "ai_level": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Ai Level" }, "group_by": { "default": "org_type", "title": "Group By", "type": "string" }, "hazard_class": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Hazard Class" }, "limit": { "default": 30, "title": "Limit", "type": "integer" }, "org_type": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Org Type" }, "role": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Role" }, "screened_only": { "default": false, "title": "Screened Only", "type": "boolean" }, "sector": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Sector" } }, "title": "use_case_landscapeArguments", "type": "object" }, "name": "use_case_landscape", "outputSchema": null }, { "description": "Do these aviation identifiers describe the same thing on this date?\n\nGive any combination of a registration (tail number), a Mode-S 24-bit\naddress, an ICAO type designator, an operator name, an airline designator\n(IATA or ICAO), a callsign and a flight designator, plus `as_of`. Each\npair that can be checked is checked, and every check comes back with a\nverdict -- `consistent`, `contradicted` or `unverifiable` -- the detail,\nand the rule that decided it. `contradictions` lists the failures on\ntheir own so an agent can act on them without reading everything.\n\nThe top-level verdict is `consistent` ONLY when every check verified.\nWhen some checks passed but others could not be checked it is\n`consistent_where_checkable` -- a different answer, because an absent\nrecord silences exactly the checks that would catch a false claim about\nthat airframe. `unverifiable_count` says how many checks were silent;\ntreat anything above zero as partial coverage, not a pass.\n\nUse it before acting on identifiers assembled from more than one message:\na movement message's registration against a surveillance track's address,\na schedule's flight number against the operating airline, a type in a\nload message against the airframe's record. One contradiction is a\ncontradiction; the top-level `verdict` never averages it away against\nthe checks that passed.\n\nWhat the rules are: the registration record on the date (address, type,\noperator); a *previous* holder of a re-issued mark is named as such rather\nthan reported as a mismatch; the FAA allocation arithmetic for N-numbers\n(an address decodes to exactly one N-number, so a wrong pairing is provable\nwithout any second source); a military or government airframe is said,\nnot judged; the airline's callsign against its record and the FAA\ncontractions order; the carrier inside the flight designator against the\nairline given; and whether the type designator exists at all.\n\n`unverifiable` means this dataset cannot say -- there is no record, or the\nrecord lacks the field -- and is a different answer from `consistent`. Do\nNOT read it as a pass. It does not check hex-to-country for non-US\naddresses, performance plausibility (range, block time) or anything live,\nand it does not resolve identifiers you did not give it: call the\nresolve_* tools for that. Pass `as_of` for any historical question; marks\nand designators are reused and an undated check is silently wrong for\npast data.", "inputSchema": { "properties": { "airline": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Airline" }, "as_of": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "As Of" }, "callsign": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Callsign" }, "flight": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Flight" }, "icao_type": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Icao Type" }, "mode_s_hex": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Mode S Hex" }, "operator": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Operator" }, "registration": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "title": "Registration" } }, "title": "validate_identifiersArguments", "type": "object" }, "name": "validate_identifiers", "outputSchema": null } ] }
Verify it yourselfcurl -s https://api.teppi.xyz/v1/evidence/sha256:c4d561b390725d3e0451f50c65fca8b8831b3e5e74093443a311b022b6a844d9 | sha256sum