faa-aircraft-registry-mcp-server
Server Details
Offline, keyless lookup of the US civil aircraft registry — decode N-numbers, search records.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 5 of 5 tools scored.
Every tool has a clearly distinct purpose: decoding type codes, checking registration status, looking up full registrations, searching type reference, and searching registrations. No overlap.
All tools follow a consistent 'faa_verb_noun' pattern in snake_case, e.g., faa_get_aircraft_type, faa_search_registrations. No deviations.
Five tools are well-scoped for querying the FAA aircraft registry, covering key operations without excess or deficiency.
The set covers all essential query operations: decoding, status checking, full lookup, and searching by various criteria. No obvious gaps for a read-only registry.
Available Tools
5 toolsfaa_get_aircraft_typefaa-aircraft-registry-mcp-server: get aircraft typeARead-onlyIdempotentInspect
Decode a 7-character FAA manufacturer/model/series code to aircraft specifications from the reference table — 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 | 7-character manufacturer/model/series code (e.g. "2072714"). Discover codes via faa_search_aircraft_types. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | The 7-char manufacturer/model/series code. |
| 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. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds specific behavioral context by listing the detailed aircraft specifications returned (manufacturer, model, category, etc.), which is non-obvious from annotations alone.
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 with zero waste: first sentence states purpose and output fields, second provides critical usage guidance. Front-loaded and efficient.
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 a simple tool with one required parameter and an output schema, the description fully covers input semantics, output expectations, and how to obtain input (via sibling search tool). No gaps.
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 parameter 'code' already has a clear description in the schema (including example and hint to discover codes). The tool description does not add additional semantic meaning beyond what the schema already provides, thus 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?
The description uses a specific verb 'Decode' and clearly states the resource: 'FAA manufacturer/model/series code to aircraft specifications from the reference table'. It lists the output fields and distinguishes from siblings by advising to use faa_search_aircraft_types first to discover a code.
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 instructs to use faa_search_aircraft_types first to discover a code by manufacturer or model name, providing clear guidance on when to use this tool and directing to an alternative when the code is unknown.
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 registration and airworthiness status for a US civil aircraft N-number across all three status files — active (MASTER), deregistered (DEREG), and reserved (RESERVED) — in priority order, returning a definitive recordType. Use this (rather than faa_lookup_registration) when a number may be inactive: it returns "deregistered" or "reserved" for a known-but-inactive number instead of a not-found. 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"; the leading N is optional. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | Registration/cancellation status as code + label (active and deregistered records). |
| nNumber | Yes | 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 | Yes | Which file the number resolved in: active (MASTER), deregistered (DEREG), reserved (RESERVED), or unknown (none). |
| 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 | Yes | 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 | 7-char manufacturer/model/series code (deregistered records). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint, idempotentHint. Description adds: it checks three files in priority order, returns definitive recordType, and that 'unknown' is informative. No contradictions.
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 sentences, no fluff, well-structured with main action first then usage guidance and edge cases. Slightly verbose for a simple tool, but efficient.
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?
Given the tool's simplicity and presence of output schema, the description covers input format, behavior across all statuses, and comparison to sibling. No gaps for an agent to select 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 baseline 3. Description mentions optional leading N, which is also in schema, but adds no new semantics beyond what schema already provides.
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 clearly states it resolves registration and airworthiness status across three files, with specific verb 'Resolve' and resource 'US civil aircraft N-number'. It distinguishes itself from sibling faa_lookup_registration by explaining its behavior for inactive numbers.
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 advises when to use this tool over faa_lookup_registration (when number may be inactive) and describes edge cases: returns 'deregistered', 'reserved', or 'unknown' instead of not-found/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). One call resolves the relational join and decodes every coded field. 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 the cross-file status answer.
| Name | Required | Description | Default |
|---|---|---|---|
| nNumber | Yes | US registration N-number to decode. Accepts "N12345" or "12345"; the leading N is optional. |
Output Schema
| Name | Required | Description |
|---|---|---|
| make | No | Aircraft manufacturer name, resolved from the reference table. |
| model | No | Aircraft model name, resolved from the reference table. |
| 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 | Yes | 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, resolved from the reference table. |
| engineType | No | Engine type (e.g. Reciprocating, Turbo-fan) as code + label. |
| engineModel | No | Engine model name, resolved from the reference table. |
| 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 | Yes | 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 | Yes | N-number in conventional display form, with the leading "N". |
| fractionalOwner | Yes | 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 | 7-char manufacturer/model/series code (join key into the aircraft reference table). |
| engineManufacturerModelCode | No | 5-char engine manufacturer/model code (join key into the engine reference table). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. Description adds value by disclosing that owner details may be redacted (returns ownerRedacted: true) and that input can be with or without leading 'N'. This enriches the agent's understanding beyond annotations.
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?
Description is two sentences but packed with information: the main action, what fields it provides, input flexibility, output detail, and alternative tool. No wasted words.
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?
Given the tool has an output schema (no need to describe return values), annotations providing safety profile, and one parameter with full schema coverage, the description covers all necessary aspects: input format, decoding behavior, owner redaction, and edge case handling (inactive numbers).
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 description does not need to add much. The description notes that the leading N is optional, but this is already present in the schema's description. No additional semantic value beyond schema.
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?
Description states the tool decodes a US civil aircraft N-number to full registration record, listing specific fields (make/model, engine, etc.). It distinguishes from sibling faa_get_registration_status by noting that inactive numbers are not found here, providing clear differentiation.
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 tells when to use: one call resolves relational joins and decodes coded fields. Also tells when not to use: inactive numbers are not found; directs to faa_get_registration_status for cross-file status answer. This provides clear usage guidance and alternatives.
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 the FAA aircraft reference table by manufacturer/model name (full-text), aircraft type code, or category code to discover 7-character manufacturer/model/series codes and browse specifications. Use this before faa_get_aircraft_type to find a code by name. At least one filter is required. When the result count hits the limit, the response discloses truncation.
| 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). | |
| category | No | Aircraft category code to match exactly (1 Land, 2 Sea, 3 Amphibian). | |
| aircraftType | No | Aircraft type code to match exactly (e.g. "6" for rotorcraft). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied (present only when capped). |
| shown | No | Number of results returned (present only when capped). |
| notice | No | Guidance when no aircraft types matched the supplied filters. |
| truncated | No | Present and true only when the result set was capped at the limit — more matches exist. |
| aircraftTypes | Yes | Matching aircraft-reference summaries (up to limit). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint. The description adds the behavioral trait that when the result count hits the limit, the response discloses truncation. No contradictions.
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: the first succinctly states the main action and output; the second adds usage guidance. No redundant information, well 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 4 fully described parameters, an output schema, and the description covering the output (codes and specifications), required filter, and truncation behavior, the description is complete for the tool's complexity.
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% with parameter descriptions. The description adds 'full-text' for query and 'match exactly' for category and aircraftType, providing extra context beyond schema baselines.
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 clearly states the tool searches the FAA aircraft reference table, lists search methods (manufacturer/model name, type code, category code), and specifies the output (7-character codes and specifications). It also differentiates from sibling tool faa_get_aircraft_type.
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?
The description explicitly advises 'Use this before faa_get_aircraft_type to find a code by name' and states 'At least one filter is required,' providing clear when-to-use and prerequisite guidance.
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, state, aircraft type, or Mode S (hex) code. Full-text search over the bundled registry; returns decoded summaries with N-numbers to drill into via faa_lookup_registration. At least one filter is required. Owner-name search is unavailable when this deployment redacts owner PII — search by make/model, state, aircraft type, or Mode S code instead. When the result count hits the limit, the response discloses truncation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–200, default 25). | |
| state | No | Two-letter state/territory abbreviation (exact match). | |
| makeModel | No | Aircraft make and/or model to match (full-text). | |
| modeSCode | No | Mode S code in hex to match exactly (ICAO 24-bit address). | |
| ownerName | No | Registrant name to match (full-text). Rejected when owner-PII redaction is on. | |
| aircraftType | No | Aircraft type code to match exactly (e.g. "4" for fixed-wing single-engine). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied (present only when capped). |
| shown | No | Number of results returned (present only when capped). |
| notice | No | Guidance when no registrations matched the supplied filters. |
| truncated | No | Present and true only when the result set was capped at the limit — more matches exist. |
| registrations | Yes | Matching registration summaries (up to limit). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, which the description complements by explaining that the tool is a search over a bundled registry, and that result truncation is disclosed when the limit is hit. It also warns that ownerName may be rejected under PII redaction, adding behavioral context beyond the annotations.
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?
The description is concise (4 sentences) and well-structured. The first sentence states the purpose, followed by additional context. Every sentence adds necessary information without redundancy.
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?
Given the complexity (6 parameters, output schema exists), the description covers all essential aspects: search scope, required filters, restrictions, and behavior on truncation. There are no apparent gaps.
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 significant value by clarifying search modes: 'full-text' for ownerName and makeModel, 'exact match' for state, modeSCode, and aircraftType. It also notes that ownerName is rejected when PII redaction is on, which is not in the schema description.
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 clearly states the tool searches active US civil aircraft registrations by multiple filters, and distinguishes itself from sibling tools like faa_lookup_registration by noting it returns summaries for drilling into specific N-numbers. The verb 'search' and resource 'registrations' are specific and unambiguous.
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?
The description explicitly states that at least one filter is required, and provides specific guidance on when owner-name search is unavailable (when PII redaction is active). It also directs the agent to use faa_lookup_registration for detailed lookups, offering clear when-to-use and when-not-to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!