Ask an LLM where a specific aircraft is right now, whether a runway is open, or what the crosswind component is at a given airport, and it will answer. Confidently, fluently, and often wrong. Not because the model is bad at reasoning — because the question has nothing to do with reasoning. It's a lookup, and the model has nothing to look up. This is the actual design problem behind any aviation stack for AI agents: not making the model smarter, but giving it something real to query.
Why LLMs Are Bad at Aviation Facts Out of the Box
A model's weights are a snapshot frozen at training time. Aviation data isn't static — it's one of the more time-sensitive domains a system can touch. ADS-B positions update every second. METARs refresh hourly, more often in rapidly changing conditions. NOTAMs get filed and cancelled all day, every day, against a moving set of thousands of active restrictions worldwide. None of that exists in pretraining data in any usable form, and even if it did, it would be stale the moment it was captured.
So when you ask a base LLM something aviation-specific without giving it a way to check, it does what language models do with a gap: it produces the statistically plausible answer. A tail number that sounds right. A runway length that's close but not exact. A wind reading that fits the pattern of "plausible METAR" without being the actual METAR. In most domains that's an annoying inaccuracy. In this one, an agent guessing at a runway closure, a TFR boundary, or a wind/gust figure instead of checking is a real operational input feeding a real decision — not a trivia mistake. That's the bar an aviation stack for AI agents has to clear: not "sounds right," but "is right, as of now."
What Grounding Actually Requires
The fix isn't a longer context window or a better-worded system prompt. Stuffing yesterday's METAR into context doesn't make it today's METAR. What actually closes the gap is giving the model tools — function calling, or its standardized form, the Model Context Protocol (MCP) — so that when a question requires a live fact, the model issues a call, gets a structured response, and reasons over real data instead of recalled patterns.
This matters mechanically, not just philosophically. A well-designed tool call returns typed, structured output (an altitude in feet, a METAR parsed into wind direction and speed, a NOTAM with explicit start/end timestamps) that the model can directly cite and compute against, rather than free text it has to half-trust. We cover the concrete mechanics of this in our Claude MCP server tutorial and in a worked dispatcher example that chains several of these calls into one decision.
The Data Categories an Aviation Agent Actually Needs
Tool calling is the mechanism; the data behind it is what determines whether the agent is actually useful. A workable aviation stack for AI agents needs to cover a handful of distinct categories, because each answers a different class of question:
- Live ADS-B positions — for "where is this aircraft right now," "what's its altitude and ground speed," or "has it landed yet." This is inherently real-time data; nothing in a model's training set substitutes for it.
- Decoded weather (METAR/TAF) — for go/no-go reasoning. An agent advising on a flight needs current ceiling, visibility, and wind as structured fields it can compare against minimums, not a wall of raw text it has to parse itself.
- NOTAMs — for restriction awareness. Closed runways, navaid outages, and temporary flight restrictions change by the hour, and an agent that doesn't check them is reasoning with a blind spot.
- Airport and navaid reference data — for grounding identifiers. Runway lengths, frequencies, elevations, and ICAO/IATA codes give the model a stable frame so it isn't guessing at facts that don't change but that it also never learned precisely.
- Historical flight data — for pattern questions like on-time performance, typical routings, or past activity on a tail number, where the answer is about trends rather than the current instant.
Drop any one of these and the agent has a hard ceiling on what it can reliably answer — it'll either refuse, hedge, or quietly fall back to guessing.
Why Fragmenting This Across Five APIs Hurts the Agent, Not Just the Developer
It's possible to wire all of this up yourself: an ADS-B provider here, a weather feed there, a government NOTAM portal, a separate airport database. Each one works in isolation. The problem shows up in the agent layer, not the data layer.
Every additional API is a separate auth scheme, a separate rate limit, a separate schema to normalize, and a separate failure mode to handle mid-conversation. More concretely: an agent answering "is it safe to depart KJFK for KBOS right now" needs to chain a weather call, a NOTAM call, and possibly a live-position call into one coherent answer. If those three calls live behind three different providers with three different reliability profiles, the agent's success rate is the product of all three uptimes, and your tool-definition surface triples for no reasoning benefit. A single source with one schema and one key means the model has fewer moving parts to get wrong when it decides which tool to call and how to combine the results — which, in agent systems, is usually where things actually break.
A Practical Starting Point
SkyLink API consolidates ADS-B tracking, decoded weather, NOTAMs, airport/navaid reference data, charts, and ML-based predictions behind one API key, exposed directly to LLMs through an MCP server so an agent can call all of it without juggling separate integrations. The free tier covers 1,000 requests/month, paid plans start at $18.59/mo, and you can get a key here and have an agent querying live aviation data in minutes.