Commoncrawl

@pipeworx/commoncrawl

Common Crawl 的公开网页档案——查找自 2008 年以来某个 URL 被抓取的所有时间，并读取抓取时保存的页面原始字节。

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

工具

• commoncrawl_crawls(limit?, contains_date?) — 按月列出的抓取集合 （CC-MAIN-2026-34 等），以及每个集合覆盖的抓取时间范围。 contains_date 可回答“哪份快照能看到我页面在那天的状态”。
• commoncrawl_index_search(url, crawl?, match_type?, limit?, page?, filter?, from?, to?) — 针对 URL、主机或整个域名查询 CDX 索引。返回抓取时间戳、 HTTP 状态、MIME 类型、检测到的语言、内容摘要，以及后续工具所需的 WARC filename、offset 和 length。
• commoncrawl_fetch_record(filename, offset, length, max_body_bytes?) — 按字节范围读取 一条归档记录：WARC 标头、抓取到的 HTTP 响应标头，以及抓取时的页面正文。

身份验证

无需密钥。

数据源

• https://index.commoncrawl.org/collinfo.json — 抓取集合列表。
• https://index.commoncrawl.org/{crawl}-index — CDX 索引，采用 JSON Lines 格式。
• <https://data.commoncrawl.org/{warc path}> — WARC 记录，支持 HTTP 范围读取。

其他人原本需要重新发现的事项

• CDX 主机在负载较高时会偶尔返回 502。 2026-09-17 的测量结果：同一个 url=example.com 查询在一分钟内交替返回 200 和 nginx 502， 所以问题出在负载，而不是查询本身。ccFetch 遇到 5xx 时会短暂等待后重试两次。 否则，调用方会把临时的 nginx 错误误认为“Common Crawl 没有这个 URL 的记录”， 但这是完全不同且错误的答案。
• “没有抓取记录”时返回的是带有英文句子的 404，而不是 JSON。 我们将其处理为 空结果集，并附上明确的 note，因此空的 captures 数组不会与上游故障 混为一谈。
• 每条索引记录都是独立的 gzip 成员，因此按字节范围读取 offset..offset+length-1 后可独立解压——无需流式读取整个 1 GB 的 WARC。 Workers 运行时中的 DecompressionStream('gzip') 可处理此操作。
• new TextDecoder('utf-8', { fatal: false }) 无法通过 @cloudflare/workers-types 的类型检查：其 TextDecoderConstructorOptions 还要求提供 ignoreBOM。不传任何选项即可；默认就是非致命模式。
• 针对大型域名进行宽泛的 match_type: "domain" 查询会给上游带来很大开销， 也最容易触发 502。请使用 match_type: "host" 并搭配 =status:200 之类的 filter 来缩小范围。

相关包

crawlgraph 是我们为自己抓取的网站构建的链接图谱。此包读取的是 Common Crawl Foundation 的语料库——数据不同，适用的问题也不同。

快速开始

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

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

此端点实际提供的内容

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

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

curl -X POST https://gateway.pipeworx.io/v1/tools/commoncrawl_crawls \
  -H 'Content-Type: application/json' \
  -d '{"limit":3}'

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

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

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

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

或者直接运行，确认服务可以启动：

npx -y @pipeworx/mcp-commoncrawl

它通过 stdin/stdout 使用 MCP 协议，并仅针对本工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。使用相同的源代码和工具，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

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

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

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT