Sec Nport

@pipeworx/sec-nport

来自 SEC Form N-PORT 和 Form N-CEN 的共同基金和 ETF 投资组合持仓及基金简介。无需密钥。

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

工具

• nport_fund_owners(security, quarter?, limit?) — 查看哪些基金和 ETF 持有某只股票或债券，并按持仓规模排序。可传入股票代码、公司名称或 CUSIP。
• nport_fund_portfolio(fund, quarter?, limit?) — 查看某只基金申报的持仓，按规模从大到小排列。
• nport_fund_profile(fund) — 基金简介：ETF/指数/货币市场状态、AUM、费用率、管理费、每股 NAV/市场价格以及投资顾问。从 SEC Form N-CEN（年度基金普查）获取 — 见下文“基金简介”。
• nport_holdings_coverage() — 查看已加载的 N-PORT 和 N-CEN 发布数据、数据的时效性，以及数据未涵盖的内容。

反向查询正是这个工具包的意义所在

在此工具发布前，询问“哪些 ETF 持有规模最大的 NVDA 持仓？”会返回 no_match，路由器也直言不讳地指出了缺口：它必须逐一检查每只 ETF。 edgar_fund_holdings 的查询方向是从基金到持仓。没有从证券到基金的查询，因为 SEC 以申报为中心发布 N-PORT，所有基于它的 API 也如此。这是结构问题，不是速率限制问题。

这不是换个包装的 13F。13F 覆盖的是资产超过 1 亿美元的机构管理人，且仅限美国股票多头。N-PORT 覆盖的是注册基金 — 共同基金和 ETF — 也包括其债券持仓。“哪些基金持有这只公司债券”根本无法通过 13F 查到答案。

范围说明：因为把部分加载的数据当作完整数据，得出的答案就是错的

季度档案共有 32 张表，占用 441MB。已加载的内容包括股票、优先股和债务持仓 — 每季度约 535 万条持仓记录中的 360 万条，涵盖 14,416 只基金。**未加载：**衍生品、贷款、回购协议和结构化产品。互换名义本金不等于对标的资产的持仓；若将其报告为持仓，就像是穿着正确答案外衣的错误答案。每个响应都会在 scope 字段中说明这一点。

每个答案还附带另外两项注意事项：

• **N-PORT 每月申报，但约在季度结束 60 天后才按季度延迟公开。**响应会附带 as_of_period。暗示数据是实时的答案就是错的。
• **N-PORT 没有 ETF 标记。**这些是注册基金，既包括 ETF，也包括共同基金；系列名称是唯一的线索。仅针对 ETF 的答案无法仅凭这份申报如实给出，因此该工具包会说明这一限制，而不会凭空捏造分类。

数据存在哪里，以及为什么不在 R2

所有数据都在 Postgres 中。 在生产数据库上测得，加载一个季度的数据后：

表	行数	磁盘占用
sec_nport_holdings	3,614,371	1,123 MB
sec_nport_funds	14,416	8.9 MB

对于一个数据包来说，这在 Postgres 中确实占了不少空间，因此有必要说明这个选择，而不是留给别人凌晨 3 点再去探究。

查询需求是原因。 这个数据包旨在实现的反向查询——哪些基金持有这只证券——通过 cusip 和 issuer_name 进行选择性查找，从 360 万行中返回几十行。这正是 B-tree 索引的用途：在毫秒内返回结果，而且几乎不会触及这 1.1GB 数据。R2 没有索引。要从对象存储中回答同样的问题，就只能扫描对象，或构建一个指向对象的辅助索引；这比现有数据库更差。

当访问模式是批量读取时，R2 才能发挥作用：读取整个文件、归档无人交互式查询的季度数据，或存储大到无法有效建立索引的数据。之后一个合理的划分方式是热季度数据放在 Postgres，冷季度数据放在 R2——但只有加载了多个季度后，这样做才有意义；而目前恰好只有一个季度。现在就拆分只会增加一个存储层，却省不了任何东西。

明确划分界限，免得后来的人还要猜。 每个季度大约占 1.1GB。加载约 4 到 6 个季度后，这部分数据就会成为数据库中最大的单一占用项，此时就应该着手构建冷季度数据拆分方案，而不是只停留在讨论上。作为对比，sec_13f_holdings 有 380 万行——这个数据包量级相同，并非全新的问题类别。

来自另一份申报文件的基金简介（N-CEN，而非 N-PORT）

nport_fund_profile 回答的问题与另外三个工具不同： 它回答的不是“这只基金持有什么”，而是“这只基金是什么”。它读取 SEC Form N-CEN（年度基金普查），其中包含 N-PORT 持仓申报文件没有的字段：

• 明确的 ETF／交易所交易管理型基金／指数基金／货币市场基金／目标日期基金标志——N-PORT 没有这些信息；系列名称是唯一的线索。
• 费用率（净资产的净年度运营费用百分比）和顾问费——主要为封闭式基金填写；大多数开放式基金和 ETF 的这些 N-CEN 项目为空，该工具会将其报告为 null，而不是 0。
• 投资顾问，包括名称、CRD 编号和 LEI，也包括次级顾问。
• AUM（月平均净资产，或货币市场基金的日平均净资产）以及每股 NAV／市场价格。

它无法回答的问题：成立日期。 N-CEN 的结构化数据集中没有此字段——在构建工具之前，我们已根据 SEC 自身的 53 张表的架构（ncen_readme.pdf）核实过，并非凭空假设。每个响应都会明确说明这一点，而不是省略该字段。

数据可能会有一年时滞的原因。 N-CEN 每年申报一次，每只基金在每个财政年度申报一次。SEC 仍按季度发布结构化数据，因为各基金的财政年度结束时间分散在全年——单个发布季度只涵盖财政年度在该时间段内结束的基金（根据当前的 2026q3 发布数据，约 9,000 至 10,000 只活跃基金中有 2,330 只）。摄取脚本会加载最近四个季度的数据，以近乎完整地覆盖单个年度。每个响应中的 report_ending_period 都是该基金自身的财政年度结束日期，而非当前日期。

以单位投资信托（SPY、QQQ、DIA）形式设立的 ETF 也在覆盖范围内，通过单独的 N-CEN 部分提供数据。 UIT 通过 N-CEN 的 Part F／UIT.tsv 表（EXISTING_SERIES_CNT、TOTAL_ASSET_FOR_ALL_SERIES，仅按 accession 编号关联，不含逐系列记录）报告基金层级数据，而不是通过 Part C/D 的 FUND_REPORTED_INFO.tsv 报告。nport_fund_profile 会先尝试 Part C/D，如果没有匹配结果，再回退到 UIT 表——已通过 SPDR S&P 500 ETF Trust（SPY，CIK 884394）的实时数据核实：其 2026 年申报（accession 0001410368-26-023904）不含任何 FUND_REPORTED_INFO 记录，但 UIT.tsv 中有一条记录，报告 TOTAL_ASSET_FOR_ALL_SERIES 为 $712,072,540,255.17。UIT 简介会返回 fund_type: "unit investment trust"、总资产和 administrators（UIT 通常没有投资顾问——它由被动管理方管理），但不会提供费用率、顾问费或 NAV／市场价格，因为 Part F 根本不报告这些项目；每个 UIT 响应都会通过 uit_profile_note 说明这一点。其 N-PORT 持仓则由 nport_fund_portfolio／nport_fund_owners 单独完整覆盖（已通过实时数据确认：SPY 存在于 sec_nport_funds 中，注册机构名称为 “State Street(R) SPDR(R) S&P 500(R) ETF Trust”）。

名称匹配会分级处理，绝不会静默猜测。 系统会针对 fund_name 使用 ILIKE '%query%' 在较大的候选池中查找，再由客户端排序——标准化标点和 “ETF”／“Trust”／“Fund” 等通用后缀后，精确匹配优先于前缀匹配，前缀匹配优先于普通子串匹配。响应始终包含 name_match；如果匹配等级不是 exact，还会包含 name_match_note 和 other_candidates（每个候选项都附有自身的匹配等级），因此不会在不作说明的情况下将包含匹配结果当作目标基金呈现。此前，排序会回退到 report_ending_period 最新的 ILIKE 候选项，这可能会（也确实会）选中同一系列中无关的基金，而不是用户实际指的那只。

Ticker 解析

持仓表以 CUSIP 为键，而 CUSIP 归 CUSIP Global Services 所有，因此本工具包不会构建或缓存批量 CUSIP↔ticker 对照表。外形类似 ticker 的输入会通过 OpenFIGI（采用开放许可的 Bloomberg FIGI）实时解析为规范公司名称，然后与我们已摄取数据行中的 issuer_name 匹配——优先选择不是 ETF 或期权包装产品的候选项，否则“NVDA”会同时匹配 Direxion Daily NVDA Bull 2X 和 NVIDIA，并将它们排在一起。这与 13F 工具包采用的是同样审慎的做法。

来源

SEC Form N-PORT 结构化数据（持仓）和 SEC Form N-CEN 结构化数据（基金概况）——均由美国证券交易委员会发布。

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/sec-nport/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 都连接到同一个网关和相同的 1831+ 个数据源。唯一的区别是直接列出的工具属于哪个工具包；无论连接哪个 URL，都可以通过 ask_pipeworx 访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/nport_fund_owners \
  -H 'Content-Type: application/json' \
  -d '{"security":"NVDA","limit":10}'

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

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

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

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

或者直接运行以确认它能启动：

npx -y @pipeworx/mcp-sec-nport

它通过 stdin/stdout 使用 MCP 协议，并为仅属于此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的共享元工具。来源相同，工具相同，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

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

ask_pipeworx({ question: "your question about Sec Nport data" })

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT