@pipeworx/sec-13f

Connect: https://gateway.pipeworx.io/sec-13f/mcp · Install: one-click buttons

Tools: 3

Institutional ownership from SEC Form 13F, asked security-first. Hosted, keyless to the caller.

Tools

• who_owns(security, limit?) — which managers hold a security, ranked by position size. Accepts a company name, a ticker-ish string or a 9-character CUSIP.
• manager_portfolio(manager, limit?) — every position one manager reported, largest first.
• holdings_coverage() — which SEC release is loaded, how many filings and holdings, which quarter.

Why this is hosted rather than proxied

The ingest program only accepts a hosted copy when it makes a question possible that the upstream cannot answer. This is the clean case: the SEC publishes 13F manager-first, and so does every API over it. Our own edgar_institutional_holdings says so in its description — answering “which funds hold $TICKER” means running it once per manager, a loop over ~8,000 filers. That is a shape problem, not a rate-limit problem, and no upstream fixes it. One indexed query over the flat table inverts it.

What 13F does not tell you

Stated here and in every response, because 13F is routinely over-read:

• Long US-listed equity only. Shorts, cash, bonds and non-US holdings are excluded by rule. “How much does X own” is answerable only inside that universe.
• Quarterly, and late. Filed up to 45 days after the period end. It is a lagged snapshot, never a current position.
• $100M floor. A manager under that threshold does not file at all, so absence is not evidence.
• No ticker column. CUSIP is the only identifier of record; issuer names are as the filer typed them (“NVIDIA CORP”). A ticker search falls back to an issuer-name match and says so in matched_on.

One thing the numbers depend on

A single manager can report the same security on several lines — different investment discretion, or puts and calls alongside the common. who_owns collapses lines per manager before ranking. Without that you get the largest lines rather than the largest holders, which is a different list that looks equally plausible.

Data + refresh

Source: https://www.sec.gov/data-research/sec-markets-data/form-13f-data-sets — one rolling 3-month ZIP carrying seven TSVs. We ingest three: SUBMISSION (accession → CIK), COVERPAGE (accession → manager) and INFOTABLE (the holdings, ~3.8M rows/release, 396MB uncompressed).

The filename encodes its window (01mar2026-31may2026_form13f.zip) and is not derivable — releases do not land on calendar quarters. Both the worker config and the script read SEC’s index page for the newest link; a hardcoded quarter would ingest once and serve stale data forever.

• Standing path: workers/data-pipeline (sec-13f-submissions, sec-13f-managers, sec-13f-holdings).
• Backfill / recovery: node scripts/ingest-sec-13f.mjs --only holdings.
• Freshness: registered in shared/src/freshness.ts at a 200-day SLA — release cadence plus the ~45-day filing lag, so a missed release trips it within a quarter.

Schema and indexes: supabase/migrations/061_sec_13f.sql. The (cusip, value_usd DESC) index is what makes the inversion viable; without it this is a 3.8M-row sequential scan and the hosted copy is slower than the API it replaced.

Tools

• who_owns — Which institutional managers hold a given US-listed security, ranked by position size — the reverse of every 13F API, which requires you to name the manager first. Give a company name, ticker or CUSIP
• manager_portfolio — Every 13F position reported by one institutional manager, largest first — the classic manager-first view, over the same hosted table. Give the manager name (“Berkshire Hathaway”, “Pershing Square”). R
• holdings_coverage — What this 13F dataset currently covers: the SEC release window loaded, how many filings and holdings are in it, and the reporting quarter. Use to check freshness before relying on an ownership answer.