Pbgc

PBGC — 养老金计划终止与保费申报

查询某个具名养老金计划是否已终止并由联邦养老金保险机构接管（托管），或仍为正常运作、目前正在缴纳保费的计划——涵盖单一雇主和多雇主计划，数据来自监管机构自己的名册。

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

为什么它与 form5500 并存

form5500 显示计划每年向劳工部提交了哪些申报——发起方、参与者、资产。但它不会说明计划后来发生了什么。本工具包回答这个问题：PBGC 是否因计划资金不足而终止计划并接管，还是计划仍在正常运作并缴纳保费。这两个名册（托管计划和缴费申报计划）从设计上互不重叠——每个计划只会出现在 PBGC 自己名册中的一个，绝不会同时出现在两个名册中。

工具

工具	回答的问题
pbgc_plan_status	[发起方] 的养老金计划是否被 PBGC 接管？ — 搜索两个名册并报告匹配结果
pbgc_search_trusteed_plans	PBGC 在伊利诺伊州接管了哪些养老金计划？
pbgc_search_premium_filers	哪些养老金计划由 Delta Air Lines 发起？ — 仍在正常运作
pbgc_industry_totals	PBGC 接管了多少个养老金计划？ — 全国或按州统计

身份验证

无需密钥。

数据来源

• Pension Benefit Guaranty Corporation (PBGC)，托管计划名册——PBGC 因计划终止且资金不足而接管并担任受托人的单一雇主养老金计划。
• Pension Benefit Guaranty Corporation (PBGC)，保费申报名册——目前正在缴纳 PBGC 保费的单一雇主和多雇主养老金计划（尚未终止）。

PBGC 以定期更新的开放政府数据下载文件发布这些数据，而不提供查询 API——其自有计划搜索页面是服务端渲染的 HTML，背后没有 JSON 后端。路由仅存在于 scripts/ingest-pbgc.mjs 中。

为什么这是镜像，以及替换语义的重要性

PBGC 将每份名册作为完整的当前快照发布，而不是增量数据——没有“自上次以来发生了哪些变化”的数据流。scripts/ingest-pbgc.mjs（由 .github/workflows/pbgc-refresh.yml 每周定时运行）会为写入的每一行添加本次运行的 data_as_of，然后删除同一张表中上次运行遗留的所有行。这对保费申报计划尤其重要：停止缴纳保费的计划（因为已终止、合并或被 PBGC 接管）必须从 pbgc_search_premium_filers 和 pbgc_plan_status 中实际消失，而不能一直残留并被误读为仍在正常运作。

每个工具响应都包含 data_as_of，原因正在于此——两个名册的更新时间不同（托管计划名册大约每季度更新一次，保费申报名册大约每月更新一次），因此调用方在比较某个计划在两个名册中的状态时，应了解两部分数据分别来自哪个快照。

架构

supabase/migrations/262_pbgc.sql — pbgc_trusteed_plans（每个托管案例一行；由于 PBGC 自己的名册只增不减，此表只会增长）和 pbgc_premium_filers（每个当前申报计划一行，以 plan_type + plan_id 为键，每次刷新时整体替换）。

数据规模（根据实时数据源验证，2026-10-17）

托管计划	自 PBGC 于 1974 年成立以来，约有 5,180 个单一雇主案例
保费申报计划 — 单一雇主	约有 21,400 个正常运作的计划
保费申报计划 — 多雇主	约有 1,290 个正常运作的计划

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/pbgc/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 都连接到同一个网关和相同的 1837+ 个数据源。唯一的区别是直接列出哪个工具包的工具；通过任一端点，ask_pipeworx 都能访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/pbgc_plan_status \
  -H 'Content-Type: application/json' \
  -d '{"sponsor":"US Airways"}'

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

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

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

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

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

npx -y @pipeworx/mcp-pbgc

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

使用 ask_pipeworx

你可以用通俗的英文提问，而不是直接调用工具——这既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Pbgc data" })

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT