MCPサーバーをApify Actorとして実行する — 実動リファレンス

これはrenzomacar/multi-scraper-mcpのソースです。 StandbyモードでApify Actorとして動作し、Claude、Cursor、WindsurfなどのAIクライアントに16のリードジェネレーションおよびウェブスクレイピングツールを公開するMCPサーバーです。

リファレンスとして公開されている理由は、興味深い部分がツール一覧ではなく、すべての実行がSUCCEEDEDを報告している間に実際のクライアントが接続できない原因となった3つのトランスポートバグにあるためです。

このコードが修正する3つの障害

1. 古いセッションIDがクライアントを永久に固まらせていた

セッションはインメモリのMapに保存されますが、Standby実行は単一の長時間稼働プロセスではありません — Apifyはそれを再利用します。火曜日に月曜日のMcp-Session-Idで再接続するクライアントは、そのIDを知らないプロセスに到達します。

以前のサーバーは400で応答していました。仕様では、応答は404でなければならないと明示されています：

サーバーはいつでもセッションを終了してもよい（MAY）。その後、そのセッションIDを含むリクエストに対してHTTP 404 Not Foundで応答しなければならない（MUST）。

クライアントがHTTP 404を受信した場合 [...] クライアントはセッションIDを付けずに新しいInitializeRequestを送信して新しいセッションを開始しなければならない（MUST）。

クライアントの復旧経路はステータスコードに依存しています。400はクライアントの自己修復能力を奪います。src/main.jsのsessionGone()を参照してください。

2. Acceptヘッダーが、私たちのコードが実行される前にクライアントを拒否していた

仕様では、クライアントはAccept: application/json, text/event-streamを送信することが要求されています。実際のクライアントのいくつかは片方だけ、または何も送信せず、トランスポートはリクエストがハンドラーに到達する前に406で応答します — そのためログには何も残らず、コンソールにも失敗した実行は表示されません。

normalizeAccept()はそれらをとにかく受け入れます。落とし穴：トランスポートはreq.rawHeadersからヘッダーを読み取るため、req.headersだけをパッチしても効果がありません。

3. 遅いツールが作業中に接続を切断していた

これらのツールは1〜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を公開すると、すべてのコピーペーストが失敗します。

実行する価値のあるチェック

6つのリクエスト。それぞれが出荷されたバグです：

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