A
license-
qualityA
maintenanceEnables offline lookup and search of the US civil aircraft registry by N-number, owner, type, or state, returning detailed aircraft and ownership information.
Last updated
120
1
Apache 2.0
ourairports-mcp-server
Server Details
Offline global aviation reference — airports, runways, navaids, frequencies from OurAirports.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/ourairports-mcp-server
- GitHub Stars
- 1
- Server Listing
- ourairports-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.7/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct operation: find airports by location, find navaids by location or airport, get airport details by code, list countries, and search airports by text/facets. There is no functional overlap, making selection unambiguous.
Naming Consistency4/5
All tools share the 'ourairports_' prefix and use snake_case. The verbs are mostly consistent ('find', 'get', 'list', 'search'), though 'find' and 'search' overlap in meaning. The pattern is predictable and clear.
Tool Count5/5
With 5 tools, the server is well-scoped for a read-only aviation data service. Each tool serves a clear purpose without redundancy, and the count is appropriate for the domain.
Completeness4/5
The set covers primary query patterns (location-based search, code lookup, text search, country listing). Minor gaps exist, such as no direct navaid code lookup or listing all airports, but core workflows are supported.
Available Tools
6 toolsourairports_find_airportsourairports-mcp-serverARead-onlyIdempotentInspect
Find airports within a radius of a latitude/longitude, ranked nearest-first by great-circle distance, each with its distance (km) and bearing (degrees true) from the query point. The grounding tool for "nearest airport to here" — pair it with a live aviation server to fetch weather or positions for the result. Takes a coordinate only: no geocoding, so resolve place names to lat/lon upstream first (e.g. an OpenStreetMap or Open-Meteo geocode tool). Closed airports are excluded unless include_closed is set. OurAirports is community-edited — not authoritative for flight operations.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to one airport type (e.g. large_airport for major fields only). | |
| limit | No | Maximum airports to return (1–50). Defaults to OURAIRPORTS_DEFAULT_SEARCH_LIMIT (20). | |
| latitude | Yes | Query point latitude in decimal degrees (WGS84), −90 to 90. | |
| longitude | Yes | Query point longitude in decimal degrees (WGS84), −180 to 180. | |
| radius_km | No | Search radius in kilometers (1–500). Defaults to 100. | |
| include_closed | No | Include airports of type "closed". Off by default. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no airport fell within the radius — e.g. widen radius_km. |
| airports | Yes | Airports within the radius, nearest-first. |
| totalCount | Yes | Number of airports returned within the radius. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true. Description adds that airports are ranked by distance, includes distance and bearing, and warns that data is community-edited and not authoritative. No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 3-4 sentences, front-loaded with core purpose, no redundant words. Highly efficient.
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?
Given the tool has an output schema, full parameter documentation, and annotations, the description covers behavior, limitations, usage flow, and data source. Complete for a read-only query tool.
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 baseline is 3. The description does not add new parameter semantics beyond what the schema provides; it only contextualizes usage. No extra meaning added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds airports within a radius of a lat/long, ranked by distance and bearing. It distinguishes from siblings like ourairports_search_airports (search by name/code) and ourairports_get_airport (single airport).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's for 'nearest airport to here', advises pairing with a live aviation server, notes no geocoding built-in, and recommends upstream geocode tools. Also mentions closed airport filtering. Comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ourairports_get_airportourairports-mcp-serverARead-onlyIdempotentInspect
Fetch the full record for one airport resolved by ANY code — IATA (SEA), ICAO (KSEA), GPS, national/local, or the OurAirports ident — with its runways and radio frequencies inline. The single code param is resolved case-insensitively across all five identifier spaces (priority: ident, then ICAO, IATA, GPS, local). The response always echoes the airport's complete code set and a resolution_note naming which space matched, so a wrong resolution from an ambiguous national code is self-correcting (re-query with the IATA or ICAO code, or the ident). Absent codes are reported as null, never an error. Closed airports always resolve. OurAirports is community-edited — not authoritative for flight operations.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Any airport code: IATA (SEA), ICAO (KSEA), GPS code, national/local code, or the OurAirports ident. Case-insensitive; surrounding whitespace is ignored. | |
| include | No | Which related records to include inline. Defaults to both. Pass a subset to trim the response. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| airport | Yes | The resolved airport record. Codes the airport lacks are null. |
| runways | Yes | Runways for the airport. Empty when the airport has none OR when `runways` was not in `include` — check `included` to tell which. |
| included | Yes | Which related-record sets this response carries, echoing the effective `include` selection. A relation NOT listed here was omitted by `include` (its array is empty for that reason); a listed relation with an empty array genuinely has no records. |
| frequencies | Yes | Radio frequencies in MHz. Empty when the airport has none OR when `frequencies` was not in `include` — check `included` to tell which. |
| resolvedVia | Yes | Which identifier space the code matched: ident, icao_code, iata_code, gps_code, or local_code. |
| resolutionNote | Yes | Human-readable note on how the code resolved, including an ambiguity warning for shared national codes. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds rich behavioral details: case-insensitive resolution with priority order (ident > ICAO > IATA > GPS > local), response includes resolution_note, absent codes reported as null (not errors), closed airports always resolve, and the dataset is community-edited (not authoritative). No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 4 sentences, with the main action front-loaded. Every sentence adds essential information: resolution logic, response structure, error handling, and caveat about data authority. No redundant or unclear phrasing.
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?
Given the tool's complexity (code resolution, inline records, community data), the description covers all necessary aspects: how codes are resolved, what the response contains (code set, resolution_note), error behavior (null vs error), closure handling, and data reliability. The output schema exists but is not provided; however, the description sufficiently describes the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds extra meaning for the `code` parameter: case-insensitive resolution across five identifier spaces, priority order, and whitespace trimming. For `include`, no additional meaning is provided, but the default is clearly stated. Since schema coverage is high, baseline 3 is exceeded due to the added detail on code resolution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch the full record for one airport resolved by ANY code', specifying the verb (fetch), resource (airport record), and scope (by any code). It distinguishes from sibling tools like ourairports_search_airports and ourairports_find_airports by focusing on a single record lookup with code resolution across multiple identifier spaces.
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?
The description provides clear context on when to use the tool: when you have any airport code and need the full record with runways and frequencies. It advises using IATA/ICAO codes for less ambiguity and notes the community-edited nature, implying it's not for authoritative flight operations. However, it lacks explicit guidance on when not to use it versus alternatives, e.g., for searching multiple airports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ourairports_list_countriesourairports-mcp-serverARead-onlyIdempotentInspect
List the countries present in the bundled OurAirports dataset with their ISO 3166-1 alpha-2 codes and airport counts. This is the lookup table for valid country (and, with include_regions, region) filter values used by ourairports_search_airports. Optionally restrict to a continent or nest each country's regions. Counts exclude closed airports.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| continent | No | Restrict to one continent: AF (Africa), AN (Antarctica), AS (Asia), EU (Europe), NA (North America), OC (Oceania), SA (South America). | |
| include_regions | No | When true, nest each country's ISO 3166-2 regions (with airport counts) under it. Off by default to keep the response compact. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when the continent filter matched no countries. |
| countries | Yes | Countries present in the dataset, sorted by name. |
| totalCount | Yes | Number of countries returned. |
Tool Definition Quality
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds that counts exclude closed airports and that include_regions defaults to false for compactness. Adequate but not extensive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence states core purpose, second adds optional behavior. Front-loaded with main action.
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?
Given presence of output schema, description need not detail return values. Covers both parameters, mentions exclusions, and explains positioning among sibling tools. Fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context: continent restriction is optional, include_regions nesting explained, and ties parameters to sibling tool usage, adding meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists countries with ISO codes and airport counts. Distinguishes from siblings by positioning itself as the lookup table for filter values used by ourairports_search_airports.
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?
Explicitly states this is the lookup table for valid filter values for ourairports_search_airports, giving clear context for when to use it. Does not formally state when not to use, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ourairports_search_airportsourairports-mcp-serverARead-onlyIdempotentInspect
Search the bundled OurAirports corpus by free-text (name / municipality / keywords) and/or facets (country, region, type). Every query token must match (word order and partial words are handled). Returns ranked airport summaries — operational and larger airports first — each with its full code set and coordinates, ready to chain into ourairports_get_airport. Closed airports are excluded unless include_closed is set. Use ourairports_list_countries for valid country/region codes. For "nearest airport to a coordinate" use ourairports_find_airports instead. OurAirports is community-edited — not authoritative for flight operations.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to one airport type: large_airport, medium_airport, small_airport, heliport, seaplane_base, balloonport, or closed. | |
| limit | No | Maximum airports to return (1–100). Defaults to OURAIRPORTS_DEFAULT_SEARCH_LIMIT (20). | |
| query | No | Free-text search over airport name, municipality, and keywords. Tokens are AND-matched. Omit to browse purely by facets. | |
| region | No | ISO 3166-2 region code filter (e.g. US-WA). Exact match, case-insensitive; surrounding whitespace is ignored. | |
| country | No | ISO 3166-1 alpha-2 country code filter (e.g. US). Exact match, case-insensitive; surrounding whitespace is ignored. Discover codes with ourairports_list_countries. | |
| include_closed | No | Include airports of type "closed". Off by default — closed airports pollute the live-flight grounding use case. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. Present only when results were truncated. |
| shown | No | Number of airports returned. Present only when results were truncated. |
| notice | No | Guidance when nothing matched or results were capped — how to broaden or narrow. |
| airports | Yes | Matching airports, ranked best-first. Codes the airport lacks are null. |
| truncated | No | Present and true only when more airports matched than were returned. |
| totalCount | Yes | Total airports matched before the limit was applied. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds ranking behavior ('operational and larger airports first'), token matching details, and the community-edited caveat. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured paragraph that front-loads the purpose, then adds details and cross-references. Every sentence earns its place 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?
Given the tool's complexity (6 parameters, 5 siblings, output schema exists), the description covers all necessary aspects: purpose, usage guidelines, behavioral traits, parameter hints, and relationships to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; the description adds contextual behavior like 'Every query token must match (word order and partial words are handled)' and clarifies default for limit. This goes slightly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'by free-text (name / municipality / keywords) and/or facets (country, region, type),' distinguishing it from sibling tools like ourairports_find_airports and ourairports_list_countries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (searching by text/facets), when not to use ('For nearest airport to a coordinate use ourairports_find_airports instead'), and provides prerequisites ('Use ourairports_list_countries for valid country/region codes').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ourairports_search_runwaysourairports-mcp-serverARead-onlyIdempotentInspect
Search runways across the whole bundled OurAirports corpus by attribute, joined back to their airports — the cross-airport counterpart to ourairports_get_airport (which returns runways for one already-known airport). Filter by airport facets (country, region, type) and runway facets (surface, min_length_ft, min_width_ft, lighted). Returns one flat {airport, runway} row per matching runway, so an airport with three matching runways contributes three rows. surface is a case-insensitive substring match against the raw upstream surface string, not an exact code — the runway surface must CONTAIN your text, so a shorter fragment matches more variants (no controlled vocabulary: "asp" matches ASP, ASPH, and Asphalt). A runway whose length or width is unknown is excluded when the matching min_*ft filter is set — the data can never confirm it meets the threshold. Closed airports and closed runways are both excluded unless their include* flag is set. Use ourairports_list_countries for valid country/region codes. OurAirports is community-edited — not authoritative for flight operations.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to runways at airports of one type: large_airport, medium_airport, small_airport, heliport, seaplane_base, balloonport, or closed. | |
| limit | No | Maximum runway rows to return (1–100). Defaults to OURAIRPORTS_DEFAULT_SEARCH_LIMIT (20). | |
| region | No | ISO 3166-2 region code filter (e.g. US-WA). Exact match, case-insensitive; surrounding whitespace is ignored. | |
| country | No | ISO 3166-1 alpha-2 country code filter (e.g. US). Exact match, case-insensitive; surrounding whitespace is ignored. Discover codes with ourairports_list_countries. | |
| lighted | No | Filter by runway lighting: true for lighted runways only, false for unlighted only. Omit to include both. | |
| surface | No | Surface filter — case-insensitive substring match against the raw upstream surface string (free text, no controlled vocabulary; ~654 distinct values). Match the literal text as recorded: "asp" matches ASP/ASPH/Asphalt/ASPH-G, "con" matches CON/Concrete, "turf" or "grs" for grass strips. A shorter fragment matches more variants; there is no enum or reference tool for surfaces. | |
| min_width_ft | No | Minimum runway width in feet (inclusive). Runways with an unknown width are excluded when this is set, never assumed to pass. | |
| min_length_ft | No | Minimum runway length in feet (inclusive). Runways with an unknown length are excluded when this is set, never assumed to pass. | |
| include_closed_runways | No | Include runways flagged closed. Off by default. | |
| include_closed_airports | No | Include runways at airports of type "closed". Off by default. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. Present only when results were truncated. |
| shown | No | Number of runway rows returned. Present only when results were truncated. |
| notice | No | Guidance when nothing matched or results were capped — how to broaden or narrow. |
| runways | Yes | Matching runways, each paired with its airport. One row per runway — an airport with N matching runways contributes N rows. |
| truncated | No | Present and true only when more runways matched than were returned. |
| totalCount | Yes | Total matching runways before the limit was applied. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant detail beyond annotations: one row per runway, surface is case-insensitive substring match with examples, unknown length/width excluded when filtering, closed entities excluded unless flags set, and data is community-edited. Annotations (readOnly, idempotent) are consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive and well-structured, front-loading the main purpose. Every sentence adds value, though it could be slightly more concise without losing clarity.
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?
Given the 10 parameters, output schema exists, and complexity, the description is complete. It explains the flat return format, filtering behavior, and caveats, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds critical context: explains substring matching for surface with examples, notes that unknown length/width cause exclusion when filters are applied, and describes the default limit. This adds substantial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches runways across the entire corpus and joins back to airports, distinguishing it from ourairports_get_airport which returns runways for a single known airport. The verb 'search' and resource 'runways' are specific.
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?
Explicitly identifies itself as the cross-airport counterpart to ourairports_get_airport, guiding when to use which. Also recommends ourairports_list_countries for valid codes. Lacks explicit when-not-to-use scenarios but context is clear.
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!
Related MCP Servers
- Flicense-qualityCmaintenanceProvides tools to search and retrieve detailed information about airports and seaports in Indonesia, including runways, radio frequencies, nearby airports, and port statistics.Last updated
- Alicense-qualityCmaintenanceProvides aviation weather data including METAR, TAF, PIREPs, AIRMET/SIGMET, station info, and winds aloft forecasts.Last updated28MIT
- Alicense-qualityCmaintenanceProvides live US airport operational status and delay data from the FAA, free and without authentication.Last updated25MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.