@pipeworx/pbgc

Connect: https://pipeworx.io/mcp — every tool in the catalog, including @pipeworx/pbgc’s. Install: one-click buttons

No MCP client? Skip the connection: POST https://gateway.pipeworx.io/v1/tools/search_packs {"query":"..."} to find a tool below, GET /v1/tools/<name> for its schema, POST the same URL with arguments for the data — see For AI agents.

Tools: 4

Whether a named pension plan was terminated and taken over by the federal pension insurer (trusteed), or is still an active plan currently paying its premiums — single-employer and multiemployer, from the regulator’s own registers.

Why this exists alongside form5500

form5500 shows what a plan FILED with the Department of Labor each year — sponsor, participants, assets. It does not say what happened to the plan afterward. This pack answers that: did PBGC take it over because it terminated underfunded, or is it still active and paying premiums. The two registers (trusteed vs. premium-filer) are disjoint by construction — a plan is in exactly one of PBGC’s own rosters, never both at once.

Tools

Auth

Keyless.

Data sources

• Pension Benefit Guaranty Corporation (PBGC), trusteed-plan register — single-employer pension plans PBGC has taken over as trustee because the plan terminated underfunded.
• Pension Benefit Guaranty Corporation (PBGC), premium-filer rosters — single-employer and multiemployer pension plans currently paying PBGC premiums (not terminated).

PBGC publishes these as periodically-updated open-government downloads rather than through a query API — its own plan-search page is server-rendered HTML with no JSON backend behind it. Routes live only in scripts/ingest-pbgc.mjs.

Why this is a mirror, and the replace semantics that matter

PBGC distributes each register as a complete current snapshot, not a delta — there is no “what changed since” feed. scripts/ingest-pbgc.mjs (scheduled weekly by .github/workflows/pbgc-refresh.yml) stamps every row it writes with that run’s data_as_of and then deletes any row in the same table left over from a previous run. That matters specifically for premium filers: a plan that stops paying premiums (because it terminated, merged, or PBGC took it over) has to actually disappear from pbgc_search_premium_filers and pbgc_plan_status, not linger reading as still-active forever.

Every tool response carries data_as_of for exactly this reason — the two registers refresh on different clocks (the trusteed register roughly quarterly, the premium-filer rosters roughly monthly), so a caller comparing a plan’s status across both should know which snapshot each half came from.

Schema

supabase/migrations/262_pbgc.sql — pbgc_trusteed_plans (one row per trusteed case; this table only grows, since PBGC’s own register does) and pbgc_premium_filers (one row per currently-filing plan, plan_type + plan_id as the key, replaced wholesale on each refresh).

Scale (verified against the live source, 2026-10-17)

Tools

• pbgc_plan_status — Look up a named pension plan sponsor’s PBGC status: whether a pension plan was terminated and taken over by PBGC (“trusteed”) because it was underfunded, or is still an active plan currently paying PB
• pbgc_search_trusteed_plans — Search PBGC’s register of single-employer pension plans PBGC has trusteed — i.e. taken over as trustee because the plan terminated underfunded. Returns case number, sponsor, plan name, EIN, terminatio
• pbgc_search_premium_filers — Search plans currently paying PBGC premiums — active pension plans (NOT terminated/trusteed), single-employer or multiemployer. Returns plan name, sponsor, admin city/state, EIN, plan effective date,
• pbgc_industry_totals — Aggregate counts across PBGC’s registers: how many pension plans PBGC has trusteed (and total participants affected), and how many plans are currently paying premiums (single-employer vs multiemployer