Give Your Ops AI Agent Aviation Lookups It Won't Hallucinate

If you are building an AI assistant for airline or airport operations, you have already hit the wall: the model is fluent about aviation until you ask it something specific and time-bound, and then it makes something up with total confidence. "What aircraft type is registration VP-BRZ?" gets an answer. Whether that answer is correct for the date you care about is a coin toss — and in operations, a confidently wrong identifier is worse than no answer, because your agent hands it downstream as fact.

The Airside Labs aviation-tools MCP server gives your existing agent a set of aviation reference and identity lookups that do the opposite: they resolve identifiers to canonical entities with confidence, temporal validity and per-field provenance — and they decline rather than guess. You add them the way you add any MCP server: point your agent at the endpoint, and the tools appear alongside whatever it already has.

Here is what they actually return, run live.

Airports, airlines, aircraft — resolved, not recalled

resolve_airport("LHR")
→ EGLL · London Heathrow · GB · 51.47,-0.46 · elev 83ft · Europe/London

resolve_registration("VP-BRZ", as_of="2010-06-01")
→ A320 · operator AFL (Aeroflot) · Mode-S 424099 · Bermuda · s/n 3157

Nothing surprising about the airport — but the registration lookup is already doing work a model cannot do reliably: it ties the tail to an aircraft type, an operator, a Mode-S hex and a country as of a date. That temporal qualifier is the whole game.

The lookup that earns its place: temporal truth

Codes get reused, and a model that answers from a blur of training data cannot tell you when a code meant what. The tools can:

resolve_airline("SN", as_of="1995-06-01")  → Sabena
resolve_airline("SN", as_of="2020-06-01")  → Brussels Airlines

Same code, two airlines, because Sabena collapsed and the code was reassigned. Ask a general model "what airline is SN?" and you get today's answer, applied silently to a 1998 record. For an ops assistant reconciling historical data, that is a bug that ships to production and surfaces months later as a data-quality mystery.

The one that stops a wrong answer cold

The sharpest tool is validate_identifiers, which checks a set of identifiers against each other on a date and tells you when they cannot all be true:

validate_identifiers(registration="VP-BRZ", mode_s_hex="424099", as_of="2022-06-01")

→ verdict: contradicted
  "424099 belonged to a previous holder of VP-BRZ (2007-06-21 to 2017-09-01);
   on 2022-06-01 the mark was worn by 43be95"
  rule: re-issued mark

Your agent proposed a registration/Mode-S pairing that was correct in 2010 and wrong in 2022, because the registration was re-issued to a different airframe with a different address. Instead of passing that pairing downstream, the tool flags the contradiction, names the rule, and gives the dates. An assistant that surfaces "these two identifiers don't match on this date, here's why" is more useful — and more trustworthy — than one that always has an answer.

Flight designators get the same treatment:

parse_flight_identifier("BA117")
→ carrier BA resolved, number 117, confidence 0.95, provenance attached

Why this beats letting the model wing it

Three properties run through every tool, and they are the reason to wire them in rather than prompt harder:

• Temporal validity. Every identity question takes an as_of date, and an undated answer to a dated question is treated as the error it is.
• Provenance on every field. No source, no field. The tools never return a value they cannot attribute.
• They decline. Ambiguity returns candidates, not one confident guess; "unresolved" is a valid, honest answer. This is the behaviour you want at the point where your agent would otherwise hallucinate.

For an ops assistant, that turns a class of silent failure — plausible-but-wrong identifiers — into either a correct answer or an explicit "I can't confirm that." Both are shippable. A confident fabrication is not.

What it does not do yet — so you can plan around it

Be clear-eyed about scope. These are reference and identity lookups over curated data. They are not a live operational feed: there is no flight status, delay, ETA, NOTAM, gate/stand or weather here. If your assistant needs real-time operational state, this layer resolves and validates the identifiers in that state — it does not source the state itself. Live operational data is on our roadmap and is work we do elsewhere; this server is the identity and reference substrate underneath it.

Knowing that up front lets you use it for exactly what it is good at — the resolution and validation layer your agent currently fakes — without expecting it to be the whole ops stack.

Add it

The catalogue tools (use_case_landscape, get_use_case) are on the free tier if you want to explore what use cases exist in your space with no key. The entity-resolution suite — the lookups above — is on the £49/month plan, sent as Authorization: Bearer or X-Api-Key, and works with any MCP client. Connection details and the full tool reference: airsidelabs.com/for-ai-agents.

Missing a lookup your agent needs? report_unmet_need and submit_suggestion are how you tell us — the curated rules tables grow from exactly those gaps.

---

Airside Labs builds and evaluates production AI for aviation — prototypes, fine-tuned models, RAG systems and adversarial testing — with 25+ years of aviation data experience behind it. These tools are the reference layer we use on our own builds.

How do I add aviation lookups to my AI agent?

Connect your agent to the Airside Labs aviation-tools MCP server (streamable HTTP at mcp.airsidelabs.com/mcp) and its identity and reference tools appear alongside your agent's existing tools. The entity-resolution suite resolves airports, airlines, aircraft types, registrations and flight designators to canonical entities, and validate_identifiers cross-checks a set of identifiers against each other on a date. It works with any MCP client; keys are sent as Authorization: Bearer or X-Api-Key.

Why do LLMs get aviation identifiers wrong?

Because aviation codes are reused over time and a model answering from training data cannot tell you what a code meant on a specific date. The airline code SN was Sabena until 2001 and Brussels Airlines from 2007; a registration like VP-BRZ can be re-issued to a different airframe with a different Mode-S address. Ask an undated question and you get today's answer applied silently to historical data. The Airside Labs tools take an as_of date on every identity question and return temporally correct answers with provenance.

Does the Airside Labs MCP server provide live flight status or NOTAM data?

Not yet. The public tools are reference and identity lookups over curated data — airports, airlines, aircraft, registrations, flight identifiers and cross-identifier validation — not a live operational feed. There is no real-time flight status, delay, ETA, NOTAM, gate/stand or weather in the current toolset. This layer resolves and validates the identifiers that appear in operational state; sourcing that live state is separate work and on the roadmap.