Aviation
FreeNot checkedProvides aviation weather data (METAR, TAF, station search) with a unique assess_conditions tool that returns flight category, confidence, and an escalation gat
About
Provides aviation weather data (METAR, TAF, station search) with a unique assess_conditions tool that returns flight category, confidence, and an escalation gate to indicate when human review is needed.
README
An MCP tool server that exposes live aviation weather to an LLM — and, more to the point, knows when it shouldn't be trusted to answer.
Built in TypeScript against aviationweather.gov. No API key, no mock data.
aviation-mcp — eval suite
15 golden cases, frozen fixtures, no network
PASS VFR auto conf 1.00 clear VFR
PASS IFR auto conf 1.00 solid IFR — low ceiling
PASS VFR gated conf 0.75 thunderstorm with technically-VFR numbers
PASS IFR gated conf 0.65 sources disagree
...
── scores ──
category accuracy 100% (15/15)
gate precision 100% (5 correct escalations, 0 spurious)
gate recall 100% (0 missed escalations)
confidence separation gated 0.68 vs ungated 1.00
The idea
Most tool servers are a thin wrapper over an API: the model asks, the tool answers, everyone assumes the answer is good. That's fine until the tool is asked something the underlying data can't actually support — at which point a language model will cheerfully produce a confident answer anyway, because that is what language models do.
So the interesting tool here isn't get_metar. It's assess_conditions, which returns three things instead of one:
{
"flightCategory": "VFR",
"confidence": 0.75,
"requiresHumanReview": true, // ← the point
"reviewReasons": [
"thunderstorm reported — category alone understates the hazard."
],
"reasoning": [
"No broken or overcast layer reported; ceiling is not a limiting factor.",
"Visibility 10 sm.",
"Category is the worse of the two components: VFR."
]
}
Ceiling and visibility both say VFR. There is a thunderstorm overhead. The number is right and the answer is dangerous — so the tool refuses to present it as settled and hands off to a person.
The escalation gates
requiresHumanReview fires on four conditions, each of which is a way for a technically-correct answer to be wrong:
| Gate | Why |
|---|---|
| Boundary conditions | Visibility of exactly 3.0 sm sits on the IFR/MVFR line. The honest answer to "which side?" is "I can't tell you from this data." |
| Missing inputs | Upstream omitted visibility. A naive implementation defaults to VFR and reports it confidently. Absence of data is not evidence of good weather. |
| Significant weather | Thunderstorms, freezing rain, hail. The category is right; the category is also not the whole story. |
| Source disagreement | Our computed category differs from upstream's own. One of us is wrong, and we don't get to assume it's them. |
Confidence degrades per gate and the eval suite asserts that gated cases actually score lower than ungated ones — otherwise the number is decorative.
What the eval harness caught
This is the part worth reading.
The first version used fixed boundary margins (±0.5 sm, ±200 ft). Every unit test passed. The implementation was, by any reasonable reading, correct.
The eval suite failed it at 56% gate precision. It was escalating half-mile fog as "near the 1 sm boundary" — half-mile fog is unambiguously the worst category there is — and a 700 ft overcast as "near 500 ft", when 700 ft is squarely IFR. It was crying wolf on a third of the cases, and a gate that fires on obvious cases is a gate humans learn to ignore.
The bug: fixed margins assume measurement precision is constant across magnitudes. It isn't. The gap between 0.5 and 1.0 sm is enormous; the gap between 700 and 500 ft is not. Switching to a proportional margin (5% of the threshold) took precision to 100% with no loss of recall.
No unit test would have caught that, because nothing was broken. It took a suite that graded the system's judgment rather than its behaviour. That's the argument for building evals before you think you need them.
Production hygiene
The boring parts, which are the parts that decide whether this survives contact with production:
- Structured contracts. Every upstream response crosses a zod boundary. A malformed payload fails loudly here, rather than silently becoming a plausible hallucination three tool calls later. Contract violations are reported as contract violations, not disguised as network blips.
- Retries. Exponential backoff with jitter, on transient failures only (5xx, 429, timeouts). A 400 is not retried — retrying a 400 is just being wrong twice. Jitter matters: without it, a fleet of retrying clients wakes up in lockstep and stampedes an upstream that's already struggling.
- Timeouts. An agent blocked forever on a hung socket is worse than one that fails fast, because nothing upstream can distinguish "thinking" from "dead".
- Idempotent reads, cached. METARs update hourly. A chatty agent asking about CYOW eight times in one turn costs one upstream call, not eight.
- Tracing. One JSON line per tool call to stderr — trace id, tool, duration, cache hit, outcome, and for assessments the category, confidence, and gate decision. Stderr, never stdout: stdout is the MCP transport, and writing to it corrupts the protocol. After the fact you can ask "how often did we gate?" and "did confidence track correctness?" without re-running anything.
- Tool errors, not crashes. A tool that throws into the transport takes down every other tool with it. Failures come back as
isErrorwith a reason the model can act on. - Pure core. Categorization, confidence, and the gates have no network, no clock, and no model in them. That's why they can be evaluated exhaustively — all the nondeterminism lives at the edges.
Tools
| Tool | Purpose |
|---|---|
assess_conditions |
Flight category + confidence + escalation gate. The one that matters. |
get_metar |
Current observations, normalized. |
get_taf |
Terminal aerodrome forecasts. |
search_stations |
Resolve a place name to an ICAO identifier. |
Running it
npm install
npm test # 43 unit tests
npm run eval # 15 golden cases, graded — fails the build on a recall miss
npm run build
npm start # MCP server over stdio
Register with any MCP client:
{
"mcpServers": {
"aviation": {
"command": "node",
"args": ["/absolute/path/to/aviation-mcp/dist/index.js"]
}
}
}
Then ask it "what are conditions at CYOW, and should I trust the answer?"
Notes on the upstream
aviationweather.gov is a free public service with an undocumented contract, which is to say it is like every other integration. Visibility arrives as a number (15), a string with a plus ("10+"), or a fraction ("1 1/2"). Wind direction is "VRB" when it's variable. None of this is in any spec; all of it is discovered by hitting the API and watching things break. It's normalized once, in normalize.ts, where it's tested — not in six places downstream, and not by hoping the model figures it out.
Layout
src/
index.ts MCP transport wiring. Thin on purpose.
tools.ts Tool definitions + handlers. Uniform shape: validate, trace, call, normalize.
assess.ts Categorization, confidence, and the escalation gates. Pure functions.
client.ts HTTP: retries, backoff, timeouts, TTL cache.
normalize.ts Upstream's bad habits → our contract.
schemas.ts zod contracts.
logger.ts Structured traces.
evals/
cases.ts 15 golden cases, frozen fixtures.
run.ts Graded harness: accuracy, gate precision, gate recall.
test/ 43 unit tests.
License
MIT.
Install Aviation in Claude Desktop, Claude Code & Cursor
unyly install aviation-mcpInstalls into Claude Desktop, Claude Code, Cursor & VS Code — handles npx, uvx and build-from-source repos for you.
First time? Get the CLI: curl -fsSL https://unyly.org/install | sh
Or configure manually
Run in your terminal:
claude mcp add aviation-mcp -- npx -y aviation-mcpFAQ
Is Aviation MCP free?
Yes, Aviation MCP is free — one-click install via Unyly at no cost.
Does Aviation need an API key?
No, Aviation runs without API keys or environment variables.
Is Aviation hosted or self-hosted?
A hosted option is available: Unyly runs the server in the cloud, no local setup required.
How do I install Aviation in Claude Desktop, Claude Code or Cursor?
Open Aviation on unyly.org, pick your client tab (Claude Desktop, Claude Code, Cursor) and press Install — the config is generated automatically, no JSON editing.
Related MCPs
GitHub
PRs, issues, code search, CI status
by GitHubFilesystem
Secure file operations with configurable access controls.
Memory
Knowledge graph-based persistent memory system.
Template MCP Server
A CLI tool to create a new Model Context Protocol server project with TypeScript support, dual transport options, and an extensible structure
by mcpdotdirectCompare Aviation with
Not sure what to pick?
Find your stack in 60 seconds
Author?
Embed badge for your README
Browse similar
All development MCPs
