Cursor に solvethree MCP を追加する

1. 1.

   環境変数を設定する

   SOLVETHREE_API_KEY にワークスペースの API キーを、SOLVETHREE_PROXY に解決処理と送信に使用するプロキシを設定してください。Cursor を起動するプロセスで、両方を使用できるようにしてください。プロジェクトの設定に認証情報を直接記述しないでください。

2. 2.

   設定ファイルを選ぶ

   プロジェクト固有の設定には .cursor/mcp.json を、ユーザー全体の設定には ~/.cursor/mcp.json を使用します。プロジェクト側の solvethree という名前のエントリは、同名のグローバルエントリより優先されます。

3. 3.

   サーバーエントリを追加する

   以下の設定を使用してください。ファイルに他のサーバーがすでに含まれている場合は、ファイルを置き換えず、既存の mcpServers オブジェクト内に solvethree を追加してください。

{
  "mcpServers": {
    "solvethree": {
      "command": "npx",
      "args": [
        "--yes",
        "--package=https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz",
        "solvethree-mcp"
      ]
    }
  }
}

これにより、公式 SDK のダウンロードから npx を使って solvethree-mcp が起動します。この設定は Cursor の環境を継承し、JSON 内での環境変数の展開には依存しません。

Cursor を完全に終了し、両方の変数を含む環境から再起動してください。ターミナルで変数をエクスポートしても、すでに実行中の GUI には反映されません。

Cursor の MCP ツールと MCP Logs の出力を確認してください。サーバーは solvethree_capabilities、solvethree_create_recaptcha、solvethree_create_kasada、solvethree_create_tmpt、solvethree_get_task を公開します。最初に solvethree_capabilities を呼び出し、利用可能な操作を確認してください。

サーバーが起動しない。

MCP Logs で起動エラーを確認してください。

試してみましょう： Cursor が npx を見つけられない場合は、Cursor の PATH で使用できるようにしてから Cursor を再起動してください。

サーバーが環境変数の不足を報告する。

現在のターミナルだけでなく、実際に Cursor を起動した環境を確認してください。

試してみましょう： その環境で両方の変数を設定し、Cursor を完全に終了してから再起動してください。

Cursor が想定と異なる設定を使用する。

両方の設定ファイルで solvethree エントリを探してください。

試してみましょう： グローバルエントリを使用するつもりだった場合は、プロジェクト側のエントリを更新または削除してください。

Cursor の設定インターフェースについては、公式 MCP ドキュメントを参照してください。

1. 1.

   サイトプロファイルが有効であることを確認する

   サイトプロファイルで、対象のホスト名、キャプチャアクション、reCAPTCHA の種類を設定してください。解決をリクエストする前に、プロファイルが有効であることを確認してください。ツールにホスト名とアクションを渡しても、プロファイルは作成されません。キャプチャ手順については、サイトプロファイルの設定を参照してください。

2. 2.

   reCAPTCHA ツールを呼び出す

   Cursor に site、action、一意の requestId を指定して solvethree_create_recaptcha を呼び出させてください。site はページ URL ではなくホスト名です。recaptchaType のデフォルトは enterprise-v3 で、waitMs は省略可能です。ツールは単一のプロキシを SOLVETHREE_PROXY から読み取るため、プロキシ引数、type、url は追加しないでください。

3. 3.

   タスクが終了状態になるまで確認する

   タスクが pending または solving の場合は、solvethree_get_task を使用して再度確認してください。使用可能なソリューションが含まれるのは ready の場合のみです。failed の場合はポーリングを停止し、何を変更するか判断する前に errorCode と error を確認してください。

作成がタイムアウトした場合は、requestId を保持してください。各作成呼び出しが作成するタスクは最大 1 つで、同じ入力と同じリクエスト ID で繰り返すと既存のタスクを取得できます。同じ ID を再利用しながら入力を変更すると競合します。最初の応答が失われたという理由だけで、新しい ID を生成しないでください。

タスクが準備完了になると、MCP サーバーの役割は終了します。返された reCAPTCHA トークンは、アプリケーションから本来の送信先に送信する必要があります。返された userAgent と secChUa の識別情報を、解決処理用に設定したものと同じプロキシで使用してください。プロキシを切り替えたり、無関係なブラウザー識別情報を混在させたりすると、リクエストが失敗する可能性があります。

他のツールを使用する場合は、ソリューションの種類を混同しないでください。Kasada は一緒に適用するヘッダーオブジェクトを返し、TMPT はそのまま使う tmpt Cookie の値を返します。どちらも reCAPTCHA トークンではありません。

Cursor はツールの応答を通じて非公開のソリューションデータを受け取ります。ready の結果は、ソリューションが生成されたことを意味し、アプリケーションのリクエストが送信先に受け入れられたことを意味するものではありません。送信に失敗した場合は、次の解決処理に料金を支払う前に、送信するトークンまたは Cookie、識別情報、プロキシを確認してください。