Bts Ontime

@pipeworx/bts-ontime

美国国内航空公司的准点表现和延误原因：按航线、航空公司和到达机场统计的月度准点率、平均到达延误、取消、备降，以及按原因（航空公司、天气、空中交通管制/NAS、安保、前序航班延误）细分的延误分钟数。Fleet #2953。

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

工具

• route_ontime(origin, dest, carrier?, months?) — 单条出发地->目的地航线的月度准点表现，可选按一家 航空公司筛选。每个月包含航班数、已完成航班数、准点到达数 和准点率、平均到达延误、取消、备降，以及按原因细分的延误 分钟数。
• carrier_ontime(carrier, airport?, months?) — 相同的月度数据结构， 按一家航空公司的整个航线网络汇总（或仅统计涉及某个机场的 航班）。
• bts_airport_delays(airport, year?, month?, limit?, offset?) — 按航空公司细分的延误原因数据，统计到达某个机场的航班， 可选按年份和/或月份筛选。limit 默认为 50（最大值 200）；如果匹配行数超过返回的行数，响应会包含 truncated: true 和 total_matching，而不会悄悄丢弃数据。
• delay_causes(year, carrier?, airport?, limit?, offset?) — 相同的 延误原因数据，优先按年份整理，便于扫描某一年内多个航空公司 或机场的数据。分页方式与 bts_airport_delays 相同，使用 limit/truncated/total_matching。
• list_coverage() — 实际加载数据的最早和最晚月份，以及加载时间。 如果不确定某个时段是否有数据，先调用此工具。

Carrier 接受 2 个字母的报告航空公司代码（"DL"）或常见航空公司 名称（"Delta"）。机场代码会根据实际加载的数据进行验证（而非静态列表）——无法识别的代码会被明确拒绝并返回清晰的错误，而不会返回空结果。

身份验证

无需密钥。工具只能通过持有数据的 Pipeworx 网关提供响应；单独执行 npm install 后没有可读取的数据，且每个工具都会明确抛出 "not bound in this runtime" 错误，而不会返回空列表。

数据来源

• 美国交通部交通统计局（BTS），TranStats — “Reporting Carrier On-Time Performance” 月度批量数据。美国联邦政府作品：属于公有领域（17 U.S.C. §105）。该机构仅发布批量文件（不提供此数据集的实时查询 API），因此本工具包会构建一份副本（scripts/bts-ontime/load-data.mjs），而非进行代理——不会存储原始航班级数据行（约 60 万行/月）；加载器会将每个月的数据汇总到两个小表中，并在处理下一个月之前丢弃原始文件。

delay_cause 是什么，不是什么

BTS 另行发布自己的 “Airline Delay Cause” 产品，会通过一种本工具包未重新实现的方法，将每个延误航班的延误分钟数按原因分配为小数形式的计数。这里的 delay_cause 表来自与 route_month 相同的底层逐航班延误分钟数字段（carrier/weather/NAS/security/late-aircraft），按 carrier x 到达机场 x 月份汇总，报告的是分钟数总和，而不是小数形式的计数。它与 BTS 自行发布的原因细分数据一致，但不保证逐行匹配——这是对单一原始数据源进行的一条处理流程，并非再次下载 BTS 自己的汇总数据。

已知缺口 — 扩展此数据包前请先阅读

数据覆盖范围截至加载时的最近几个月，并非完整历史数据。 BTS 的批量文件服务器会严格限制每个连接的速度——实测下载一个文件约需 170 秒，无论适度提高并发量是否有帮助（实测于 2026-10-12，同时下载此上游的 3 个文件与串行下载 1 个文件，耗时大致相同），因此一次性拉取 1987 年至今的完整存档（400 多个月度文件）需要数小时，不适合作为构建数据包的步骤。首次加载覆盖截至 2026-10-12 最近 12 个月的数据（调用 list_coverage 可查看准确范围），并且涵盖两个表——此提交中，delay_cause 没有单独回填 2003 年至今的数据；它与 route_month 取自相同月份。

扩展覆盖范围是机械性操作，无需研究——请参阅下文“刷新或扩展数据”。重新运行加载器并设置更大的 --months 值（以及将 --concurrency 调整到对上游服务器较为友好的程度），即可拉取更早的数据；架构和工具均无需更改。

刷新或扩展数据

node scripts/bts-ontime/load-data.mjs --months 12                 # default: most recent 12 months
node scripts/bts-ontime/load-data.mjs --months 36 --concurrency 4 # extend further back
node scripts/bts-ontime/load-data.mjs --through 2026-7            # pin the "latest" month instead of probing

需要登录 Pipeworx Cloudflare 账户的 wrangler。每次运行都会替换 route_month、delay_cause 和 bts_ontime_meta（先 DROP，再重新加载），而不是追加数据——BTS 自己的月度文件偶尔也会修订，因此完整重新加载才是确保已撤回或修正文件中的过期行不会残留的唯一方法。每月刷新（BTS 发布数据的延迟约为 2 个月）时，应重新运行此命令，并设置足够大的 --months 值以覆盖上次加载以来的时间段，而不只是 12；否则，之前加载的最早几个月份会悄然超出覆盖范围。

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/bts-ontime/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、discover_tools、search_within、remember/recall，以及网关全局工具集中的其他工具。因此，你看到的工具数量会多于此表所列：目前，单数据包端点除了该数据包自身的工具外，还会列出约 30 个共享工具。连接的 initialize 响应会说明其确切范围，并且是当天范围的权威信息。

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

或者，连接完整的 Pipeworx 网关，直接列出所有数据包的工具，而不只是此数据包的工具：

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

两个 URL 都会连接到同一个网关和相同的 1779+ 个数据源。唯一的区别是直接列出哪个数据包的工具；无论连接哪个端点，ask_pipeworx 都能访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/route_ontime \
  -H 'Content-Type: application/json' \
  -d '{"origin":"JFK","dest":"LAX","months":3}'

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

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

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

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

或者直接运行，确认服务能够启动：

npx -y @pipeworx/mcp-bts-ontime

它通过 stdin/stdout 进行 MCP 通信，并响应 initialize/tools/list/tools/call，只提供此数据包的工具——不包含上述网关连接额外提供的共享元工具。来源相同，工具相同，但不支持 ask_pipeworx 路由。

使用 ask_pipeworx

你也可以用通俗英语提问，而非直接调用工具——此功能既适用于上面的数据包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Bts Ontime data" })

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

More

• Docs and guides
• pipeworx.io

License

MIT