Faa Aircraft Registry MCP server

@pipeworx/faa-aircraft-registry

Look up a US aircraft tail number (N-number) in the FAA civil aircraft registry — manufacturer, model, serial number, engine, airworthiness class, registrant type, registration status, certificate dates, and deregistration if the N-number has left the active registry.

Part of Pipeworx — an MCP gateway connecting AI agents to 1743+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

Tools

its aircraft/engine reference data, registrant type, and registration status. Registrant NAME is returned only for non-individual registrant types (corporation, LLC, partnership, co-owned, government) — an individual's name is personal data and is withheld, with the response saying so. A deregistered record never returns a registrant name at all (see "Personal data" below).

• faareglookup(n_number) — resolves one N-number ("N12345" or "12345") to

Auth

Keyless.

Data sources

full civil aircraft registry, refreshed daily. Four files are loaded: MASTER.txt (currently-registered aircraft), ACFTREF.txt (airframe make/model reference), ENGINE.txt (engine reference), DEREG.txt (historical deregistrations). DEALER.txt and RESERVED.txt ship in the same ZIP but are out of scope for this pack. US federal data, public domain.

• — the FAA's

Why this is a local-copy pack, not a live proxy

There is no live query API — the FAA only publishes the daily bulk ZIP. This pack reads a Supabase mirror (faaregacftref, faaregengine, faaregaircraft, faaregdereg; schema in supabase/migrations/236faaaircraftregistry.sql) loaded once a day by scripts/ingest-faa-aircraft-registry.mjs (.github/workflows/faa-aircraft-registry-refresh.yml). Every successful lookup response carries dataasof from the row's own loadedat.

The fetch itself is routed through the gateway, not done directly. registry.faa.gov fronts itself with Akamai, and the block is header-shape, not IP-reputation alone (corrected 2026-10-08: refresh run 37731086667 got a live Akamai 403 straight from the gateway's own Worker route, which an earlier, incorrect version of this note said could not happen). Reproduced and fixed with a throwaway Cloudflare Worker on the prod account: a bot-shaped UA with Accept: / gets Akamai's "Access Denied" HTML (HTTP 403) on this exact URL, while a realistic browser header set (a real Chrome UA, a browser-shaped Accept/Accept-Language, and a same-origin Referer) gets a clean HTTP 200 with the genuine ~73 MB ZIP — same Worker, same IP, only the headers differ. A residential IP and the Supabase egress relay were also tried and both 403 regardless of header shape, so the gateway's own /admin/faaregfetch_zip route (workers/gateway/src/index.ts), sending those browser-shaped headers, is the one route that serves; the ingest script calls it and does the actual unzip/parse/load from wherever it runs.

The DB load is TRUNCATE + psql \copy per table, all four in one transaction, using the pooled connection string the ingest script reads from its environment — this is a full daily snapshot, not an incremental upsert, because today's MASTER.txt does not contain yesterday's deregistered N-numbers at all. A parse failure on any of the four files rolls the whole transaction back, so yesterday's data stays live rather than a table going half-replaced.

Empty-registry guard

Shortened. The full README is on GitHub.