ourairports-mcp-server

Name: ourairports-mcp-server
Author: cyanheads

Server Details

Offline global aviation reference — airports, runways, navaids, frequencies from OurAirports.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-10 07:35
Transport: Streamable HTTP
URL
Repository: cyanheads/ourairports-mcp-server
GitHub Stars: 1
Server Listing: ourairports-mcp-server

TDQS

A4.7/5.0

Scored 2026-08-25 03:45 across 6 tools

Disambiguation5/5

Each tool targets a distinct operation: spatial lookup (find_airports, find_navaids), code-based retrieval (get_airport), free-text/faceted search (search_airports), runway attribute search (search_runways), and a reference table (list_countries). No two tools overlap in purpose; even the two 'search' tools are clearly differentiated by entity type.

Naming Consistency5/5

All tool names follow a strict 'ourairports_<verb>_<noun>' pattern with snake_case throughout. Verbs are distinct and indicative (find, get, list, search), and nouns clearly identify the resource (airports, navaids, countries, runways). The pattern is uniform and predictable.

Tool Count5/5

The server exposes exactly 6 tools, which is well-scoped for its domain. Each tool addresses a distinct core need: spatial proximity, code resolution, text/facet search, runway attributes, navaid lookup, and country/region reference. No unnecessary tools, and the count is within the ideal 3-15 range.

Completeness5/5

The surface covers the full read-only lifecycle for aviation data: find by location, resolve by code, search by name/facets, inspect runways, and retrieve navaids. The inclusion of a country lookup table for valid filters and clear cross-references (e.g., search_airports → get_airport) demonstrates thoughtful coverage. Since the dataset is static, CRUD operations aren't expected, and no obvious gaps exist.

Available Tools

6 tools

ourairports_find_airportsourairports-mcp-serverA

Read-onlyIdempotent

Inspect

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
`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
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance when no airport fell within the radius — e.g. widen radius_km.
`airports`	No	Airports within the radius, nearest-first.
`totalCount`	No	Number of airports returned within the radius.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not repeat those. It adds context beyond annotations by warning that 'OurAirports is community-edited — not authoritative for flight operations' and by disclosing that closed airports are excluded unless include_closed is set. No contradiction with annotations found.

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 compact, with the core purpose in the first sentence and supporting guidance (geocoding, data quality, include_closed) in the following three sentences. No redundant phrasing; every sentence earns its place. Information is front-loaded with the operative definition.

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 moderate complexity (6 params, 2 required) and the presence of a complete output schema (not shown but declared), the description covers all essential aspects: what it does, how it ranks results, its distance/bearing output, prerequisites (geocoding), and a safety caveat about data authority. Nothing an agent needs to invoke it correctly is 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% — every parameter (latitude, longitude, radius_km, type, limit, include_closed) has a clear description in the schema. The tool description adds no new parameter-specific meaning beyond what the schema already provides; it merely restates the coordinate requirement and the closed-airport default. Baseline 3 applies.

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 states a precise operation: 'Find airports within a radius of a latitude/longitude, ranked nearest-first by great-circle distance.' It names the specific resource (airports), the geographic constraint, and the ranking order, clearly distinguishing this location-based lookup from siblings like ourairports_search_airports (text search) and ourairports_get_airport (by ID).

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?

The description explicitly states when to use this tool ('The grounding tool for "nearest airport to here"'), how to compose it with upstream geocoding ('no geocoding, so resolve place names to lat/lon upstream first'), and when to avoid it (not authoritative for flight operations). It also notes the optional include_closed flag to control scope.

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

ourairports_find_navaidsourairports-mcp-serverA

Read-onlyIdempotent

Inspect

Find navigation aids (VOR, VOR-DME, DME, NDB, NDB-DME, TACAN, VORTAC) two ways: spatially, by passing latitude+longitude (with an optional radius_km); or relationally, by passing airport_code to get the navaids that serve that airport. Supply exactly one mode — both or neither is a validation error. Coordinate mode ranks nearest-first with distance (km) and bearing (degrees true). Frequencies are stored in kHz for every navaid type (a VOR on 114.5 MHz reads frequencyKhz 114500) and are also surfaced in MHz. Airport mode returns an empty list (not an error) when the airport exists but has no associated navaids; an unknown airport_code is an error. OurAirports is community-edited — not authoritative for flight operations.

ParametersJSON Schema

Name	Required	Description
`type`	No	Restrict to one navaid type: NDB, VOR-DME, VORTAC, TACAN, VOR, DME, or NDB-DME.
`limit`	No	Maximum navaids to return (1–50). Defaults to OURAIRPORTS_DEFAULT_SEARCH_LIMIT (20).
`latitude`	No	Coordinate mode: query point latitude (−90 to 90). Provide with longitude; mutually exclusive with airport_code.
`longitude`	No	Coordinate mode: query point longitude (−180 to 180). Provide with latitude.
`radius_km`	No	Coordinate mode: search radius in kilometers (1–500). Defaults to 100. Ignored in airport mode.
`airport_code`	No	Airport mode: any airport code (IATA/ICAO/GPS/local/ident); returns the navaids serving that airport. Case-insensitive; surrounding whitespace is ignored. Mutually exclusive with latitude/longitude.

Output Schema

ParametersJSON Schema

Name	Required	Description
`mode`	No	Which query mode was used.
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance when no navaids matched (empty radius, or airport found but unserved).
`navaids`	No	Matching navaids. Nearest-first in coordinate mode; in airport-association order in airport mode.
`totalCount`	No	Number of navaids returned.
`airportIdent`	No	In airport mode, the resolved airport ident the navaids were matched against; null in coordinate mode.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, which the description does not contradict. The description goes beyond annotations by detailing mode-specific behavior: coordinate mode ranks nearest-first with distance and bearing, airport mode returns an empty list for existing airports without navaids but errors on unknown codes, frequency units are given in kHz and MHz, and it warns that the data is community-edited. This is rich, non-redundant context.

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 moderately long but each sentence contributes new information. It is well-structured by mode, leading with the core purpose and then detailing the two paths. The frequency unit explanation and data-quality caveat are useful but might be slightly tangential in the main flow; however, they are concise and front-loaded enough to remain helpful.

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 that an output schema exists (so return values are documented), the description covers all essential behavioral aspects: the two modes, validation rules, result ordering, error semantics, frequency units, and data authority caveat. Nothing critical is missing for an agent to correctly invoke the tool and interpret results.

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%, so the schema already documents each parameter. The description adds meaningful semantics: the mode relationships and mutual exclusivity, defaults for radius_km and limit, and the interpretation of frequencyKhz. It clarifies how parameters interplay (e.g., radius_km ignored in airport mode), which is not explicit in the schema. This adds value beyond the structured definitions.

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 opens with a clear verb and resource: 'Find navigation aids' and enumerates the navaid types. It distinguishes this tool from sibling tools (airports, runways, countries) by focusing on navaids and offering two explicit search modes. The purpose is unambiguous and immediately recognizable.

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 explains the two mutually exclusive modes (spatial and airport-based) and the validation rule that exactly one mode must be supplied. It gives concrete context for each mode's parameters and behavior. However, it does not explicitly name alternative tools or state when not to use this tool, but given the sibling names and the specificity of navaids, the use case is clear enough.

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-serverA

Read-onlyIdempotent

Inspect

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
`error`	No	Present when the call failed. Absent on success.
`airport`	No	The resolved airport record. Codes the airport lacks are null.
`runways`	No	Runways for the airport. Empty when the airport has none OR when `runways` was not in `include` — check `included` to tell which.
`included`	No	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`	No	Radio frequencies in MHz. Empty when the airport has none OR when `frequencies` was not in `include` — check `included` to tell which.
`resolvedVia`	No	Which identifier space the code matched: ident, icao_code, iata_code, gps_code, or local_code.
`resolutionNote`	No	Human-readable note on how the code resolved, including an ambiguity warning for shared national codes.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond readOnly and idempotent hints, it reveals case-insensitivity, resolution priority, response echoes, null handling, closed airport inclusion, and community-edited nature. No contradiction.

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?

Well-structured with core purpose first, followed by resolution details and caveats. No wasted sentences; all information is relevant and concise for its richness.

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 output schema exists and the description covers edge cases (ambiguous codes, nulls, closed airports, authoritative caveat), it is complete for an agent to call correctly.

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?

With 100% schema coverage, baseline is 3; description adds semantic detail for the code parameter (priority across five identifiers, whitespace ignored) and clarifies include default behavior. Adds value over 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?

States explicitly it fetches a full airport record by any code, specifying the verb and resource. It distinguishes from search tools by emphasizing resolution by code rather than search.

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?

Provides guidance on resolution priority and self-correction for ambiguous codes, and notes behavior for closed airports. Does not explicitly contrast with search tools but context implies using this for known codes.

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-serverA

Read-onlyIdempotent

Inspect

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
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance when the continent filter matched no countries.
`countries`	No	Countries present in the dataset, sorted by name.
`totalCount`	No	Number of countries returned.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds a behavioral fact not in annotations: 'Counts exclude closed airports.' It also clarifies that the dataset is bundled, which is useful context. This goes beyond what annotations provide.

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 two sentences, front-loaded with the core purpose. The first sentence states what it does and what it returns; the second covers optional behavior and a caveat. No wasted words, and the structure helps an agent quickly grasp the tool.

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 an output schema present, the description doesn't need to explain return format. It covers purpose, usage, optional parameters, and a key exclusion (closed airports). It also links to search_airports, giving the agent enough context to call it correctly. Nothing essential is 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 parameters are fully documented in the schema. The description reinforces the meaning of include_regions ('nest each country's regions') and continent restriction, but doesn't add new semantic information beyond the schema. Baseline 3 is appropriate.

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 states a specific verb ('list') and resource (countries in the OurAirports dataset) with output details (ISO codes and airport counts). It also distinguishes itself from siblings by explicitly positioning it as the lookup table for valid country/region filter values used by ourairports_search_airports, making its role clear.

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 gives clear context: it is the lookup table for valid country (and region) filter values for ourairports_search_airports, implying when to use it. It also mentions optional continent filtering and include_regions. It does not explicitly rule out other tools, but the purpose makes the usage obvious.

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-serverA

Read-onlyIdempotent

Inspect

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
`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.
`error`	No	Present when the call failed. Absent on success.
`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`	No	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`	No	Total airports matched before the limit was applied.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover read-only and idempotent; description adds matching rules (every token must match), ranking (operational and larger first), and the caveat that data is community-edited. Also states return fields (full code set, coordinates) and exclusion behavior. This goes beyond annotations to inform agent behavior.

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?

Description front-loads the core purpose and keeps every sentence functional. It avoids fluff and packs usage guidance, caveats, and sibling routing into a compact paragraph.

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?

For a read-only search tool with an output schema, the description covers usage, parameter semantics, alternatives, and data caveats. It also mentions chaining into get_airport and list_countries for codes. Nothing an agent needs to invoke correctly is 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 coverage is 100%, so each parameter has a description. The tool description restates the query semantics (tokens AND-matched) and facet filters but doesn't add meaning significantly beyond what the schema already provides. Baseline 3 is appropriate.

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?

States a specific verb (search) + resource (OurAirports corpus) and the facets (country, region, type). Distinguishes from siblings by naming ourairports_find_airports for nearest-coordinate and ourairports_get_airport for chaining. Clear and specific.

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 says when to use this tool vs alternatives: 'For nearest airport to a coordinate use ourairports_find_airports instead' and 'Use ourairports_list_countries for valid country/region codes'. Also clarifies that closed airports are excluded unless include_closed, and that query tokens are AND-matched. No ambiguity.

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-serverA

Read-onlyIdempotent

Inspect

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
`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.
`error`	No	Present when the call failed. Absent on success.
`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`	No	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`	No	Total matching runways before the limit was applied.

TDQS

A5/5.0

Behavior5/5

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

Discloses behaviors beyond the readOnly/idempotent annotations: flat row structure (one row per matching runway), surface substring matching semantics with examples, exclusion of runways with unknown length/width when min_*_ft filters are set, and closed handling. These are non-obvious traits essential for correct invocation and interpretation.

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?

Despite its length, every sentence adds distinct value: purpose, sibling contrast, output shape, surface semantics, unknown-value handling, closed handling, reference tool, and data quality caveat. Information is front-loaded with the primary purpose and key differentiator first, and the structure is logical.

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 (10 parameters, 100% schema coverage, output schema present) and annotations, the description covers all critical aspects: return format, filtering edge cases, exclusion rules, reference to country codes, and data quality caveats. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds crucial semantic depth: the surface parameter's substring behavior (no controlled vocabulary, shorter fragments match more), the min_length_ft/min_width_ft exclusion rule, and the include_closed_* flags' effects. This goes well beyond the schema's per-parameter descriptions.

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?

States a specific verb (Search) and resource (runways) across the whole bundled corpus, and explicitly contrasts with ourairports_get_airport (which returns runways for one already-known airport). This makes the tool's purpose and scope unambiguous and differentiates it from the sibling tool.

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 frames this tool as the 'cross-airport counterpart' to ourairports_get_airport, telling the agent when to use it instead. Also directs to ourairports_list_countries for valid country/region codes and warns that the data is community-edited, providing clear context for when to trust the results.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesAug 25, 2026

Changedourairports_find_airports6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "airports",
+      "totalCount"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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.",
+          "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"
+}

removedOutput schema / required

Removed value: -[
-  "airports",
-  "totalCount"
-]

Changedourairports_find_navaids6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "mode",
+      "airportIdent",
+      "navaids",
+      "totalCount"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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: `mode_conflict`: Both coordinate (latitude/longitude) and airport_code were supplied, or neither was. `unknown_code`: airport_code did not match any airport in any identifier space. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "mode_conflict",
+            "unknown_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"
+}

removedOutput schema / required

Removed value: -[
-  "mode",
-  "airportIdent",
-  "navaids",
-  "totalCount"
-]

Changedourairports_get_airport6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "airport",
+      "resolvedVia",
+      "resolutionNote",
+      "included",
+      "runways",
+      "frequencies"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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: `unknown_code`: No airport matched the supplied code in any identifier space (IATA/ICAO/GPS/local/ident). Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "unknown_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"
+}

removedOutput schema / required

Removed value: -[
-  "airport",
-  "resolvedVia",
-  "resolutionNote",
-  "included",
-  "runways",
-  "frequencies"
-]

Changedourairports_list_countries6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "countries",
+      "totalCount"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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.",
+          "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"
+}

removedOutput schema / required

Removed value: -[
-  "countries",
-  "totalCount"
-]

Changedourairports_search_airports6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "airports",
+      "totalCount"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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.",
+          "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"
+}

removedOutput schema / required

Removed value: -[
-  "airports",
-  "totalCount"
-]

Changedourairports_search_runways6 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "runways",
+      "totalCount"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added 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.",
+          "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"
+}

removedOutput schema / required

Removed value: -[
-  "runways",
-  "totalCount"
-]

1 tool updateJul 18, 2026
- Addedourairports_search_runways

3 tool updatesJul 18, 2026

Changedourairports_find_navaids2 fields changed

changedInput schema / properties / airport_code / description

Previous value: -"Airport mode: any airport code (IATA/ICAO/GPS/local/ident); returns the navaids serving that airport. Mutually exclusive with latitude/longitude."New value: +"Airport mode: any airport code (IATA/ICAO/GPS/local/ident); returns the navaids serving that airport. Case-insensitive; surrounding whitespace is ignored. Mutually exclusive with latitude/longitude."

addedInput schema / properties / airport_code / minLength
```
Added value: +1
```

Changedourairports_get_airport5 fields changed

changedInput schema / properties / code / description

Previous value: -"Any airport code: IATA (SEA), ICAO (KSEA), GPS code, national/local code, or the OurAirports ident. Case-insensitive."New value: +"Any airport code: IATA (SEA), ICAO (KSEA), GPS code, national/local code, or the OurAirports ident. Case-insensitive; surrounding whitespace is ignored."

changedOutput schema / properties / frequencies / description

Previous value: -"Radio frequencies in MHz (empty array when none recorded, or when frequencies were not requested in `include`)."New value: +"Radio frequencies in MHz. Empty when the airport has none OR when `frequencies` was not in `include` — check `included` to tell which."

addedOutput schema / properties / included

Added value: +{
+  "description": "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.",
+  "items": {
+    "enum": [
+      "runways",
+      "frequencies"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / runways / description

Previous value: -"Runways for the airport (empty array when none recorded, or when runways were not requested in `include`)."New value: +"Runways for the airport. Empty when the airport has none OR when `runways` was not in `include` — check `included` to tell which."

changedOutput schema / required

Previous value: -[
-  "airport",
-  "resolvedVia",
-  "resolutionNote",
-  "runways",
-  "frequencies"
-]New value: +[
+  "airport",
+  "resolvedVia",
+  "resolutionNote",
+  "included",
+  "runways",
+  "frequencies"
+]

Changedourairports_search_airports4 fields changed

changedInput schema / properties / country / description

Previous value: -"ISO 3166-1 alpha-2 country code filter (e.g. US). Exact match. Discover codes with ourairports_list_countries."New value: +"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."

addedInput schema / properties / country / minLength
```
Added value: +1
```

changedInput schema / properties / region / description

Previous value: -"ISO 3166-2 region code filter (e.g. US-WA). Exact match."New value: +"ISO 3166-2 region code filter (e.g. US-WA). Exact match, case-insensitive; surrounding whitespace is ignored."

addedInput schema / properties / region / minLength
```
Added value: +1
```

1 tool updateJun 30, 2026

Changedourairports_find_airports2 fields changed

removedInput schema / properties / limit / default
```
Removed value: -10
```

changedInput schema / properties / limit / description

Previous value: -"Maximum airports to return (1–50). Defaults to 10."New value: +"Maximum airports to return (1–50). Defaults to OURAIRPORTS_DEFAULT_SEARCH_LIMIT (20)."

5 tool updatesJun 16, 2026
- First observedourairports_find_airports
- First observedourairports_find_navaids
- First observedourairports_get_airport
- First observedourairports_list_countries
- First observedourairports_search_airports

Related MCP Connectors

faa-aircraft-registry-mcp-server A
io.github.cyanheads
Offline, keyless lookup of the US civil aircraft registry — decode N-numbers, search records.
Government Data Search
522
airports A
io.github.pipeworx-io
Airports MCP — wraps AirportGap API (free, no auth required)
Travel & Transportation Open Data Search
342
FerryFlight
com.ferryflighthub
Ferry-flight price estimates + aircraft, airport, FAA-registry, route & live-flight data.
Travel & Transportation Location Services
2
Live Flight Data B
org.memoryapi
Live flight departures and airport information
Travel & Transportation Location Services
22

Related MCP Servers

@cyanheads/faa-aircraft
Travel & Transportation Government Data Open Data
cyanheads
A
license
Not graded
quality
A
maintenance
Enables offline lookup and search of the US civil aircraft registry by N-number, owner, type, or state, returning detailed aircraft and ownership information.
Updated 16 days ago (2026-08-25 03:02 UTC)
239
2
Apache 2.0
MCP Transportasi Bandara &
Travel & Transportation Location Services
tirthanzh
F
license
Not graded
quality
D
maintenance
Provides tools to search and retrieve detailed information about airports and seaports in Indonesia, including runways, radio frequencies, nearby airports, and port statistics.
Updated 3 months ago (2026-06-10 06:54 UTC)
-
mcp-aviation-weather
Weather Services Travel & Transportation
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides aviation weather data including METAR, TAF, PIREPs, AIRMET/SIGMET, station info, and winds aloft forecasts.
Updated 15 days ago (2026-08-26 16:42 UTC)
18
MIT
FAA Delays MCP
Travel & Transportation Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides live US airport operational status and delay data from the FAA, free and without authentication.
Updated 15 days ago (2026-08-26 17:05 UTC)
9
MIT

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources