Offline, keyless lookup of the US civil aircraft registry — decode N-numbers, search records.
Each tool has a clear and distinct purpose: faa_get_aircraft_type decodes a code to specs, faa_search_aircraft_types discovers codes by name; faa_lookup_registration gets full details for active N-numbers, faa_get_registration_status handles inactive or unreserved ones; faa_search_registrations searches by criteria. Descriptions explicitly clarify overlaps, so agents can reliably choose the right tool.
All tools follow a uniform 'faa_verb_noun' pattern with consistent verb choices (get, lookup, search). The naming is predictable and makes the toolset easy to navigate.
Five tools is ideal for a focused registry server. Each tool provides a necessary function (search, decode, status check, full lookup) without redundancy, covering the core workflow in a lean set.
The toolset covers all key operations for a read-only aircraft registry: searching registrations and aircraft types, looking up full records, and checking registration status across all files. There are no obvious gaps for the intended use case.
Decode a 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. |
| Name | Required | Description |
|---|---|---|
| code | No | The 7-char 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral context by listing the specific output fields (cruise speed, type-certificate data sheet, etc.), which helps the agent anticipate the return value. It does not contradict annotations and provides useful detail beyond them, though it could mention error handling for invalid codes, which is a minor gap.
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 a single sentence that front-loads the action, then lists outputs, and ends with usage guidance. Every phrase earns its place: the action, the output fields, and the pointer to the sibling tool. There is zero waste and no repetition of schema content beyond what is necessary for context.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema (which explains return values), the description is thorough. It covers the purpose, the exact parameter format, and the workflow for obtaining a code. Nothing critical is missing for an agent to call this tool successfully.
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?
The schema description covers 100% of the parameter 'code', including its format (6–7 uppercase alphanumeric characters, usually 7) and an example. The description repeats this information almost verbatim without adding new meaning. Since the schema already carries the load, a baseline 3 is appropriate. The slight inconsistency of calling it '7-character' in the description while schema says 6–7 is minor and does not significantly affect understanding.
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 opens with a specific verb ('Decode') and a resource (a 7-character FAA manufacturer/model/series code), then enumerates the exact output fields (manufacturer, model, category, engine type, etc.). It clearly distinguishes this from sibling tools like faa_search_aircraft_types, which is for discovering codes, and faa_get_registration_status, which is about registration, not aircraft specs.
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 instructs the agent to 'Use faa_search_aircraft_types first to discover a code by manufacturer or model name.' This provides a clear precondition for when to use this tool versus the alternative, guiding the agent through the correct workflow. No exclusions are needed because the use case is self-evident from the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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). |
| 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 | 7-char manufacturer/model/series code (deregistered records). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds the important behavioral clarification that an unissued number returns recordType 'unknown' as a valid answer, not an error, which goes beyond the structured annotations. This adds genuine context for interpreting responses.
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 three sentences with no redundant wording. It front-loads the core purpose, then provides usage guidance, and finally clarifies input format. Every sentence earns its place, making it extremely concise yet informative.
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?
The tool is a single-parameter resolver and the description covers the input format, the semantic output categories, the 'unknown' handling, and the distinction from its primary sibling. With an output schema present and annotations for idempotence, nothing an agent needs to correctly invoke and interpret this tool 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% for the single nNumber parameter, which already includes format details (leading N optional, character shape). The description reinforces this ('Accepts "N12345" or "12345"') but adds no new semantics beyond the schema's own description, so a 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 clearly states the tool's verb ('Resolve') and resource ('US civil aircraft N-number'), and specifies the possible outcomes: active, deregistered, reserved, or unknown. It also explicitly contrasts with the sibling tool 'faa_lookup_registration' when a number may be inactive, making differentiation 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 provides explicit guidance: 'Use this rather than faa_lookup_registration when a number may be inactive.' This names the alternative and the exact condition for selection, leaving no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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). |
| 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 | 7-char manufacturer/model/series code. |
| engineManufacturerModelCode | No | 5-char engine manufacturer/model code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds owner redaction behavior (ownerRedacted flag) and the limitation that inactive numbers are not found, which are not covered by annotations. It does not contradict annotations; it enriches the safety and outcome picture beyond the structured hints.
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, each earning its place: the first states the primary function and output fields; the second covers input nuance and the alternative tool. It is slightly dense but well-organized and not bloated. The key action 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?
Given a single parameter, an existing output schema, and read-only/idempotent annotations, the description covers the output fields, owner redaction, input variations, and the limitation of inactive numbers with a pointer to the correct sibling. Nothing essential is missing for an agent to invoke it 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 description coverage is 100% and includes the same guidance about the optional leading N and accepted formats. The description repeats this rather than adding new parameter-specific meaning (e.g., examples or edge cases). Baseline 3 is appropriate when the schema already documents the parameter thoroughly.
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 verb 'Decode' with the resource 'US civil aircraft N-number' and enumerates the returned fields (make/model, engine, airworthiness, status, Mode S, owner). It explicitly differentiates from sibling faa_get_registration_status by noting that inactive numbers are not found here. This is specific and not a tautology.
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 names faa_get_registration_status as the alternative for inactive numbers, providing a clear when-not-to-use condition. It also clarifies the optional leading N in the input format, which guides correct invocation. This is direct and leaves little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FAA aircraft types by manufacturer/model name, 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. 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 to match exactly (1 Land, 2 Sea, 3 Amphibian). | |
| aircraftType | No | Aircraft type code to match exactly (e.g. "6" for rotorcraft). |
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: 'Every response reports totalCount (all matches, not just this page); when more remain, it returns nextOffset — pass it back as offset to page forward.' This explains pagination semantics and the totalCount meaning, which are not derivable from annotations or schema. No contradictions with 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?
Four sentences, each essential: purpose and outcome, sibling routing, filter requirement, and pagination behavior. The main purpose is front-loaded, followed by usage guidance and behavioral details. No filler or repetition of schema information. It is appropriately compact for the content it conveys.
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?
The description covers what the tool does, when to use it (before faa_get_aircraft_type), what inputs are acceptable (at least one filter, listed types), and the output semantics (totalCount, nextOffset, pagination). With an output schema present, return-value details are already structured, so the description doesn't need to restate them. The combination of annotations, schema, and description leaves no critical gap for an agent to call this 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 description coverage is 100%, so baseline is 3. The description adds meaning by mapping the search dimensions: 'by manufacturer/model name, aircraft type code, or category code' corresponds to query, aircraftType, and category. It also adds the critical constraint 'At least one filter is required,' which is not present in the schema (no required fields). This user-facing requirement goes beyond the schema's per-field descriptions, so a 4 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?
Description clearly states the tool's purpose: 'Search FAA aircraft types by manufacturer/model name, aircraft type code, or category code to discover 7-character manufacturer/model/series codes and browse specifications.' It names the specific resource (FAA aircraft types) and the output (codes, specifications). It also distinguishes from sibling faa_get_aircraft_type by explicitly positioning this as the search-before-retrieve step, so an agent can tell them apart without opening schemas.
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?
Provides explicit usage guidance: 'Use this before faa_get_aircraft_type to find a code by name.' This names the alternative and the condition that selects this tool. It also states the required precondition 'At least one filter is required' and explains pagination usage for continuing results. No ambiguity remains about when to call this versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search active US civil aircraft registrations by owner name, make/model, state, aircraft type, or Mode S (hex) code. 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. 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-letter state/territory abbreviation (exact match). | |
| 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 | 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). |
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds crucial behavioral details beyond those: the requirement for at least one filter, the owner-PII redaction condition, and the pagination mechanism (totalCount, nextOffset, offset). These are non-obvious behaviors that would otherwise be unknown. No contradiction with annotations exists.
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 three sentences with zero filler. It leads with the core purpose, then covers the required-filter constraint and the redaction caveat, and finishes with pagination behavior. Every sentence contributes essential information, and the structure is logical — purpose first, then constraints, then continuation mechanics.
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 tool with 7 optional parameters, an output schema, and a pagination design, the description covers all critical operational aspects: search fields, output format, mandatory-filter condition, deployment-specific redaction, and pagination flow. It even names the follow-up tool (faa_lookup_registration). There is no missing information an agent would need to invoke it correctly, especially given the annotations already cover read-only idempotency.
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 individual parameter descriptions, providing a baseline of 3. The description adds meaningful context on top: it clarifies that at least one filter is required (a cross-parameter constraint not in the JSON Schema, since no property is marked required), and it explains how offset relates to pagination via nextOffset. It also reinforces the ownerName rejection condition, tying the parameter to the deployment context. This goes beyond mere parameter listing.
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 opens with a specific verb and resource: 'Search active US civil aircraft registrations' and lists the searchable fields. It clearly distinguishes itself from the sibling tools by mentioning the drill-in step to faa_lookup_registration, establishing it as the search entry point rather than a lookup. The output expectation ('decoded summaries with N-numbers') is also stated, leaving no ambiguity about the tool's role.
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 a hard requirement ('At least one filter is required') and provides conditional guidance for when owner-name search is unavailable ('search by make/model, state, aircraft type, or Mode S code instead'). It also gives precise pagination instructions, telling the agent to pass nextOffset back as offset. This is actionable, context-specific guidance that distinguishes when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
faa_get_aircraft_type6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "code"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]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"
+}Output schema / requiredRemoved value: -[
- "code"
-]faa_get_registration_status7 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "recordType",
+ "nNumber",
+ "nNumberDisplay"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]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"
+}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."Output schema / requiredRemoved value: -[
- "recordType",
- "nNumber",
- "nNumberDisplay"
-]faa_lookup_registration12 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "nNumber",
+ "nNumberDisplay",
+ "fractionalOwner",
+ "ownerRedacted"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / engineMake / descriptionPrevious value: -"Engine manufacturer name, resolved from the reference table."New value: +"Engine manufacturer name."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."Output schema / properties / engineModel / descriptionPrevious value: -"Engine model name, resolved from the reference table."New value: +"Engine model name."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"
+}Output schema / properties / make / descriptionPrevious value: -"Aircraft manufacturer name, resolved from the reference table."New value: +"Aircraft manufacturer name."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."Output schema / properties / model / descriptionPrevious value: -"Aircraft model name, resolved from the reference table."New value: +"Aircraft model name."Output schema / requiredRemoved value: -[
- "nNumber",
- "nNumberDisplay",
- "fractionalOwner",
- "ownerRedacted"
-]faa_search_aircraft_types6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "aircraftTypes",
+ "totalCount"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]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"
+}Output schema / requiredRemoved value: -[
- "aircraftTypes",
- "totalCount"
-]faa_search_registrations6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "registrations",
+ "totalCount"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]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"
+}Output schema / requiredRemoved value: -[
- "registrations",
- "totalCount"
-]faa_get_aircraft_type1 field changedInput 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."faa_get_registration_status1 field changedInput 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)."faa_lookup_registration1 field changedInput 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)."faa_search_aircraft_types9 fields changedInput 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"
+}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)."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)."Output schema / properties / nextOffsetAdded value: +{
+ "description": "Offset to request the next page; absent when this page reached the end of the matches.",
+ "type": "number"
+}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."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)."Output schema / properties / totalCountAdded value: +{
+ "description": "Total aircraft types matching the filters, across all pages. Always present.",
+ "type": "number"
+}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."Output schema / requiredPrevious value: -[
- "aircraftTypes"
-]New value: +[
+ "aircraftTypes",
+ "totalCount"
+]faa_search_registrations9 fields changedInput 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"
+}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)."Output schema / properties / nextOffsetAdded value: +{
+ "description": "Offset to request the next page; absent when this page reached the end of the matches.",
+ "type": "number"
+}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."Output schema / properties / registrations / descriptionPrevious value: -"Matching registration summaries (up to limit)."New value: +"Matching registration summaries for this page (up to limit)."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)."Output schema / properties / totalCountAdded value: +{
+ "description": "Total registrations matching the filters, across all pages. Always present.",
+ "type": "number"
+}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."Output schema / requiredPrevious value: -[
- "registrations"
-]New value: +[
+ "registrations",
+ "totalCount"
+]faa_get_aircraft_typefaa_get_registration_statusfaa_lookup_registrationfaa_search_aircraft_typesfaa_search_registrationsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Offline global aviation reference — airports, runways, navaids, frequencies from OurAirports.
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.
Ferry-flight price estimates + aircraft, airport, FAA-registry, route & live-flight data.
Add one secure layer between your agents and this server.
