The Aviation MCP server integrates real-time aviation data, specifically allowing you to retrieve NOTAMs (Notices to Airmen) with extensive filtering capabilities:
Filter by ICAO or domestic location, optionally within a specified radius
Filter by NOTAM type (New, Replaced, Canceled), number, or classification (International, Military, Domestic)
Filter by feature type (e.g., RWY, AD, AIRSPACE, NAV)
Apply temporal filters with effective start/end dates and last updated dates
Specify location using latitude/longitude coordinates
Sort results by various fields in ascending or descending order
Paginate results with customizable page size and number
Request data in different formats: AIXM, GeoJSON, or AIDAP
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Aviation Model Context Protocol get METAR for KLAX"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Aviation MCP provides a suite of Model Context Protocol (MCP) servers that map to FAA and other aviation APIs, making it easy to integrate real-time aviation data into your LLM-powered workflows. This project is designed for developers who want to connect their LLM clients (such as Cursor, Claude, or others) to authoritative aviation data sources for weather, NOTAMs, charts, aircraft info, and more.
⚠️ Disclaimer ⚠️
The developer of this code is not responsible for the correctness or safety of the APIs providing data, or your flight planning for your particular flight. This applies to both the software and the instructions in FlightPlanning.md, which do NOT substitute for the expertise of an appropriately licensed pilot. The pilot in command is solely responsible for the safety of flight and compliance with all relevant regulations.
Modular MCP servers for aviation data
Integrates with FAA, Aviation Weather, and other APIs
Easy configuration for use with any MCP-compatible LLM client
Published as an npm package: aviation-mcp
Related MCP server: Aviation MCP Server
Add the aviation-mcp server to your mcp.json like so. Make sure to update the keys to contain valid values (visit https://api.faa.gov/s/ for FAA API client creds, https://api-ninjas.com/ for their API keys) or remove them (and the relevant APIs will be hidden).
Aviation Weather (including lots of geo-referenced data) and Charts do not need any API keys. NOTAMs require an FAA client id/secret.
{
"mcpServers": {
"aviation": {
"command": "npx",
"args": [
"-y",
"aviation-mcp"
],
"env": {
"API_NINJA_KEY": "<your-key>",
"FAA_CLIENT_ID": "<your-id>",
"FAA_CLIENT_SECRET": "<your-secret>"
}
}
}
}weather: Aviation weather data (METAR, TAF, PIREP, SIGMET, G-AIRMET, etc.)
charts: Sectional, TAC, IFR enroute, and TPP charts
notam: FAA NOTAM API
These sources would be helpful, but the integration or API access is not yet working:
precipitation: FAA EIM Weather Proximity API (precipitation data)
airports: FAA airport and runway information
delays: The ASWS FAA API provides information about airport delays.
aircraft: Aircraft data
Procedure routes in a machine-readable format. TODO: Download CIFP data and use something like arinc424 to transform it into a usable format.
Airspace data in a machine-readable format. TODO: Download NASR data and use a library to read shapefiles and/or AIXM data.
Once configured, your LLM client can connect to the MCP servers and query aviation data as needed. Refer to your client's documentation for details on supplying the mcp.json config.
See FlightPlanning.md for a sample system prompt to be used for flight planning.
For temporal awareness, I recommend combining with time.
For EFB management, consider combining with filesystem or gdrive.
For a detailed list of supported APIs, endpoints, and integration status, see Sources.md.
MIT
Retrieves NOTAMs based on specified filters
| Name | Required | Description | Default |
|---|---|---|---|
| classification | No | The NOTAM classification | |
| domesticLocation | No | The domestic location criteria (e.g., 'IAD' for Dulles International Airport) | |
| effectiveEndDate | No | The effective end date | |
| effectiveStartDate | No | The effective start date | |
| featureType | No | The feature type filter | |
| icaoLocation | No | The ICAO location criteria (e.g., 'KIAD' for Dulles International Airport) | |
| lastUpdatedDate | No | The last update date | |
| locationLatitude | No | The location latitude (e.g., 60.57) | |
| locationLongitude | No | The location longitude (e.g., -151.24) | |
| locationRadius | No | The location radius in nautical miles (max: 100) | |
| notamNumber | No | The NOTAM number (e.g., 'CK0000/01') | |
| notamType | No | The NOTAM type: 'N' for New, 'R' for Replaced, 'C' for Canceled | |
| pageNum | No | The page number | |
| pageSize | No | The page size (max: 1000) | |
| responseFormat | No | Response format for NOTAM data | geoJson |
| sortBy | No | The field to sort results by | |
| sortOrder | No | The sort order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states retrieval with filters. It lacks behavioral details like pagination handling (implied by pageNum/pageSize but not explained), rate limits, authentication needs, or response format implications (e.g., geoJson output). This leaves significant gaps in understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and scope without unnecessary words. It's appropriately sized for its purpose, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 17 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address behavioral aspects like pagination, response formats, or error handling, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no extra meaning beyond implying filters exist, which the schema already details. Baseline 3 is appropriate as the schema handles parameter semantics effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('NOTAMs'), with scope ('based on specified filters'). It's specific about the action and subject matter, though without sibling tools to differentiate from, it can't achieve the highest score for sibling differentiation.
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?
No guidance is provided on when to use this tool, such as scenarios or prerequisites. The description mentions filters but doesn't explain their application or alternatives, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_notamsWith only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'get_notams' has a clear, distinct purpose focused on retrieving NOTAMs.
The tool name 'get_notams' follows a clear verb_noun pattern (get + notams). Since there is only one tool, consistency is inherently perfect with no deviations or mixed conventions.
The server has only one tool, which feels thin for a domain like aviation that typically involves multiple operations such as querying weather, flight plans, or airspace data. This minimal toolset limits functionality and suggests an incomplete surface.
The toolset is severely incomplete for an aviation context. It only provides NOTAM retrieval, with no coverage for other essential aviation data like METARs, TAFs, flight tracking, or airspace information, leading to significant gaps in agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Aviationstack MCP — global flight + airport + airline data
350+ production-ready APIs through one MCP server — weather, geocoding, validation, financial data.
Live flight prices and working booking links for AI agents and travel apps.
Flight search & booking for AI agents. 400+ airlines, $20-50 cheaper than OTAs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/blevinstein/aviation-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
