Epstein

epstein

对众议院监督委员会为调查 Jeffrey Epstein 而发布的文件进行全文搜索，包括转录访谈、传票和信件；此外（第 2 阶段）还可对 Epstein 本人的飞行员飞行日志进行结构化搜索。Fleet #1480，第 1-2 阶段。

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

工具

工具	可查询内容
epstein_search_documents	某个短语在记录中的出现位置，并提供页级引用
epstein_list_documents	语料库包含哪些内容，以及哪些内容无法搜索
epstein_get_document	单份文档的全文，一次一页
epstein_flight_log_search	飞行员记录中某个机尾编号、航线或日期范围对应的人员

工具名称添加了前缀，因为 search_documents 已被 federal-register 和 riksdagen-se 占用；名称冲突的工具会导致无法访问， 而错误信息给出的带命名空间名称也无法解析。

第 2 阶段：飞行日志

epstein_flight_log_search 读取政府证物 662-RR——Epstein 本人的飞行员飞行日志（1991-2005）。该日志在 USA v. Ghislaine Maxwell, 20-cr-330 (S.D.N.Y.) 案中被采纳为证据并解封，并通过稳定的 DocumentCloud 资源 URL 托管，无需密钥。第 1 阶段最初的发布说明称，众议院监督委员会的语料库中不存在任何飞行日志——这确实没错，但公开来源并非只有这一处。该证物是固定、完整的 118 页历史文档，并非实时数据源，因此只需一次性转录，而非每次请求都调用代理。

目前已录入估计 3,000 多段飞行记录中的 397 段——118 页中的 23 页（fleet #1880 在最初挑选的 10 页种子内容上增加了第 4-13 页；种子内容旨在涵盖 1991-2005 年的完整时间范围；fleet #1881 增加了第 14-16 页）。这份手写日志的机器 OCR 无法使用（构建前已确认，证物随附的 OCR 文本层本身只是无法辨认的字符噪声）；每条已录入记录都直接根据页面图像转录。epstein_flight_log_search 不带筛选条件时会返回确切的已覆盖页码，因此查不到记录绝不表示“没有飞过”——也可能只是相应页面尚未转录。剩余 95 页的转录是后续工作，不会阻碍这部分功能发布。

转录内容的置信度约定（fleet #1880）： passengers_raw 按每条记录逐字保留——同一个人的姓名不会在不同记录间统一拼写，即使明显存在拼写差异也是如此（对于可能是同一个人的姓名，“Krestena” / “Kristena” / “Christina”均有出现）。对某个词虽有一定把握但仍不完全确定时，会在该词内附加结尾标记 [?]（"Arthur Hallering[?]"）；完全无法辨认的词则标记为 [illegible]。这两种标记都不是以猜测代替事实。飞行员自己划掉并更正的内容会被省略，而不标记为 [redacted]——该标记仅用于原始证物页面上的涂黑内容。

设计决策 C 保持不变：乘客条目绝不进行身份确认。 “JE”、“GM”、“SK”等类似首字母缩写会按飞行员原样书写存储并返回，绝不扩展为完整身份——即使该身份已在其他公开报道中披露。原始页面上涂黑的内容会以字面标记 [redacted] 存储；转录者无法有把握辨认的词会以 [illegible] 存储。这两种标记都不是以猜测代替事实。

每条记录都带有自身的来源信息：证物标题、页面上印刷的页码、DocumentCloud source_url，以及源 PDF 的 sha256，因此调用方无需依赖对两条记录是否来自同一文件的猜测。

这是什么，以及它不是什么

这是一个委员会发布的 PDF 文件。它不是“爱泼斯坦档案”，每条响应都会明确说明这一点，不会任由名称让人误以为内容完整。

• 我们已经有了委员会层：search_committee_documents 返回监督委员会谈及这项调查的发布材料、传票公告和工作人员备忘录。本数据包收录的是这些发布材料所链接的内容。
• 这里没有法院文件和案卷——它们属于 court-listener，应当与本数据包关联，而不是重复收录。
• 没有遗产文件批次。 2025-11-12 发布的 "Oversight Committee Releases Additional Epstein Estate Documents" 链接到一个 Google Drive 文件夹，但该文件夹现在返回 404。这些文件无法从此来源获取。不要添加 Drive 抓取工具来追踪它；文件夹已经消失，并非被隐藏。

当前语料库：31 份文件、505 页、约 800,000 个字符，包括 Barr（129 页）、Tova Noel（135 页）和 Bondi（111 页）的访谈转录稿。

每条结果都是一条引文

匹配结果会返回文件标题、页码和委员会自己的 URL，因为这类资料唯一有用的形式，就是读者能够自行核查的形式：

"2025.08.05 Subpoena Cover Letters, page 33 — https://oversight.house.gov/..."

按页存储是硬性要求，而非权宜之计——后续阶段（人物档案、关联关系）都建立在这张表上，任务中的设计决策 B 规定，一条关系边本身就必须是它的引文。

此阶段刻意不做的事

没有实体页面，没有关系评分，没有“关联人士”，也没有推断出的关联。某个名字出现在文件中，是关于该文件的事实；除此之外的任何内容都是一种主张，而对于从未被起诉的人，宽泛推导出的关系边可能构成诽谤。第 3–5 阶段（电子邮件、人物档案、关联关系）是在第 1–2 阶段之上的一层，并遵循各自的规则——尤其是，人物信息来自解封令，绝不会通过提取文本中的姓名获得，因为页面上的已解封姓名与涂黑失误看起来完全相同。根据设计决策 C，第 2 阶段的乘客条目不受此规则限制：它们绝不会被解析为某个身份，因此，促使我们采用决策 A 的涂黑失误风险在此并不以相同方式适用——系统不会将任何内容断言为某个人，返回的首字母也仍是首字母。

有四份文件无法搜索，并会明确说明

31 份文件中有 4 份是没有文本层的扫描件（两份传票附表、两封信）。它们会显示在 epstein_list_documents 中，标记为 searchable: false，而 epstein_get_document 会按名称拒绝提供，并附上原始文件的链接。若将它们存储为空文本，就会导致一份确实存在的文件匹配不到任何内容——这看起来像是“语料库中没有”，而不是“机器无法读取”。

数据来源

• 众议院监督与政府改革委员会的发布页面，以及这些页面在 oversight.house.gov/wp-content/uploads/YYYY/MM/ 下链接的 PDF。免费，无需凭据。没有批量接口：发布页面就是索引，因此数据导入会遍历委员会发布页面本身。
• .github/workflows/epstein-refresh.yml 每周重新抓取一次。委员会会按自己的安排补充这项调查的材料——三份访谈转录稿分别在三次独立发布中公布。
• 政府证物 662-RR，USA v. Ghislaine Maxwell，20-cr-330（S.D.N.Y.）——一份法庭审判证物，已被采纳为证据并解封，以无需密钥的方式托管在稳定的 DocumentCloud 资源 URL 上。这是一份固定且封闭的历史文件，不是实时数据源；它只作为一次性转录稿导入（迁移 186_epstein_flight_logs.sql），而非按请求代理获取。

PDF 下载被截断时，仍会显示为成功。 构建时测得，Bondi 访谈转录稿实际返回 131,072 字节，而声明的大小为 392,928 字节；curl 以 0 退出，file(1) 仍将其识别为有效 PDF——它本来会以三分之一的内容被编入索引，却没有任何错误报告。数据导入会检查每次获取的 Content-Length 和 %%EOF 结束标记，并在失败时重试。

获取展品：这里的 User-Agent 规则恰好相反

s3.documentcloud.org 对普通机器人 User-Agent 返回 200，对完整的 Chrome User-Agent 返回 403。在同一分钟对同一个 URL 进行三种方式的测试：pipeworx/1.0 → 200，普通 Chrome UA → 403，完全不发送 UA → 200。 www.documentcloud.org 页面及其 API 也会拒绝浏览器 UA。

这与通常的规则正好相反——war.gov、dol.gov 和 gao.gov 都需要完整的浏览器标头才会响应。大概是因为来自数据中心 IP、却没有浏览器指纹的浏览器 UA，比诚实的爬虫更容易被判定为异常。

这很重要，因为 403 返回的不是网络错误，而是一个 4.7 KB 的 Cloudflare 拦截页面：如果获取时不检查结果，就会把一个“已下载”的 4.7 KB PDF 记录下来并继续运行。请发送普通且诚实的 User-Agent，并检查 Content-Length 和 %%EOF 结尾。

快速开始

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

{
  "mcpServers": {
    "epstein": {
      "url": "https://gateway.pipeworx.io/epstein/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/epstein/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 都连接到同一个网关和相同的 1879+ 个数据源。唯一的区别是哪些工具包的工具会被直接列出；从任一端点都可以通过 ask_pipeworx 访问所有工具。

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

curl -X POST https://gateway.pipeworx.io/v1/tools/epstein_search_documents \
  -H 'Content-Type: application/json' \
  -d '{"query":"non-prosecution agreement"}'

首次调用无需账户。检查任意工具：GET https://gateway.pipeworx.io/v1/tools/epstein_search_documents。查找工具：向 https://gateway.pipeworx.io/v1/tools/search_packs 发送 POST 请求，并附上 {"query":"..."}。

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

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

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

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

npx -y @pipeworx/mcp-epstein

它通过 stdin/stdout 使用 MCP 通信，并响应 initialize/tools/list/tools/call，但仅限此工具包的工具——不包含上文网关连接额外提供的任何共享元工具。数据源相同，工具相同，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

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

ask_pipeworx({ question: "your question about Epstein data" })

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT