Sec Contracts

@pipeworx/sec-contracts

SEC 文件中的重大合同附件——信贷协议、契约、合并协议、雇佣和离职协议——根据其中的条款措辞查找，而非使用 SEC EDGAR 全文搜索。反向问题是 edgar 无法回答的问题：不是“Adobe 提交了什么文件”，而是“自 2025 年以来提交的哪些信贷协议包含控制权变更条款”。

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

工具

• sec_contracts_search(query, match?, exhibit_type?, form?, since?, until?, company?, sic?, limit?, include_snippets?) — 查找文本中包含指定短语的附件（EX-10 / EX-4 / EX-2，或任意类型）。每份附件文档占一行：公司、CIK、股票代码、根表格类型、提交日期、附件类型及提交方的附件说明、匹配内容附近的片段、文档 URL 和 accession；此外还会提供按文件归类的相同行记录。
• sec_contract_text(url | adsh + filename + cik, max_chars?, offset?, find?) — 分页显示附件的纯文本。find 可跳转到某个短语的首次出现处（例如“控制权变更”定义、“终止费”）。
• sec_contracts_by_company(company, exhibit_type?, form?, since?, until?, limit?) — 按股票代码、名称或 CIK 查找提交方的重大合同，按时间从新到旧排列。

身份验证

无需密钥。SEC 要求每次请求都提供描述性的 User-Agent；此工具包会自动发送。

数据源

• https://efts.sec.gov/LATEST/search-index — EDGAR 全文搜索。索引 2001 年以来申报文件中的每份文档；每条命中均包含 file_type（EX-10.1、EX-4.2、10-K……）、file_description、adsh、ciks、sics、display_names。
• https://www.sec.gov/Archives/edgar/data/{cik}/{accession}/{file} — 展品文档本身。

下一位维护者原本也会重新发现的事项（数据均于 2026-08-28 测得）：

• efts 没有展品类型参数。 forms=EX-10 返回零条结果——forms 筛选的是根表单。展品筛选在客户端基于 file_type 进行，每页多取 100 份文档（每次调用最多 500 份）。前缀测试使用 EX-10(?!\d)，因为存在申报者误写的 EX-103。
• 没有高亮内容。 搜索响应不包含摘要片段。摘要片段通过读取每份匹配展品的前 1.5 MB，并截取短语首次出现处附近的内容生成，每次处理五份文档。
• 只提供一端的 dateRange=custom 会被忽略。 只提供 startdt 而不提供 enddt，会导致筛选条件为空，并返回 2008 年的命中结果。始终同时传入起止日期。
• 未加引号的词会按 AND 关系组合（每个词对应一个 match_phrase 子句）；词之间使用 OR 有效；双引号括起来的短语会精确匹配；q=* 不匹配任何内容。因此，按公司查询的工具会使用合同相关词语组成宽泛的 OR 查询（agreement OR indenture OR amendment …），并添加 ciks 筛选条件。
• 归档 URL 需要使用注册人的 CIK，而不是 accession 前缀。申报代理机构的 accession（0001193125-… = Donnelley）通过代理机构 CIK 路径访问时会返回 503。因此，搜索结果会附带解析出的 cik 和 document_url。
• efts 的响应缓存会在 sics / ciks / entityName 之间泄漏。 该端点位于 API Gateway 缓存之后，缓存键包含 q、日期范围、forms 和 from/page，但不包含 sics、ciks 或 entityName。2026-08-28 测得：sics=7372 请求返回了几秒前为相同 q 和日期缓存的未筛选 10,000 条结果；反向泄漏也会发生（未筛选请求返回仅限软件行业的结果）。响应正文中回显的 query 会显示实际执行了哪些筛选条件。只要设置了其中任意一项筛选条件，该工具包就会在 q 中追加一个取反的无意义词元（-zqfs7372）——efts 会将其编译为不匹配任何内容的 must_not（已验证结果总数完全一致），并使每组筛选条件对应唯一的缓存键；此外，还会逐条重新检查 sic/cik，如果有结果被剔除，则在 note 中报告。任何其他向 efts 传入 ciks/sics 的工具包也会遭遇同样的泄漏。
• 覆盖范围始于 2001-01-01；更早的 since 会被限制到该日期，并在响应中注明。

快速开始

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

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

此端点实际提供的内容

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

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

curl -X POST https://gateway.pipeworx.io/v1/tools/sec_contracts_search \
  -H 'Content-Type: application/json' \
  -d '{"query":"change of control","exhibit_type":"EX-10","since":"2025-01-01","limit":12}'

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

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

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

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

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

npx -y @pipeworx/mcp-sec-contracts

它通过 stdin/stdout 使用 MCP 通信，并响应 initialize/tools/list/tools/call，仅提供此软件包的工具——不包含上述网关连接额外提供的任何共享元工具。相同的源代码，相同的工具，无需 ask_pipeworx 路由。

使用 ask_pipeworx

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

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

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT