ourairports-mcp-server
Server Details
Offline global aviation reference — airports, runways, navaids, frequencies from OurAirports.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: spatial airport search, navaid lookup (spatial or by airport), airport details by code, country listing, and free-text airport search. No overlap in functionality.
All tools follow the 'ourairports_verb_noun' pattern consistently, e.g., ourairports_find_airports, ourairports_get_airport, ourairports_search_airports. The naming is predictable and clear.
Five tools is well-scoped for a reference database server covering spatial queries, detail lookup, search, and metadata. Each tool earns its place without unnecessary duplication.
The tool surface covers the core use cases: finding airports geographically, getting details by code, searching by text, listing countries, and finding navaids. Minor gaps exist, such as no dedicated tool to list all airports directly, but search can likely handle broad queries.
Available Tools
5 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.
| 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 10. | |
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds critical behavioral context: community-edited data (not authoritative), exclusion of closed airports by default, and output fields (distance and bearing). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each purposeful: operation details, role suggestion, input requirement, exclusions and caveat. No wasted words, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, output schema, annotations), the description covers purpose, usage context, input constraints, behavioral nuances, data quality warning, and next-step suggestions. Fully sufficient for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description doesn't need to repeat parameter details. However, it adds value by clarifying that the tool takes coordinates only (no geocoding) and that place names must be resolved upstream, which goes beyond the schema's 'latitude' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Find airports within a radius') and resources, clearly distinguishes from sibling tools like search and get, and explicitly positions itself as the 'grounding tool for nearest airport to here.'
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 guidance: no geocoding, resolve place names upstream, pair with live aviation server, and includes when to set include_closed. Does not explicitly list when not to use it, but the context of siblings is implied.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Any airport code: IATA (SEA), ICAO (KSEA), GPS code, national/local code, or the OurAirports ident. Case-insensitive. | |
| include | No | Which related records to include inline. Defaults to both. Pass a subset to trim the response. |
Output Schema
| Name | Required | Description |
|---|---|---|
| airport | Yes | The resolved airport record. Codes the airport lacks are null. |
| runways | Yes | Runways for the airport (empty array when none recorded, or when runways were not requested in `include`). |
| frequencies | Yes | Radio frequencies in MHz (empty array when none recorded, or when frequencies were not requested in `include`). |
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds critical behavioral context: resolution priority order, null for absent codes, closed airports always resolve, community-edited source, and response includes resolution_note for self-correction.
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?
Single paragraph packs all information effectively, but slightly denser than necessary; could benefit from structured bullet points for readability.
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 existing output schema, description covers all essential behavioral details: code resolution, error handling, data source caveats, and inline records.
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% but description enhances with code resolution order and case-insensitivity for 'code', and trimming response with 'include' subset.
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 'Fetch the full record for one airport resolved by ANY code', specifying the verb (fetch), resource (airport), and distinguishing it from sibling tools like search by focusing on single airport resolution.
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 guidance on resolution priority and handling ambiguous codes ('re-query with IATA or ICAO code'), but does not explicitly state when not to use it compared to siblings.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only, idempotent, and closed-world hints. The description adds behavioral details: counts exclude closed airports, and the include_regions parameter nests regions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the main purpose, and contains no unnecessary information. Every sentence adds value.
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 presence of an output schema, two optional parameters, and clear annotations, the description fully covers what the tool does, what it returns, and how parameters affect behavior. It is complete for a list tool.
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%, but the description adds context: 'Off by default to keep the response compact' for include_regions, and reinforces the meaning of continent codes. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists countries with ISO codes and airport counts, and explains its role as a lookup table for filter values used by a sibling tool. It specifies optional parameters for continent restriction and region nesting, distinguishing it from search tools.
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 frames the tool as a lookup table for valid country and region filter values, giving clear context for when to use it. It does not mention alternative tools or exclusions, but the purpose is well-defined.
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.
| 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. | |
| country | No | ISO 3166-1 alpha-2 country code filter (e.g. US). Exact match. 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and idempotentHint annotations, description details token matching (AND, partial words), ranking (operational/larger first), and closed airport exclusion (with include_closed override). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs, front-loaded with primary action, every sentence adds unique value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and output schema, description covers search logic, default exclusion, ranking, and chaining to ourairports_get_airport. Complete for a contextual search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value: explains query AND-matching, country/region code discovery via sibling tool, and why closed airports are excluded by default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the OurAirports corpus by free-text and facets, specifying resource and action. It distinguishes from siblings like ourairports_find_airports for nearest airports.
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 guidance: when to use (search by text/facets), when not (nearest airports -> use ourairports_find_airports), and references ourairports_list_countries for code discovery.
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!