faa-airmen-registry-mcp-server

Faa Airmen Verify Remote Pilot

faa_airmen_verify_remote_pilot

Read-onlyIdempotent

Find releasable FAA remote pilot certificate records by Unique ID or name. While the operator's personal-data redaction is on (the default), name mode needs lastName and firstName, nameMatch prefix and city or ZIP filters are rejected, and city and ZIP are withheld. Results establish certificate presence in the local snapshot; they do not establish recurrent-training currency, commercial operating authority, or current Part 107 eligibility.

Input Schema

Name	Required	Description
`city`	No	Exact city, 1–60 visible characters; requires operator-enabled location access and is rejected while personal-data redaction is on. Blank means unset.
`mode`	Yes	id requires uniqueId and forbids nonblank name/location fields and explicit nameMatch; name requires lastName, plus firstName while personal-data redaction is on, and forbids nonblank uniqueId.
`limit`	No	Maximum complete people or reference entries per page; default 10, maximum 50. A larger limit returns at most 50, with a notice.
`state`	No	Two-letter state or territory; trimmed and uppercased. Blank means unset.
`offset`	No	Zero-based offset; default 0, maximum 10000. Follow nextOffset or narrow filters at the cap.
`zipCode`	No	Five-digit ZIP or ZIP+4, preserving leading zeros; requires operator-enabled location access and is rejected while personal-data redaction is on. Blank means unset.
`lastName`	No	LAST NAME, which may include a suffix; the default words match finds SMITH JR from SMITH. 1–60 visible characters after normalization. Blank means unset.
`uniqueId`	No	Opaque FAA Unique ID returned by faa_airmen_verify_certificate in name mode, A or C plus seven digits, for example A9999999; not a certificate number. Trimmed and uppercased.
`firstName`	No	FIRST NAME, which usually includes middle names; the default words match finds JOHN ROBERT from JOHN. 1–60 visible characters after normalization. Blank means unset.
`nameMatch`	No	How each supplied name field matches; default words for name searches. words: the field equals the term or continues with a space after it; only a space separates words, so a hyphenated or apostrophe name is one word. exact: the whole field. prefix: the field begins with the term, also mid-word; rejected while personal-data redaction is on.

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Snapshot limitations, absence guidance, source-quality notices for the returned records, and operational notices; may be empty.
`hasMore`	No	Whether another page is reachable within the offset cap.
`matches`	No	Candidates with U certificate records in this snapshot.
`nextOffset`	No	Next reachable offset, or null when no next page is available.
`provenance`	No	Snapshot provenance, or null for static reference topics.
`totalCount`	No	Total matches after filtering, before paging.
`atPagingCap`	No	Matches remain but the next offset exceeds 10000; narrow the filters.
`piiRedacted`	No	Operator personal-data redaction: true withholds city, ZIP, and medical fields and limits searches to a full name or Unique ID.
`returnedCount`	No	Complete people or reference entries returned on this page.
`appliedFilters`	No	Every effective normalized selector, filter, and paging value.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only, idempotent, closed-world annotations, the description discloses the default personal-data redaction behavior, field rejection and withholding rules, local-snapshot scope, and limits on what the records prove. These are important behavioral traits an agent needs before calling or interpreting the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by operational constraints and then important interpretation caveats. It is dense but every sentence carries useful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full input schema, output schema, and annotations covering safety, the description adds the critical contextual caveats about redaction, local-snapshot scope, and eligibility/currency limitations. Nothing essential for correct invocation or interpretation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description restates the conditional name-mode and redaction requirements already documented in the schema fields and does not add meaning for the remaining parameters such as limit, offset, or state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Find') and resource ('releasable FAA remote pilot certificate records') scoped by Unique ID or name. It is clear, but it does not explicitly name sibling tools such as faa_airmen_verify_certificate to sharpen scope differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains when name mode applies, which filters are rejected under default redaction, and what the results do not establish. It provides strong context but does not explicitly route to an alternative sibling when the agent needs a different certificate scope or verification purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All faa-airmen-registry-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.