Icij Offshore Leaks

@pipeworx/icij-offshore-leaks

按名称搜索 ICIJ Offshore Leaks Database 中的离岸实体、高管（董事／股东／受益人）和中介机构（注册代理、律师事务所、银行），涵盖 ICIJ 的五项调查（Offshore Leaks 2013、Panama Papers 2016、Bahamas Leaks 2016、Paradise Papers 2017、Pandora Papers 2021）；也可获取某个节点的完整档案，以及所有关联的高管／中介机构／实体／地址和每条关联所源自的泄漏事件。

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

工具

• offshore_search(name, jurisdiction?, node_type?, limit?) — 按名称搜索实体、高管和中介机构（支持前缀的 FTS5），可选按司法管辖区和节点类型筛选。返回每条匹配项的 node_id、类型、司法管辖区、状态及其所源自的泄漏事件。
• offshore_entity(node_id, limit?) — 获取某个节点的完整档案（名称、司法管辖区、状态、注册／注销日期、注册代理），以及所有关联关系（角色、方向、另一节点的名称和类型，以及该关联所源自的泄漏事件）。适用于任何节点类型。

身份验证

无需密钥。

许可与免责声明 — 每条响应均原样包含以下内容

ICIJ Offshore Leaks Database 根据 Open Database License (ODbL) 许可（内容采用 Creative Commons Attribution-ShareAlike 许可）。 ICIJ：“使用这些数据时，请务必注明国际调查记者联盟。”

ICIJ：“将某个人或实体纳入 ICIJ Offshore Leaks Database，并不旨在暗示或表示其从事过非法或不当行为。” 许多人和实体的名称相同或相似。

此软件包仅提供 ICIJ 自身已发布的信息 — 名称、角色、司法管辖区和关联关系。不会与任何其他个人数据来源进行信息补充。

数据源

• 国际调查记者同盟（ICIJ）的 Offshore Leaks Database（offshoreleaks.icij.org）——ICIJ 对其公开数据库背后关系图的批量 CSV 导出：约 81.4 万个实体、约 77.1 万名管理人员、约 2.7 万名中介、约 40.2 万个地址、约 3,000 个其他节点，以及它们之间约 334 万条关系边，涵盖五项特定时间点的调查。

存储数据，不随包导入，也不是实时查询。 ICIJ 以 ODbL 许可发布批量 CSV 下载，而不是可调用的 API，因此这是一个 BUILD-THE-COPY 包（CLAUDE.md“我们将采用的数据源”）。约 200 万个节点和约 330 万条边存储在 D1 数据库中，网关通过 _d1 将其提供给此包（pack-manifest.json 中的 "d1Binding": "ICIJ_OFFSHORE_LEAKS_DB"；架构和查询位于 src/store.ts）——如此规模的数据若随包导入，会直接突破网关 Worker 的包大小上限（原始大小 28 MiB／gzip 后 6.5 MiB；仅此数据集就约有 1 GB 的 SQL）。

加载器会处理一个已知的数据问题： ICIJ 的导出会对 nodes-officers.csv 和 nodes-intermediaries.csv 中约 1,139 名人员重复使用相同的 node_id（姓名／国家／来源均相同，例如 node_id 51122 的 “Peng, Wan-Hsiung” 同时列在两者中）。ICIJ 自己的网站（offshoreleaks.icij.org/nodes/<id>）会将这些 ID 解析为“中介”，因此对于发生冲突的 ID，加载器会保留中介行并丢弃重复的管理人员行（scripts/icij-offshore-leaks/fetch-icij-data.py）。

搜索使用 FTS5，而非 LIKE——与本目录中规模较小的 D1 存储包不同，约 160 万个可搜索姓名数量过多，无法在 D1 的单次查询限制内可靠地通过 LIKE '%term%' 扫描查询。offshore_name_fts 是一张独立的 FTS5 表（没有 content=／content_rowid=），与 offshore_node 的 rowid 解耦，并通过 node_id TEXT 列进行关联——这样做专门是为了避开 D1 FTS5 的两个已知问题：分块导入基础表不会填充 FTS5 倒排索引（因此，加载器会在确认基础数据完整加载之后，在服务端通过自己批量执行的语句重建索引）；而引用基础表中不存在列的外部内容 FTS，在 D1 上运行时会报错，但本地 sqlite 冒烟测试却不会提示问题。

刷新：

python3 scripts/icij-offshore-leaks/fetch-icij-data.py --out /tmp/icij-ndjson
node scripts/icij-offshore-leaks/load-data.mjs --ndjson /tmp/icij-ndjson --db pipeworx-icij-offshore-leaks

ICIJ 会按自己的计划更新批量导出（自 2013 年以来有五项特定时间点的调查，最近一次是 2021 年的 Pandora Papers，之后也有增量修正）。每个响应中的 data_as_of 都是最近一次加载时该导出文件自身的生成日期。此操作会写入生产 D1——只有具备相应访问权限时才运行；所依赖的一次性数据库创建步骤，请参阅下方的“生产环境设置”。

生产环境设置（一次性操作，由本包作者之外的人员完成——D1 写入由 Bruce 决定）

wrangler d1 create pipeworx-icij-offshore-leaks --location wnam
# then add the [[d1_databases]] block it prints to workers/gateway/wrangler.toml:
#   binding = "ICIJ_OFFSHORE_LEAKS_DB"
#   database_name = "pipeworx-icij-offshore-leaks"
#   database_id = "<from the create output>"

python3 scripts/icij-offshore-leaks/fetch-icij-data.py --out /tmp/icij-ndjson
node scripts/icij-offshore-leaks/load-data.mjs --ndjson /tmp/icij-ndjson --db pipeworx-icij-offshore-leaks

已在本地使用真实的 2026-09-09 导出数据验证（使用 --local-sqlite 而非 --db，不涉及网络／wrangler）：共 2,016,523 个节点（814,344 个实体、770,176 名管理人员、26,768 名中介、402,246 个地址、2,989 个其他节点；已对 1,139 个管理人员／中介重复项去重），3,339,267 条关系，FTS 索引含 1,611,197 行，单核加载耗时远低于一分钟。生成的 SQLite 文件约为 1.1 GB，远低于 D1 的 10 GB（Workers Paid）数据库大小上限。生产环境加载主要受网络往返耗时影响，而非 CPU：加载器会为每个文件打包多个受字节数限制的 INSERT 语句（D1 的单条语句上限为 100,000 字节；wrangler d1 execute --file 支持最大 5 GiB 的文件），因此 offshore_node 约需 74 个文件，offshore_relationship 约需 50 个文件，服务端重建 offshore_name_fts 则需 41 个批次——总计约 165 次 wrangler d1 execute 往返，预计耗时 45–90 分钟，具体取决于 D1 每个文件的导入延迟。

快速开始

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

{
  "mcpServers": {
    "icij-offshore-leaks": {
      "url": "https://gateway.pipeworx.io/icij-offshore-leaks/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/icij-offshore-leaks/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/offshore_search \
  -H 'Content-Type: application/json' \
  -d '{"name":"Wintris"}'

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

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

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

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

也可以直接运行，以确认服务能启动：

npx -y @pipeworx/mcp-icij-offshore-leaks

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

与 ask_pipeworx 搭配使用

除了直接调用工具，你也可以用自然语言提问——此方法既适用于上面的工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Icij Offshore Leaks data" })

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

更多信息

• 文档与指南
• pipeworx.io

许可证

MIT