Aviation MCP 提供了一套模型上下文协议 (MCP) 服务器，可映射到 FAA 和其他航空 API，从而轻松地将实时航空数据集成到您的 LLM 工作流程中。该项目专为希望将其 LLM 客户端（例如 Cursor、Claude 或其他客户端）连接到权威航空数据源（例如天气、航行通告、图表、飞机信息等）的开发者而设计。
⚠️ 免责声明 ⚠️
本代码的开发者不对提供数据的 API 的正确性或安全性负责，也不对您的特定航班的飞行计划负责。此规定适用于FlightPlanning.md中的软件和说明，它们不能替代持有适当执照的飞行员的专业知识。机长对飞行安全及所有相关法规的遵守负全部责任。
用于航空数据的模块化 MCP 服务器
与 FAA、航空天气和其他 API 集成
轻松配置，可与任何兼容 MCP 的 LLM 客户端一起使用
作为 npm 包发布： aviation-mcp
Related MCP server: Aviation MCP Server
将 Aviation-mcp 服务器添加到你的 mcp.json 文件中，如下所示。请确保更新密钥以包含有效值（访问https://api.faa.gov/s/获取 FAA API 客户端凭证，访问https://api-ninjas.com/获取其 API 密钥），否则请移除密钥（相关 API 将被隐藏）。
航空天气（包括大量地理参考数据）和图表不需要任何 API 密钥。航行通告 (NOTAM) 需要 FAA 客户端 ID/密钥。
{
"mcpServers": {
"aviation": {
"command": "npx",
"args": [
"-y",
"aviation-mcp"
],
"env": {
"API_NINJA_KEY": "<your-key>",
"FAA_CLIENT_ID": "<your-id>",
"FAA_CLIENT_SECRET": "<your-secret>"
}
}
}
}天气：航空气象数据（METAR、TAF、PIREP、SIGMET、G-AIRMET 等）
图表：分区图、TAC图、IFR航路图和TPP图
航行通告：FAA 航行通告 API
这些来源会有所帮助，但集成或 API 访问尚未起作用：
降水：FAA EIM 天气接近度 API（降水数据）
机场：FAA机场和跑道信息
延误：ASWS FAA API 提供有关机场延误的信息。
飞机：飞机数据
以机器可读格式编写程序路线。TODO：下载 CIFP 数据，并使用类似arinc424的工具将其转换为可用格式。
机器可读格式的空域数据。待办事项：下载 NASR 数据并使用库读取 Shapefile 和/或 AIXM 数据。
配置完成后，您的 LLM 客户端即可连接到 MCP 服务器并根据需要查询航空数据。有关如何提供mcp.json配置的详细信息，请参阅客户端的文档。
请参阅FlightPlanning.md了解用于飞行计划的示例系统提示。
对于时间意识，我建议与时间相结合。
有关受支持的 API、端点和集成状态的详细列表，请参阅Sources.md 。
麻省理工学院
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.
v1.0.0get_notamsScored across 1 tool
With 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.
Aircraft intelligence for AI agents: valuations with uncertainty bands, FAA registry lookups, cost of ownership, comparable aircraft, fleet search, airworthiness directives and STCs, market metrics and forecasts, verified value reports, pre-buy diligence checklists, logbook search and a watchlist. 38 tools; free tier with OAuth or a Windsock API key.
Aviationstack MCP — global flight + airport + airline data
Aviation identity resolution and an AI use-case atlas, with provenance and temporal validity
350+ production-ready APIs through one MCP server — weather, geocoding, validation, financial data.
