作为 Apify Actor 的 MCP 服务器 —— 一个可运行的参考实现

这是 renzomacar/multi-scraper-mcp 背后的源代码，它是一个以 Apify Actor 的 Standby 模式运行的 MCP 服务器，向 Claude、Cursor 和 Windsurf 等 AI 客户端提供 16 个线索生成和网页抓取工具。

它作为参考发布，因为有趣的部分不是工具列表，而是三个传输层 bug——它们让真实客户端无法连接，而每次运行却都报告 SUCCEEDED。

此代码修复的三个故障

1. 过期的会话 ID 让客户端永远卡住

会话保存在内存中的 Map 里，但 Standby 运行并不是一个长期存活的进程——Apify 会回收它。客户端在周二带着周一的 Mcp-Session-Id 重新连接时，会碰到一个从未听说过该 ID 的进程。

服务器过去会返回 400。规范 明确规定响应必须是 404：

服务器可以随时终止会话，之后它必须对包含该会话 ID 的请求以 HTTP 404 Not Found 响应。

当客户端收到 HTTP 404 [...] 时，它必须通过发送一个不带会话 ID 的新 InitializeRequest 来开始新会话。

客户端的恢复路径与状态码绑定。400 会移除其自我修复的能力。参见 src/main.js 中的 sessionGone()。

2. Accept 头在我们的任何代码运行之前就拒绝了客户端

规范要求客户端发送 Accept: application/json, text/event-stream。一些真实客户端只发送其中一个，或者什么都不发送，传输层会在请求到达处理器之前返回 406——因此日志中没有任何记录，控制台中也没有失败运行。

normalizeAccept() 无论如何都会接受它们。问题在于：传输层从 req.rawHeaders 读取该头，因此仅修改 req.headers 不会起任何作用。

3. 一个慢工具在工作进行中丢掉了连接

这些工具包装了需要一到三分钟的抓取器。如果线路上没有字节流动，Standby 网关就会断开连接。修复方法是每 10 秒流式发送一条 notifications/message，并在 finally 中清除定时器，这样提前的错误返回就不会泄漏定时器。

Related MCP server: ZapFetch MCP Server

诚实计费

Actor.charge 位于实际返回数据的路径上，在数据到手之后——而不是在请求处理器的开头。在数据到达时计费意味着为失败计费。

文件结构

运行

npm install
npm start

然后将 MCP 客户端指向 http://localhost:4321/mcp。在 Apify 平台上，Standby URL 是 https://USERNAME--ACTOR-NAME.apify.actor/mcp——注意 USERNAME-- 前缀；发布不带此前缀的 URL 会让每次复制粘贴都失败。

一个值得运行的检查

六个请求，每一个都是一个已发布的 bug：

1. 使用正确的 Accept 头进行握手 → 200

2. 使用 Accept: application/json 进行握手 → 200（原为 406）

3. 不带 Accept 头进行握手 → 200（原为 406）

4. 使用未知会话 ID 调用 tools/list → 404（原为 400）

5. 在仍持有过期 ID 时调用 initialize → 200（原为 400）

6. 在活动会话上调用 tools/list → 200，返回完整工具列表

第 2 到第 5 项在生产环境中全部是坏的，而 Actor 却报告运行健康。

许可证

MIT