faa-aircraft-registry-mcp-server
Server Details
Offline, keyless lookup of the US civil aircraft registry — decode N-numbers, search records.
- Status
- Healthy
- Uptime
- 99.9% over 64 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/faa-aircraft-registry-mcp-server
- GitHub Stars
- 3
- Server Listing
- @cyanheads/faa-aircraft-registry-mcp-server
TDQS
Scored across 5 tools
Each tool targets a distinct action/resource pair, and descriptions explicitly carve out the boundary between faa_lookup_registration (full active records) and faa_get_registration_status (inactive/unknown states), which is the one potentially confusable pair. The aircraft-type decode vs. search split is also clearly delineated. Only the N-number pair requires reading the description carefully.
All tools share the faa_ prefix and a verb_noun pattern (get_aircraft_type, get_registration_status, search_aircraft_types, search_registrations). The lone deviation is 'lookup_registration' instead of 'get_registration', but the distinct verb is semantically justified given the get/status split.
Five tools is well-scoped for a read-only reference registry: two search tools, two lookup/get tools, and a status resolver. Each earns its place with no redundant or filler operations.
The surface covers the core lifecycle: discover aircraft types, decode type codes, search registrations, resolve a specific N-number, and check active/inactive status. Minor gaps exist (no bulk/list-all or owner-directory operations), but the read-only domain is well covered and the search tools provide workarounds.
Available Tools
5 toolsfaa_get_aircraft_typefaa-aircraft-registry-mcp-server: get aircraft typeARead-onlyIdempotentInspect
Decode a 6–7-character FAA manufacturer/model/series code to aircraft specifications — manufacturer, model, aircraft category, aircraft type, engine type, number of engines, number of seats, weight class, cruise speed, and type-certificate data sheet/holder. Use faa_search_aircraft_types first to discover a code by manufacturer or model name.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Manufacturer/model/series code (e.g. "2072714") — 6–7 uppercase alphanumeric characters, usually 7. Discover codes via faa_search_aircraft_types. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | No | The 6–7-character manufacturer/model/series code. |
| error | No | Present when the call failed. Absent on success. |
| model | No | Aircraft model name. |
| category | No | Aircraft category (Land, Sea, Amphibian) as code + label. |
| engineType | No | Engine type as code + label. |
| weightClass | No | Weight class as the literal FAA string (e.g. "CLASS 1"). |
| aircraftType | No | Aircraft type as code + label. |
| manufacturer | No | Aircraft manufacturer name. |
| numberOfSeats | No | Number of seats; may be blank on the reference record. |
| cruiseSpeedMph | No | Cruise speed in mph; often blank (permissible field). |
| numberOfEngines | No | Number of engines; may be blank on the reference record. |
| weightClassLabel | No | FAA maximum gross takeoff weight range in pounds; omitted when the raw weight class is unknown. |
| builderCertification | No | Builder certification (Type Certificated, Not Type Certificated, Light Sport) as code + label. |
| typeCertificateDataSheet | No | Type-certificate data sheet identifier. |
| typeCertificateDataHolder | No | Type-certificate data holder. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety and repeatability profile is fully covered by structured data. The description adds the field list of the decoded payload, but nothing about lookup failures, missing codes, or data freshness, so it is incremental rather than rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the capability and returned fields come first, the prerequisite second. Every clause earns its place and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, full schema coverage, an output schema to describe return values, and annotations covering the safety profile, the description supplies everything an agent needs to select and invoke it. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the code format, the example value, and the discovery path via faa_search_aircraft_types. The description's "6–7-character" phrasing merely restates the schema, adding no new parameter meaning; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Decode") plus the exact resource (a 6–7-character FAA manufacturer/model/series code) and enumerates the specifications returned. It also names the sibling faa_search_aircraft_types, so an agent can distinguish it from the other registry tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes the workflow prerequisite: "Use faa_search_aircraft_types first to discover a code by manufacturer or model name," which is exactly the guidance needed for a lookup-by-opaque-code tool. It does not state when-not to use it (e.g. against faa_lookup_registration for N-numbers), so it falls short of full alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faa_get_registration_statusfaa-aircraft-registry-mcp-server: get registration statusARead-onlyIdempotentInspect
Resolve whether a US civil aircraft N-number is active, deregistered, reserved, or unknown, including the available registration and airworthiness status. Use this rather than faa_lookup_registration when a number may be inactive. A number that was never issued returns recordType "unknown" — a valid, informative answer, not an error. Accepts "N12345" or "12345".
| Name | Required | Description | Default |
|---|---|---|---|
| nNumber | Yes | US registration N-number to resolve. Accepts "N12345" or "12345" (leading N optional). Shape: 1–5 characters — a leading digit 1–9, then digits, optionally ending in 1–2 letters (I and O are unused). |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| status | No | Registration/cancellation status as code + label (active and deregistered records). |
| nNumber | No | Normalized N-number without the leading "N". |
| purgeDate | No | Scheduled purge date, YYYY-MM-DD (reserved records). |
| cancelDate | No | Cancellation date, YYYY-MM-DD (deregistered records). |
| recordType | No | Resolved registration state: active, deregistered, reserved, or unknown. |
| reserveDate | No | Date the number was reserved, YYYY-MM-DD (reserved records). |
| modeSCodeHex | No | Mode S code in hex / ICAO 24-bit address (deregistered records). |
| serialNumber | No | Manufacturer serial number (deregistered records). |
| certIssueDate | No | Certificate issue date, YYYY-MM-DD (active records). |
| expirationDate | No | Registration expiration date, YYYY-MM-DD (active records). |
| nNumberDisplay | No | N-number with the leading "N" for display. |
| typeReservation | No | Type of reservation as code + label (reserved records). |
| nNumberForChange | No | The N-number this reservation changes to/from (reserved records). |
| airworthinessDate | No | Airworthiness certificate date, YYYY-MM-DD (active records). |
| airworthinessClass | No | Airworthiness classification as code + label (active records). |
| expirationNoticeDate | No | Date an expiration notice was sent, YYYY-MM-DD (reserved records). |
| manufacturerModelCode | No | 6–7-character manufacturer/model/series code (deregistered records). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description nonetheless adds real semantic context beyond them: the full set of possible resolution states and the important behavioral note that an unissued number is a normal informative result, not a failure. It does not discuss rate limits or auth, but nothing suggests those are relevant here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, all front-loaded: purpose, sibling routing, error-semantics caveat, input format. No filler and nothing an agent would need to skip past to find the key routing instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is unnecessary, and the description supplies the one thing the schema cannot: what "unknown" means semantically and when to prefer this tool. For a single-parameter read tool, nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the accepted "N12345"/"12345" forms and the character shape rules. The description's "Accepts 'N12345' or '12345'" merely restates that, so this is the baseline case where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (resolve) and resource (US civil aircraft N-number) and enumerates the exact outcome states it returns: active, deregistered, reserved, or unknown. It explicitly differentiates itself from the sibling faa_lookup_registration, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the selection condition outright: "Use this rather than faa_lookup_registration when a number may be inactive." It also pre-empts a misuse mode by clarifying that a never-issued number returns recordType "unknown" as a valid answer rather than an error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faa_lookup_registrationfaa-aircraft-registry-mcp-server: lookup registrationARead-onlyIdempotentInspect
Decode one US civil aircraft N-number to its full registration record — aircraft make/model, engine, year manufactured, airworthiness, registration status, Mode S (ICAO 24-bit) code, and registered owner (when owner-PII redaction is off). Accepts "N12345" or "12345" (the leading N is optional). Returns ownerRedacted: true when owner details were withheld. A number that is known but inactive (deregistered or reserved) is not found here — use faa_get_registration_status for its current state.
| Name | Required | Description | Default |
|---|---|---|---|
| nNumber | Yes | US registration N-number to decode. Accepts "N12345" or "12345" (leading N optional). Shape: 1–5 characters — a leading digit 1–9, then digits, optionally ending in 1–2 letters (I and O are unused). |
Output Schema
| Name | Required | Description |
|---|---|---|
| make | No | Aircraft manufacturer name. |
| error | No | Present when the call failed. Absent on success. |
| model | No | Aircraft model name. |
| owner | No | Registrant name/address; present only when redaction is off. |
| region | No | Registrant's FAA region as code + label. |
| status | No | Registration status (e.g. Valid registration) as code + label. |
| nNumber | No | Normalized N-number without the leading "N" (the registry storage form). |
| kitModel | No | Kit model (amateur-built aircraft); often blank. |
| uniqueId | No | FAA unique aircraft identifier. |
| engineMake | No | Engine manufacturer name. |
| engineType | No | Engine type (e.g. Reciprocating, Turbo-fan) as code + label. |
| engineModel | No | Engine model name. |
| aircraftType | No | Aircraft type (e.g. Fixed-wing single-engine) as code + label. |
| modeSCodeHex | No | Mode S code in hex — the ICAO 24-bit address used to key live flight-tracking data. |
| serialNumber | No | Manufacturer serial number. |
| certIssueDate | No | Certificate issue date (YYYY-MM-DD). |
| ownerRedacted | No | True when owner name/address were withheld from this payload by the redaction gate. |
| expirationDate | No | Registration expiration date (YYYY-MM-DD). |
| lastActionDate | No | Date of the last registration action (YYYY-MM-DD). |
| modeSCodeOctal | No | Mode S transponder code in octal. |
| nNumberDisplay | No | N-number in conventional display form, with the leading "N". |
| fractionalOwner | No | True when the aircraft is under fractional ownership. |
| kitManufacturer | No | Kit manufacturer (amateur-built aircraft); often blank. |
| yearManufactured | No | Year the aircraft was manufactured; often blank (permissible field). |
| airworthinessDate | No | Airworthiness certificate date (YYYY-MM-DD). |
| airworthinessClass | No | Airworthiness classification (Standard, Experimental, …) from CERTIFICATION char 1, as code + label. |
| approvedOperationsRaw | No | Raw FAA approved-operations sub-code string; interpretation varies by airworthiness class. |
| manufacturerModelCode | No | 6–7-character manufacturer/model/series code. |
| engineManufacturerModelCode | No | 5-char engine manufacturer/model code. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real context beyond them: owner-PII redaction behavior, the ownerRedacted:true signal, and the not-found semantics for inactive numbers. It does not discuss pagination or rate limits, but for a single-record lookup that is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose, then input format, then the sibling routing rule. The only waste is restating the optional-N input format that the schema already carries, which slightly duplicates structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return fields need no explanation, and the description covers the remaining gaps an agent needs: input acceptance, redaction signaling, and the inactive-number boundary with its alternative tool. Nothing required for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented in the schema, including the accepted forms and character-shape rule. The description repeats the 'N12345' or '12345' acceptance already present in the schema, adding no syntax or format meaning beyond it, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Decode one US civil aircraft N-number to its full registration record') and enumerates the decoded fields. It also distinguishes itself from faa_get_registration_status by explicitly routing inactive/deregistered numbers there, so an agent can tell the lookup apart from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit exclusion plus the alternative: 'A number that is known but inactive (deregistered or reserved) is not found here — use faa_get_registration_status for its current state.' It also states the input-shape condition (N-prefix optional) that governs correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faa_search_aircraft_typesfaa-aircraft-registry-mcp-server: search aircraft typesARead-onlyIdempotentInspect
Search FAA aircraft types by manufacturer/model name, aircraft type code, or category code to discover 6–7-character manufacturer/model/series codes and browse specifications. Pass a code to faa_get_aircraft_type for specs or faa_search_registrations as manufacturerModelCode for exact registration matches, then faa_lookup_registration for details. At least one filter is required. Every response reports totalCount (all matches, not just this page); when more remain, it returns nextOffset — pass it back as offset to page forward.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–200, default 25). | |
| query | No | Manufacturer and/or model name to match (full-text). | |
| offset | No | Zero-based index of the first result to return — pass the nextOffset from a previous response, with identical filters, to page forward (default 0). | |
| category | No | Aircraft category code: 1 (Land), 2 (Sea), 3 (Amphibian), exact match. Trimmed; blank is unset. | |
| aircraftType | No | FAA aircraft type code: 1–9, H (Hybrid Lift), O (Other), exact match. Trimmed and uppercased; blank is unset. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied (present only when truncated is set). |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of results on this page (present only when truncated is set). |
| notice | No | Guidance when no aircraft types matched, or when more matches remain. |
| truncated | No | Present and true only when matches remain beyond this page. |
| nextOffset | No | Offset to request the next page; absent when this page reached the end of the matches. |
| totalCount | No | Total aircraft types matching the filters, across all pages. Always present. |
| aircraftTypes | No | Matching aircraft-reference summaries for this page (up to limit). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world behavior, so safety is covered. The description adds genuinely useful traits beyond that: the mandatory-filter constraint and the full pagination contract (totalCount reported for all matches, nextOffset returned and re-passed as offset). It stops short of error/edge-case behavior, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then the sibling routing, then the filter and pagination rules. Every sentence earns its place, though it is dense and packs the whole workflow into a single paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value documentation is not strictly needed, yet the description still surfaces the paging fields that drive correct repeated calls. Combined with annotations covering safety, an agent has everything needed to invoke and page correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by mapping the filter dimensions to the discovery workflow and by explaining the offset/nextOffset round-trip for paging, which goes beyond the per-parameter schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Search FAA aircraft types") and names the three filter dimensions (manufacturer/model name, aircraft type code, category code). It also states the discovery goal (6–7-character manufacturer/model/series codes), which differentiates it from the lookup siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: pass a code to faa_get_aircraft_type for specs, use the code as manufacturerModelCode in faa_search_registrations for exact registration matches, then faa_lookup_registration for details. It also states the hard requirement that at least one filter is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faa_search_registrationsfaa-aircraft-registry-mcp-server: search registrationsARead-onlyIdempotentInspect
Search active US civil aircraft registrations by owner name, make/model, exact manufacturerModelCode, state, aircraft type, or Mode S (hex) code. Discover codes with faa_search_aircraft_types, search registrations by manufacturerModelCode, then drill into N-numbers via faa_lookup_registration. Filters are AND-combined; at least one is required. Owner-name search is unavailable when this deployment redacts owner PII — use the other filters instead. Every response reports totalCount (all matches, not just this page); when more remain, it returns nextOffset — pass it back as offset to page forward.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–200, default 25). | |
| state | No | Two ASCII letters for a state, territory or military postal code (e.g. WA, GU, AE, AP; exact match). Trimmed and uppercased; blank is unset. | |
| offset | No | Zero-based index of the first result to return — pass the nextOffset from a previous response, with identical filters, to page forward (default 0). | |
| makeModel | No | Aircraft make and/or model to match (full-text). | |
| modeSCode | No | Six hexadecimal characters for the Mode S code (ICAO 24-bit address), exact match. Trimmed and uppercased; blank is unset. | |
| ownerName | No | Registrant name to match (full-text). Rejected when owner-PII redaction is on. | |
| aircraftType | No | FAA aircraft type code: 1–9, H (Hybrid Lift), O (Other), exact match. Trimmed and uppercased; blank is unset. | |
| manufacturerModelCode | No | Exact FAA manufacturer/model/series code: 6–7 alphanumeric characters, trimmed and uppercased; blank is unset. Discover codes with faa_search_aircraft_types. AND-combined with other filters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied (present only when truncated is set). |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of results on this page (present only when truncated is set). |
| notice | No | Guidance when no registrations matched, or when more matches remain. |
| truncated | No | Present and true only when matches remain beyond this page. |
| nextOffset | No | Offset to request the next page; absent when this page reached the end of the matches. |
| totalCount | No | Total registrations matching the filters, across all pages. Always present. |
| registrations | No | Matching registration summaries for this page (up to limit). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), but the description adds genuinely new behavioral facts: the one-filter minimum, AND-combination of filters, the PII-redaction mode that rejects ownerName, and the totalCount/nextOffset paging contract. It stops short of describing rate limits or error behavior, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense but front-loaded paragraph: the verb and resource lead, then the sibling workflow, then the filter constraints and paging contract. Every sentence carries operational information, though the workflow chain and constraint clauses could be tightened into a list for faster scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter search tool with a full schema and an output schema, the description covers what the schema cannot: required-filter rule, conditional PII restriction, sibling routing, and how to consume nextOffset. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so format rules (uppercasing, trimming, hex length, 6–7 char model codes) are already documented per parameter. The description only restates that some matches are exact and adds the AND-combination rule, which the schema also hints at — baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (active US civil aircraft registrations) plus the enumerable filter axes. It explicitly differentiates from siblings by naming faa_search_aircraft_types (code discovery) and faa_lookup_registration (N-number drill-down), so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit workflow chain: discover codes with faa_search_aircraft_types, then search here by manufacturerModelCode, then drill into N-numbers with faa_lookup_registration. It also states the precondition that filters are AND-combined and at least one is required, and names the condition under which ownerName must not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
- Changed
faa_get_aircraft_type2 fields changed- changed
Output schema / properties / code / descriptionPrevious value: -"The 7-char manufacturer/model/series code."New value: +"The 6–7-character manufacturer/model/series code." - added
Output schema / properties / weightClassLabelAdded value: +{ + "description": "FAA maximum gross takeoff weight range in pounds; omitted when the raw weight class is unknown.", + "type": "string" +}
- Changed
faa_get_registration_status1 field changed- changed
Output schema / properties / manufacturerModelCode / descriptionPrevious value: -"7-char manufacturer/model/series code (deregistered records)."New value: +"6–7-character manufacturer/model/series code (deregistered records)."
- Changed
faa_lookup_registration1 field changed- changed
Output schema / properties / manufacturerModelCode / descriptionPrevious value: -"7-char manufacturer/model/series code."New value: +"6–7-character manufacturer/model/series code."
- Changed
faa_search_aircraft_types5 fields changed- changed
Input schema / properties / aircraftType / descriptionPrevious value: -"Aircraft type code to match exactly (e.g. \"6\" for rotorcraft)."New value: +"FAA aircraft type code: 1–9, H (Hybrid Lift), O (Other), exact match. Trimmed and uppercased; blank is unset." - changed
Input schema / properties / category / descriptionPrevious value: -"Aircraft category code to match exactly (1 Land, 2 Sea, 3 Amphibian)."New value: +"Aircraft category code: 1 (Land), 2 (Sea), 3 (Amphibian), exact match. Trimmed; blank is unset." - changed
Output schema / properties / aircraftTypes / items / properties / code / descriptionPrevious value: -"7-char manufacturer/model/series code — pass to faa_get_aircraft_type for full specs."New value: +"6–7-character manufacturer/model/series code — pass to faa_get_aircraft_type for full specs or faa_search_registrations as manufacturerModelCode for exact registration matches." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_filters`: No search filter was supplied. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_aircraft_type`: aircraftType is not 1–9, H or O. `invalid_category`: category is not 1, 2 or 3. `no_filters`: No search filter was supplied. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "no_filters" -]New value: +[ + "invalid_aircraft_type", + "invalid_category", + "no_filters" +]
- Changed
faa_search_registrations7 fields changed- changed
Input schema / properties / aircraftType / descriptionPrevious value: -"Aircraft type code to match exactly (e.g. \"4\" for fixed-wing single-engine)."New value: +"FAA aircraft type code: 1–9, H (Hybrid Lift), O (Other), exact match. Trimmed and uppercased; blank is unset." - added
Input schema / properties / manufacturerModelCodeAdded value: +{ + "description": "Exact FAA manufacturer/model/series code: 6–7 alphanumeric characters, trimmed and uppercased; blank is unset. Discover codes with faa_search_aircraft_types. AND-combined with other filters.", + "type": "string" +} - changed
Input schema / properties / modeSCode / descriptionPrevious value: -"Mode S code in hex to match exactly (ICAO 24-bit address)."New value: +"Six hexadecimal characters for the Mode S code (ICAO 24-bit address), exact match. Trimmed and uppercased; blank is unset." - changed
Input schema / properties / state / descriptionPrevious value: -"Two-letter state/territory abbreviation (exact match)."New value: +"Two ASCII letters for a state, territory or military postal code (e.g. WA, GU, AE, AP; exact match). Trimmed and uppercased; blank is unset." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `owner_search_disabled`: ownerName was supplied while owner-PII redaction is enabled on this deployment. `no_filters`: No search filter was supplied. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_code`: manufacturerModelCode is not 6–7 alphanumeric characters after normalization. `invalid_state`: state is not two ASCII letters. `invalid_mode_s_code`: modeSCode is not six hexadecimal characters. `invalid_aircraft_type`: aircraftType is not 1–9, H or O. `owner_search_disabled`: ownerName was supplied while owner-PII redaction is enabled on this deployment. `no_filters`: No search filter was supplied. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "owner_search_disabled", - "no_filters" -]New value: +[ + "invalid_code", + "invalid_state", + "invalid_mode_s_code", + "invalid_aircraft_type", + "owner_search_disabled", + "no_filters" +] - added
Output schema / properties / registrations / items / properties / manufacturerModelCodeAdded value: +{ + "description": "FAA manufacturer/model/series code (6–7 characters); use with faa_get_aircraft_type for specs or manufacturerModelCode to find registrations of the same type.", + "type": "string" +}
5 tool updates
- Changed
faa_get_aircraft_type6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "code" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: The code is well-formed but does not identify a known aircraft type. `invalid_code`: The input is not a structurally valid code (expected 6–7 uppercase alphanumeric characters). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "invalid_code" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "code" -]
- Changed
faa_get_registration_status7 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "recordType", + "nNumber", + "nNumberDisplay" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_n_number`: The input is not a structurally valid N-number (after the optional leading \"N\": 1–5 characters, a leading digit 1–9, then digits, optionally 1–2 trailing letters; I and O are unused). Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_n_number" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - changed
Output schema / properties / recordType / descriptionPrevious value: -"Which file the number resolved in: active (MASTER), deregistered (DEREG), reserved (RESERVED), or unknown (none)."New value: +"Resolved registration state: active, deregistered, reserved, or unknown." - removed
Output schema / requiredRemoved value: -[ - "recordType", - "nNumber", - "nNumberDisplay" -]
- Changed
faa_lookup_registration12 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "nNumber", + "nNumberDisplay", + "fractionalOwner", + "ownerRedacted" + ] + }, + { + "required": [ + "error" + ] + } +] - changed
Output schema / properties / engineMake / descriptionPrevious value: -"Engine manufacturer name, resolved from the reference table."New value: +"Engine manufacturer name." - changed
Output schema / properties / engineManufacturerModelCode / descriptionPrevious value: -"5-char engine manufacturer/model code (join key into the engine reference table)."New value: +"5-char engine manufacturer/model code." - changed
Output schema / properties / engineModel / descriptionPrevious value: -"Engine model name, resolved from the reference table."New value: +"Engine model name." - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: The N-number is well-formed but has no active registration. `invalid_n_number`: The input is not a structurally valid N-number (after the optional leading \"N\": 1–5 characters, a leading digit 1–9, then digits, optionally 1–2 trailing letters; I and O are unused). Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "invalid_n_number" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - changed
Output schema / properties / make / descriptionPrevious value: -"Aircraft manufacturer name, resolved from the reference table."New value: +"Aircraft manufacturer name." - changed
Output schema / properties / manufacturerModelCode / descriptionPrevious value: -"7-char manufacturer/model/series code (join key into the aircraft reference table)."New value: +"7-char manufacturer/model/series code." - changed
Output schema / properties / model / descriptionPrevious value: -"Aircraft model name, resolved from the reference table."New value: +"Aircraft model name." - removed
Output schema / requiredRemoved value: -[ - "nNumber", - "nNumberDisplay", - "fractionalOwner", - "ownerRedacted" -]
- Changed
faa_search_aircraft_types6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "aircraftTypes", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_filters`: No search filter was supplied. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_filters" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "aircraftTypes", - "totalCount" -]
- Changed
faa_search_registrations6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "registrations", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `owner_search_disabled`: ownerName was supplied while owner-PII redaction is enabled on this deployment. `no_filters`: No search filter was supplied. Other values are possible when a failure originates below the handler.", + "examples": [ + "owner_search_disabled", + "no_filters" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "registrations", - "totalCount" -]
3 tool updates
- Changed
faa_get_aircraft_type1 field changed- changed
Input schema / properties / code / descriptionPrevious value: -"7-character manufacturer/model/series code (e.g. \"2072714\"). Discover codes via faa_search_aircraft_types."New value: +"Manufacturer/model/series code (e.g. \"2072714\") — 6–7 uppercase alphanumeric characters, usually 7. Discover codes via faa_search_aircraft_types."
- Changed
faa_get_registration_status1 field changed- changed
Input schema / properties / nNumber / descriptionPrevious value: -"US registration N-number to resolve. Accepts \"N12345\" or \"12345\"; the leading N is optional."New value: +"US registration N-number to resolve. Accepts \"N12345\" or \"12345\" (leading N optional). Shape: 1–5 characters — a leading digit 1–9, then digits, optionally ending in 1–2 letters (I and O are unused)."
- Changed
faa_lookup_registration1 field changed- changed
Input schema / properties / nNumber / descriptionPrevious value: -"US registration N-number to decode. Accepts \"N12345\" or \"12345\"; the leading N is optional."New value: +"US registration N-number to decode. Accepts \"N12345\" or \"12345\" (leading N optional). Shape: 1–5 characters — a leading digit 1–9, then digits, optionally ending in 1–2 letters (I and O are unused)."
2 tool updates
- Changed
faa_search_aircraft_types9 fields changed- added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Zero-based index of the first result to return — pass the nextOffset from a previous response, with identical filters, to page forward (default 0).", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - changed
Output schema / properties / aircraftTypes / descriptionPrevious value: -"Matching aircraft-reference summaries (up to limit)."New value: +"Matching aircraft-reference summaries for this page (up to limit)." - changed
Output schema / properties / cap / descriptionPrevious value: -"The limit that was applied (present only when capped)."New value: +"The limit that was applied (present only when truncated is set)." - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "Offset to request the next page; absent when this page reached the end of the matches.", + "type": "number" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when no aircraft types matched the supplied filters."New value: +"Guidance when no aircraft types matched, or when more matches remain." - changed
Output schema / properties / shown / descriptionPrevious value: -"Number of results returned (present only when capped)."New value: +"Number of results on this page (present only when truncated is set)." - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total aircraft types matching the filters, across all pages. Always present.", + "type": "number" +} - changed
Output schema / properties / truncated / descriptionPrevious value: -"Present and true only when the result set was capped at the limit — more matches exist."New value: +"Present and true only when matches remain beyond this page." - changed
Output schema / requiredPrevious value: -[ - "aircraftTypes" -]New value: +[ + "aircraftTypes", + "totalCount" +]
- Changed
faa_search_registrations9 fields changed- added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Zero-based index of the first result to return — pass the nextOffset from a previous response, with identical filters, to page forward (default 0).", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - changed
Output schema / properties / cap / descriptionPrevious value: -"The limit that was applied (present only when capped)."New value: +"The limit that was applied (present only when truncated is set)." - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "Offset to request the next page; absent when this page reached the end of the matches.", + "type": "number" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when no registrations matched the supplied filters."New value: +"Guidance when no registrations matched, or when more matches remain." - changed
Output schema / properties / registrations / descriptionPrevious value: -"Matching registration summaries (up to limit)."New value: +"Matching registration summaries for this page (up to limit)." - changed
Output schema / properties / shown / descriptionPrevious value: -"Number of results returned (present only when capped)."New value: +"Number of results on this page (present only when truncated is set)." - added
Output schema / properties / totalCountAdded value: +{ + "description": "Total registrations matching the filters, across all pages. Always present.", + "type": "number" +} - changed
Output schema / properties / truncated / descriptionPrevious value: -"Present and true only when the result set was capped at the limit — more matches exist."New value: +"Present and true only when matches remain beyond this page." - changed
Output schema / requiredPrevious value: -[ - "registrations" -]New value: +[ + "registrations", + "totalCount" +]
5 tool updates
- First observed
faa_get_aircraft_type - First observed
faa_get_registration_status - First observed
faa_lookup_registration - First observed
faa_search_aircraft_types - First observed
faa_search_registrations
Related MCP Connectors
Offline global aviation reference: airports, runways, navaids, frequencies from OurAirports.
FAA civil aircraft registry — resolve a US tail number (N-number) to its
Scrape the FAA Aircraft Registry by N-number — aircraft make, model, year, owner name, address, airw
Aircraft registry search, flight history, and analytics powered by ADS-B Exchange data.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables users to query live local ADS-B flight data from their own receiver, listing aircraft overhead or near a point and finding aircraft by callsign, ICAO hex code, or registration.3Mozilla Public 2.0
- AlicenseNot gradedqualityCmaintenanceProvides live ADS-B aircraft positions and enables searching by registration, ICAO hex, or callsign, viewing nearby traffic sorted by distance, finding the closest aircraft, filtering by type or military status, and looking up airport information.MIT
- AlicenseNot gradedqualityDmaintenanceProvides real-time aircraft tracking data from OpenSky Network combined with FAA aircraft registry information, enabling rich aviation queries that merge live flight positions with technical specifications.1MIT
- AlicenseBqualityCmaintenanceEnables clients to look up DARC local-club DOK codes and special event DOKs — district, club, purpose, callsign and sponsoring club — and to check whether a code was valid on a given QSO date, or to search by club, town, district or purpose. Runs fully offline with no network or authentication, and every answer cites its published source.6179 PyPIGPL 3.0
Glama MCP Gateway
Add one secure layer between your agents and this server.