Raul's ask: pass a company, get every fund holding it; pass a fund, get every company it holds; include contact info for the manager on every fund returned. Below is real data in both directions, plus the JSON shape the actual feed would return — not a mockup.
as of 2026‑06‑30, ranked by position value
| Fund | Value |
|---|---|
| Vanguard Group Inc 100 Vanguard Blvd, Malvern, PA 19355 · (610) 669‑1000 ✎ Ashley Grim, Head of Global Fund Administration · (610) 669‑8989 | $417.9B |
| BlackRock, Inc. 50 Hudson Yards, New York, NY 10001 · (212) 810‑5800 ✎ Spencer Fleming, Attorney‑in‑Fact · (212) 810‑5300 | $336.5B |
| State Street Corp | $178.0B |
| Geode Capital Management, LLC | $107.2B |
| FMR LLC | $94.1B |
| Fund | Value |
|---|---|
| Magnetar Financial LLC 1603 Orrington Ave, 13th Fl, Evanston, IL 60201 · (847) 905‑4400 ✎ Hayley Stein, Chief Compliance Officer · (212) 994‑8112 | $5.18B |
| NVIDIA Corp 2788 San Tomas Expy, Santa Clara, CA 95051 · (408) 486‑2000 ✎ Rebecca Peters, VP, Deputy General Counsel · (408) 486‑2000 | $4.70B |
| Vanguard Group Inc | $3.54B |
| BlackRock, Inc. | $2.40B |
| Goldman Sachs Group Inc | $1.80B |
CoreWeave is the more interesting of the two on purpose — a mega-cap like Apple is dominated by the same handful of index managers every time, which is a weak demo. CoreWeave's holder list actually varies by company: NVIDIA shows up as a top-5 holder in its own right (a real strategic stake, not a data error), which is exactly the kind of thing this feed makes visible at a glance.
as of 2026‑06‑30, ranked by position value
| Company | Value |
|---|---|
| AAPL — Apple Inc | $65.95B |
| AXP — American Express Co | $51.28B |
| KO — Coca‑Cola Co | $32.51B |
| GOOGL — Alphabet Inc Cl A | $28.16B |
| BAC — Bank of America Corp | $27.54B |
| Company | Value |
|---|---|
| CRWV — CoreWeave Inc Cl A | $5.18B |
| WBS — Webster Financial Corp | $88.4M |
| KVUE — Kenvue Inc | $88.2M |
| GTLS — Chart Industries Inc | $87.4M |
| NSC — Norfolk Southern Corp | $86.6M |
Magnetar and CoreWeave line up with the company-side example above on purpose — same fund, same stake, both directions of the lookup agreeing with each other, which is the actual correctness bar for a feed like this: query it either way and the numbers have to match.
what the real feed returns, not a mockup — every field below is a real column already in the database
{
"company": { "cusip": "21873S108", "ticker": "CRWV", "name": "COREWEAVE INC-CL A" },
"as_of": "2026-06-30",
"holders": [
{
"fund": {
"cik": 1352851,
"name": "Magnetar Financial LLC",
"manager_type": "broker_dealer",
"contact": {
"address": "1603 Orrington Ave, 13th Floor, Evanston, IL 60201",
"phone": "(847) 905-4400"
},
"signer": {
"name": "Hayley Stein",
"title": "Chief Compliance Officer",
"phone": "212-994-8112"
}
},
"value_usd": 5179700295,
"shares": 52062927
},
… one entry per holder
]
}
The reverse direction (fund → companies) is the mirror shape: a fund object with the same contact block, and a holdings array of company + value + shares instead of holders.
| Piece | Status |
|---|---|
| Company → funds query | Already the shape of an existing query pattern (current_holdings_mat + cusip_mapping), sub-5ms on the covering index. No new build. |
| Fund → companies query | Same table, same index, other direction. No new build. |
| Manager firm address/phone | Extraction logic already exists (detect_duplicate_filers.py's header-metadata pull) but has never been exposed as a served field — it's used internally for entity-dedup evidence, not surfaced to a consumer. Needs promoting into the regular pipeline (pulled once per CIK per filing cycle, cached, not fetched live per request) and adding to the manager-side response. |
| Named signer (officer + direct phone) | New this revision — not extracted anywhere yet, including internally. Lives in the cover-page XML's signatureBlock (name/title/phone), a different document than the SGML header the address/phone pull already reads. Required on every 13F, so expected near-100% coverage. Same promotion path as the address/phone field, one more XML tag to read. |
| JSON API surface | Not built yet. This would ship as two MCP tool specs (thirteenf_company_holders, thirteenf_fund_portfolio), same pattern every other smart_money tool already follows — we write the spec, argos-mcp-server implements. |
Net: the data and the query pattern are not the gap. Surfacing both contact fields (firm address/phone, and now the named signer) as served fields, plus writing the two MCP tool specs, is the actual remaining work — small, not a new data source.