Ntsb Investigations

@pipeworx/ntsb-investigations

NTSB 航空事故/事件调查，可按飞机注册号（机尾编号）或制造商/型号搜索。每条匹配结果均返回 NTSB 编号、事件日期、地点、伤亡级别、飞行阶段/事件类型、可能原因、调查发现，以及 NTSB 案卷链接。

属于 Pipeworx 的一部分——这是一个 MCP 网关，可将 AI Agent 连接到 1721+ 个实时数据源。这是一个独立的非官方集成，与上游提供方无关联、未获其认可，也未由其发布。

工具

• ntsb_search_investigations({ registration?, make?, model?, year?, state?, limit? }) — 必须提供 registration 或 make。model 可在指定制造商范围内进一步筛选（按前缀匹配 “172”、“172S”、“172N”……）。year 按事件年份筛选；如果某个 N 编号曾被重新分配给不同飞机，也可用它缩小注册号匹配范围（见下文）。有匹配结果时返回 { found, data_as_of, source, count, query, results[] }；没有匹配结果时返回 { found: false, data_as_of, source, query }。

身份验证

无需密钥。无需上游账户或 API 密钥。

数据源

• https://data.ntsb.gov/avdata — NTSB 自有的 eADMS 航空事故数据库（avall.zip，Microsoft Access .mdb 批量文件；已确认在 2026-10-07 可访问，压缩后约 96 MB / 解压后约 561 MB）。这是完整的最新数据集，与 CAROL 航空搜索查询的数据完全相同，NTSB 正是为此用途提供该批量文件。
• https://data.ntsb.gov/Docket/?NTSBNumber=NNN — 给定 ntsb_number 对应的 NTSB 案卷页面，其中发布了最终报告和支持文件。已确认真实案例（取自同一数据集）的页面可访问（HTTP 200）。

为什么不使用 CAROL 自身的搜索，或更新的开发者 API

我们首先测试了 CAROL（data.ntsb.gov/carol-main-public），这是 NTSB 的现代搜索界面。其 JSON 端点（api/Query/Main、api/Query/FileExport）没有文档说明；从公开的第三方 CAROL 代理和 NTSB 自己的 CAROL-Guide.pdf 逆向推断出的所有 QueryGroups/QueryRules 请求格式，均返回 HTTP 500（“An unknown exception occured.” / “An error has occurred.”）。前端没有提供可在不使用开发者工具的情况下查看的架构信息，服务器也没有说明它要求的格式为何与真实浏览器会话发送的格式不同（可能是 CAROL 自身的 JS 在首次查询前设置了服务器端会话/防伪要求）。

NTSB 还在 developer.ntsb.gov 提供较新的 REST API（通过 Azure API Management 网关提供 Aviation / Safety Recommendations / Data Dictionary API）。该门户要求先注册开发者账户并订阅密钥，之后才能成功调用——这是一道身份验证门槛。根据本仓库一贯的规则，在未单独决定使用密钥之前，绝不绕过这种门槛；而本工具包实际读取的是无需身份验证的公开批量文件。

刷新数据

node mcps/ntsb-investigations/scripts/refresh.mjs [--local-mdb <path>] [--dry-run] [--r2-mode auto|api|wrangler] [--shard-max-bytes <n>]

下载 avall.zip，解压后，对五个表（aircraft、events、narratives、Findings、Events_Sequence、eADMSPUB_DataDictionary）运行 mdb-export（mdbtools — brew install mdbtools / apt install mdbtools），将它们合并为一个按飞机划分的扁平案例列表，然后将其分片存入共享的 pipeworx-datasets R2 存储桶（与 mcps/indiana-code、mcps/illinois-code、mcps/crs-reports 使用同一存储桶 — 参见 scripts/lib/statute-store.mjs），而不是写入单个对象：

• ntsb/by-make/<slug>.json — 每个制造商对应一个数组。如果某个制造商的扁平分片超过约 4 MB（本次拉取中只有 CESSNA），则进一步拆分为 ntsb/by-make/<slug>/<year>.json。
• 行数少于 5 的制造商（约 4,174 个不同的原始 acft_make 字符串中的大多数都是 OCR／数据录入变体，并非真正不同的制造商）会按稳定哈希汇集到 16 个 ntsb/by-make/_other/<bucket>.json 分片中，而不是每个都单独存为一个小文件。
• ntsb/by-registration.json — 将规范化后的注册号映射到其对应的 (make, year)，这样注册号查询无需完整扫描即可知道要读取哪些分片。
• ntsb/manifest.json — 包含 data_as_of、source、record_count，以及每个制造商的准确分片结构（flat / by_year + 对应年份 / bucket），因此读取路径无需探测 R2，就能知道某个制造商的数据位于哪个键下。

此前的设计是将所有数据存为单个对象（ntsb/aviation-cases.json，约 27 MB），每次调用都会重新获取并解析整个数据集，且没有缓存 — 两个并发调用会在同一个 isolate 中同时保留两份完整解析结果。现在，src/index.ts 会读取清单以及每次查询所需的确切分片（制造商／型号查询读取一个分片；注册号查询读取该注册号对应的、去重后的 (make, year) 配对所解析出的少量分片），绝不会读取旧的单体文件；该脚本会在分片上传后将其从存储桶中删除。我们有意不使用模块级缓存 — 参见 src/index.ts 中的头部注释。无需迁移 Supabase；数据仅存储在 R2 中。--local-mdb 会复用已下载的 avall.mdb，而不是重新拉取 96 MB 数据。每个响应中的 data_as_of 表示上次运行刷新脚本的日期，并非上游数据中的逐条记录字段。

注册号（N 号）的重复使用

FAA 会随着时间推移，将机尾编号重新分配给不同的飞机。ntsb_search_investigations({ registration }) 不会悄悄合并这些记录：该机尾编号的每条历史匹配结果都会返回，每条结果都包含自己的 event_date、make 和 model。如果同一注册号对应多个结果，可传入 year，将结果缩小到其中一次使用记录。

常见制造商可能需要缩小查询范围

少数常见制造商（本次拉取中的 CESSNA）数据量足够大，因此按年份拆分为多个分片。查询这类制造商时，如果既不指定 model 也不指定 year，就必须读取该制造商的所有年度分片才能作答 — 这不是对整个数据集的完整扫描，但也不像其他查询那样只需读取一两个小对象。超过一个较小的固定年度分片数量后，该工具会拒绝查询并提示指定 year（或 model；指定 model 不会改变要读取的分片，只是缩小查询范围），而不会悄悄执行更大的读取。按制造商／型号／年份组合查询，或单独查询不常见的制造商，则不受影响。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "ntsb-investigations": {
      "url": "https://gateway.pipeworx.io/ntsb-investigations/mcp"
    }
  }
}

此端点实际提供的内容

tools/list 在 https://gateway.pipeworx.io/ntsb-investigations/mcp 返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、 discover_tools、search_within、remember/recall 和网关范围内的其他工具。因此，你看到的工具数量会多于此表中的数量：单个工具包端点目前会列出大约 30 个共享工具，以及该工具包自身的工具。连接的 initialize 响应会说明其确切范围，并且是当天情况的权威答案。

这是有意为之，并非意外的多路复用。元工具让作用域受限的连接也能回答本工具包未涵盖的问题——通过 ask_pipeworx 在整个目录中路由——无需添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点；如果额外的架构定义消耗的上下文超过路由带来的价值，请连接一次完整网关，而不是连接多个工具包端点。

或者连接完整的 Pipeworx 网关，直接列出每个工具包的工具，而不只是此工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都会连接到同一个网关和相同的 1721+ 个数据源。唯一的区别是直接列出哪个工具包的工具；从任一端点都可以通过 ask_pipeworx 访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/ntsb_search_investigations \
  -H 'Content-Type: application/json' \
  -d '{"make":"Cessna","model":"172","year":2024,"limit":10}'

首次调用无需账户。检查任意工具：GET https://gateway.pipeworx.io/v1/tools/ntsb_search_investigations。查找工具：使用 {"query":"..."} 向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求。

独立运行（无需网关账户）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账户，也无需往返网关：

{
  "mcpServers": {
    "ntsb-investigations": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-ntsb-investigations"]
    }
  }
}

或者直接运行，确认它可以启动：

npx -y @pipeworx/mcp-ntsb-investigations

它通过 stdin/stdout 使用 MCP 通信，并且仅对该工具包的工具响应 initialize/tools/list/tools/call——不包含上文网关连接额外提供的任何共享元工具。源代码相同，工具相同，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗英语提问，而不是直接调用工具——上述工具包端点和完整网关都支持此功能：

ask_pipeworx({ question: "your question about Ntsb Investigations data" })

网关会选择合适的工具，并自动填入参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT