FetchSandbox

fetchsandbox-mcp

Smithery、npm、公式 MCP レジストリでも公開されています。

FetchSandbox 用の MCP サーバーとして提供される、エージェント向けの決定論的な検証エンジンです。

エージェントがインテグレーションを作成します。実際に動作するかどうかを、実際のプロバイダーのように振る舞うサンドボックスで検証します。再試行された Webhook、拒否されたカード、レート制限、認証エラーなどの失敗も含まれます。

バグが見つかると、修正を提案して実証できます。同じ失敗を、差分の適用前と適用後のコードに対して実行します。最初に再現し、適用後に再現しなくなった場合にのみ成功となります。どちらの場合も、結果を確認できる URL が発行されます。

インストール

MCP サーバーは Node.js を使ってローカルで実行します。クライアントによって npx の解決方法が異なることがあります。Mac の Cursor では、command -v npx で取得したフルパスが必要な場合があります。

{
  "mcpServers": {
    "fetchsandbox": {
      "command": "npx",
      "args": ["-y", "fetchsandbox-mcp@latest"],
      "env": { "FETCHSANDBOX_API_KEY": "fsk_your_key_here" }
    }
  }
}

検出ツールとリファレンスツールは、キーなしで利用できます。アプリケーションの計画、検証、管理されたローカルトンネリングには、サインインまたは API キーが必要です。 https://fetchsandbox.com/keys から入手できます。 アカウントを参照してください。

クライアント	ファイル
Claude Code	プロジェクトルートの .mcp.json、または claude mcp add
Claude Desktop	~/Library/Application Support/Claude/claude_desktop_config.json
Cursor	~/.cursor/mcp.json、またはリポジトリ内の .cursor/mcp.json
Zed	context_servers の下にある ~/.config/zed/settings.json
Codex	[mcp_servers.fetchsandbox] として ~/.codex/config.toml

Mac の Cursor：動作確認済みの設定

https://fetchsandbox.com/keys から実際のアカウントキーを取得します。command -v npx を実行し、そのフルパスを ~/.cursor/mcp.json で使います。この例は Apple Silicon 上の Homebrew を対象としています。パスが異なる場合は置き換えてください。Windows では where.exe npx を使って、インストール済みのコマンドを確認します。

{
  "mcpServers": {
    "fetchsandbox": {
      "command": "/opt/homebrew/bin/npx",
      "args": ["-y", "[email protected]"],
      "env": { "FETCHSANDBOX_API_KEY": "fsk_your_key_here" }
    }
  }
}

fsk_your_key_here は、Bearer プレフィックスを付けずに、実際のキーへ個別に置き換えてください。このプレースホルダーでは認証できません。プロジェクト内の .cursor/mcp.json に FetchSandbox のエントリーが重複していないか確認してください。保存後、Cursor を完全に終了して再起動してください。ウィンドウの再読み込みでは、古い MCP プロセスが残ることがあります。必要に応じてサーバーを有効にし、ツールが読み込まれることを確認してください。接続が緑色であるだけでは、アプリケーションの検証呼び出しが認証されているとは限りません。

その後、クライアントを再起動してください。MCP に対応する他のクライアントでも、同じコマンドと引数を使います。

ターミナルがない場合：ホスト型エンドポイントを使用

Lovable、Bolt、v0 などのブラウザベースのビルダーでは npx を実行できません。代わりに、ホスト型のストリーミング可能な HTTP トランスポートに直接接続します。

https://fetchsandbox.com/mcp/v1

「None」ではなくBearer トークンで認証してください。https://fetchsandbox.com/keys からキーを貼り付けます。

同じツイン、同じシナリオ、7 つのツール：validate_integration、quickrun、run_workflow、verify_behavior、list_workflows、guide、coach。

残りのツールは非表示ではありません。ここでは動作しないのです。find_bugs、fix_bug、prove_fix はディスク上のプロジェクトを読み込みますが、ホスト型サーバーにはそのコピーがありません。そのため、これらを案内すると、行き詰まるセッションが発生していました。自分のコードを分析するには、確認したいプロジェクト内で npx fetchsandbox-mcp をローカル実行してください。

まず validate_integration を実行してください。quickrun の成功は、プロバイダーがドキュメントどおりに動作することを実証しますが、チェックアウトのエンドポイント、Webhook ハンドラー、メール送信には触れません。validate_integration はプロバイダーごとに新しいツインを用意し、お客様のコードが実際に呼び出した内容を報告します。

使用方法

同僚に説明するように、問題を説明してください。ツール名を挙げる必要はありません。

Paddle で決済した後、購入した数より多くのシートが顧客に割り当てられているという報告が届いています。 原因を調べてもらえますか？

エージェントは、症状の振り分け、プロバイダーのサンドボックスでの再現、コードの確認、修正案の取得、ご自身のコードでの修正の検証という手順で進めます。各ステップで、次のステップに必要なものを引き渡します。

覚えておくとよいことがあります。つい逆に考えがちですが、prove_fix には未修正のツリーが必要です。差分をディスクに書き込む前に実行してください。そうしないと、再現するバグがなくなり、検証もできません。

アカウント

最初に使う際にアカウントは必要ありません。インストールして質問するだけで、すべて実行されます。

実行結果に残しておきたいもの（レシートや調査結果など）が初めて含まれたとき、短いコードとリンクが表示されます。サインインには約20秒かかり、2つのことが行われます。レシートの根拠となる証拠が15日後にアーカイブされなくなり、そのマシンでの実行履歴が1か所に集約されます。サインインを求められるのは1日に最大1回で、サインイン後に求められることはありません。

CI、ホスト型エンドポイント、またはブラウザーを利用できない環境では、代わりにキーを設定してください。https://fetchsandbox.com/keys で作成できます。サインインしてから「Create a key」を選択してください。キーは fsk_... のような形式です。

MCP クライアントの設定では、env に指定します。

"env": { "FETCHSANDBOX_API_KEY": "fsk_your_key_here" }

シェルまたは CI では、次のように指定します。

export FETCHSANDBOX_API_KEY=fsk_your_key_here

ホスト型エンドポイントでは、Authorization: Bearer fsk_... として送信してください。

エディターからサインインすると、キーは ~/.fetchsandbox/credentials.json にも書き込まれます。環境変数が常に優先されます。

ツール

まずは guide を使ってください。依頼内容に合ったツールを選びます。

問題の特定と修正

ツール	機能	引数
guide	症状に対応する仕様、ワークフロー、既知の障害クラスを案内します	intent*、hints
find_bugs	既知の統合障害クラスに照らしてプロジェクトを監査します。git リモートは不要で、指定したディレクトリを読み取ります	path、spec、timeout_s
fix_bug	1 件の検出結果に対する git diff を返します。ファイルには変更を加えません	bug*、fix_pattern、path、spec、timeout_s
get_job	別の分析や検証を開始せず、同じ実行中のジョブを取得します	job_id*
prove_fix	差分の適用前後で、コードに対して障害を実行します。測定された結果の変化があった場合のみ成功になります	diff*、bug、scenario、sandbox_id、path、timeout_s

統合の検証

ツール	機能	引数
validate_integration	プロバイダーに対して独自のコードを検証します。こちらのツインが動作するかどうかを検証するものではありません。プロバイダーごとに新しいツインを用意し、こちらのリクエストログを読み取って、アプリが実際に呼び出した内容を報告します	providers、app_base_url、session_id
quickrun	同梱された仕様に対して、こちらが用意したワークフローを 1 つ実行します。ここで成功すればプロバイダーがドキュメントどおりに動作していることを示しますが、統合については何も示しません	spec_slug*、workflow_name*、scenario
run_workflow	すでに用意したサンドボックスで同じ処理を実行します。ここで scenario を設定して再実行できます	sandbox_id*、workflow_name*、scenario
verify_behavior	リファレンスハンドラーで障害クラスを表示します。バグありと修正済みの状態を比較します。独自のコードは対象外です	bug_pattern_id*、prompt、sandbox_id、flow_run_id
list_workflows	仕様に注入できるワークフローと障害シナリオをまとめて返します	spec_slug または spec_id
guide	症状を説明するプロバイダーの動作を案内し、引数を埋めた次の呼び出しを返します	intent*、hints
coach	統合の構築を複数ターンにわたって支援します	intent、session_id、user_response、context

この 7 つが、ブラウザー上のビルダーから見えるツールのすべてです。また、ファイルシステムが不要なのもこれらだけです。以下のツールはすべてローカルプロジェクトが必要です。

コードのあるマシン上で

ツール	機能	引数
find_bugs	既知の統合障害クラスに照らしてプロジェクトを監査します	path、spec、timeout_s
fix_bug	1 件の検出結果に対する git diff を返します。ファイルには変更を加えません	bug*、fix_pattern、path、spec、timeout_s
get_job	別の分析や検証を開始せず、同じ実行中のジョブを取得します	job_id*
prove_fix	差分の適用前後で、コードに対して障害を実行します。測定された結果の変化があった場合のみ成功になります	diff*、bug、scenario、sandbox_id、path、timeout_s
run_all_workflows	1 回の呼び出しで複数のワークフローを実行します	sandbox_id*、workflow_names
list_scenarios	仕様に注入できる障害を一覧表示します	sandbox_id*
set_scenario	サンドボックスに障害を設定します	sandbox_id*、scenario*
list_runs	サンドボックスの過去の実行を一覧表示します	sandbox_id*、limit
list_specs	すでに利用可能な仕様を一覧表示します	filter
submit_proof	実行の証明書を公開します	sandbox_id、flow_run_id、bug_pattern_id、summary、proofs

* = 必須。

お使いのマシンから送信されるもの

find_bugs、fix_bug、prove_fix は、指定したディレクトリをまとめてアップロードし、分析します。以前の説明では逆の意味に受け取れる内容だったため、明確にお伝えします。

パッケージ化の前に、.git、node_modules、ビルド出力、エージェントの指示ファイル、および認証情報らしきもの（.env*、*.pem、*.key、id_rsa*、*.tfstate、.npmrc、.aws、.ssh、.mcp.json、.mcp.*.json、mcp.json など）を除外します。

その後、アーカイブを読み戻し、どこにあっても何という名前でも、実際に使える認証情報のようなものが残っていれば、アップロードを拒否します。config/local.yml にキーがある場合、アップロードを中止してファイル名を示します。パターンで網羅できるのは、誰かが想定したものだけです。残りを検出するためにスキャンを行います。

何も外部に出したくない場合、現時点では分析にソースコードが必要です。これがありのままの状況です。

長時間実行される処理

MCP の応答は短時間待機した後、status: running、その job_id、および get_job を呼び出すための next_tool_call を返します。status: done または error になるまで、その呼び出しを続けてください。既存のバックエンドジョブを読み取るものであり、プロジェクトを再度アップロードしたり、別の検証を開始したりすることはありません。検証の実行中は、元のツリーを変更しないでください。ジョブが実行中でも、合格が確定したわけではありません。

これは、問題の検出、修正案の提示、修正適用後の検証、非同期のリファレンス検証に適用されます。ライブラリを直接呼び出す場合のブロッキング動作は変わりません。ジョブの保持と所有権は、引き続き既存のバックエンドが管理します。この変更によって、バックエンドが再起動してもインメモリのジョブトラッカーが維持されるわけではありません。

レシートはリンクを持つ人なら誰でも閲覧できます

submit_proof は、アプリの実行前後における実際のリクエストとレスポンスをレシートページに添付するため、レシートにはコード自体の動作が表示されます。このページはログインなしで閲覧できます。PR にリンクを貼ることが目的だからです。そのため、ページ上の本文はリンクを持つ人なら誰でも読めます。

プロバイダーの実行には、FetchSandbox のツインまたは記録用テストダブルを使用できます。レシートに記載された実行範囲を確認してください。記録用テストダブルでは、ツインまたは実プロバイダーとの忠実度は確認できません。ただし、リクエスト本文はアプリが組み立てたものであり、設定値が含まれる可能性があります。共有する前にレシートを確認してください。

設定

環境変数	デフォルト	目的
FETCHSANDBOX_API_KEY	なし	ブラウザーを使わずにサインインします。保存済みの認証情報より優先されます
FETCHSANDBOX_BASE_URL	https://fetchsandbox.com	接続先を別のバックエンドに変更します
FETCHSANDBOX_TELEMETRY	オン	0 に設定すると無効になります

テレメトリーでは、不透明なマシンごとの ID（~/.fetchsandbox/session.json に保存されるランダムな UUID）、ツール名、レイテンシー、呼び出しの成否を記録します。仕様の内容、リクエスト本文、認証情報は記録しません。セッション数や、利用されている API を把握するためのものです。

サインインすると、呼び出しはアカウントにも紐付けられます。サインインする目的はそこにあり、実行結果を一か所で確認できるようになります。

FETCHSANDBOX_TELEMETRY=0 にすると、マシンごとの ID が送信されなくなり、呼び出しはマシンに紐付けられなくなります。ただし、呼び出しが見えなくなるわけではありません。ツールを実行するのはサーバーなので、サーバーにはツールが実行されたことが記録されます。また、サインインしている場合は、いずれにしてもキーによってユーザーが識別されます。キーとはそういうものです。紐付けを避けるには、サインインしないでください。

ライセンス

MIT — LICENSE を参照してください。

• fetchsandbox.com
• ソースコード · 問題を報告

ngrok を使わずにローカルアプリを検証する

バージョン 0.7.13 では、ローカル MCP パッケージに manage_tunnel が追加されました。実際の隔離されたアプリを起動し、そのループバックポートを公開して、返された app_base_url を validate_integration に渡します。既存のアプリの Webhook パスを application_config.event_destinations で宣言してください。FetchSandbox はプロバイダー固有のイベントに署名し、既存のアプリケーションランナーを通じて個別に保存された状態を確認します。保護された受け渡しを通じてテスト用シークレットを設定し、事前確認を行ってから一度だけ実行し、同じ実行レシートを取得します。接続を閉じた後、一時設定を削除してください。接続できただけではテスト合格になりません。

fetchsandbox.com へのアウトバウンド HTTPS 接続、実行中のローカル MCP プロセス、および実際のローカルアプリが必要です。インバウンドのファイアウォールルールや別途のトンネルインストールは必要ありません。制限付きネットワークでは、承認済みのプロキシ／CA 設定が必要になる場合があります。Node 22.21+ または 24.5+ では、HTTPS_PROXY と NO_PROXY を設定して NODE_USE_ENV_PROXY=1 を使用できます。NO_PROXY に 127.0.0.1/localhost を含め、承認済みの企業 CA には NODE_EXTRA_CA_CERTS を使用してください。古い Node バージョンでは、このプロキシ設定は自動的にはサポートされません。TLS 証明書の検証を無効にしないでください。企業のファイアウォールによって接続がブロックされる場合もあります。リースは 30 分後、またはサーバー再起動時に期限切れになります。不確かな書き込みが自動的に再実行されることはありません。

ローカルアプリ検証用の非公開認証情報（0.7.14）

所有するアプリケーションの実行を設定した後、Cursor、Claude Code などのローカル MCP クライアントは、そのセッション ID と実行 ID を指定して install_test_credentials を呼び出します。 既存の FetchSandbox アカウントキーで取得を認証します。一時的なプロバイダー キー、Webhook シークレット、検証トークンは、プロジェクトの外にある ~/.fetchsandbox/handoffs/ 配下の新しい非公開 dotenv ファイルに書き込まれます（ディレクトリは 0700、ファイルは 0600）。ツールの結果に含まれるのは、そのパスと変数名だけです。env_mapping で、返された名前と実際のアプリの環境設定を明示的に対応付けます。

このファイルを、内容を表示せずに使い捨てアプリケーションの dotenv ローダーで 読み込みます。返された twin のベース URL を設定し、アプリを再起動して、事前確認を行い、 一度だけ実行してから同じレシートを取得します。テスト後は一時ファイルを削除してください。 ファイルは自動削除されず、本番用の認証情報でもありません。値をチャット、 ソースコード、ログ、コマンド引数に貼り付けないでください。Replit/Lovable では、従来どおり所有者のブラウザーを介した受け渡しとネイティブのシークレットマネージャーを使用します。この変更によって prove_fix がローカルリレー経由になることはありません。