Use a CAPTCHA MCP result in a browser agent

1. 1.

   Configure the local MCP server

   Follow the MCP setup instructions to launch solvethree-mcp through npx. It’s a local stdio server, not a hosted endpoint. Supply SOLVETHREE_API_KEY and SOLVETHREE_PROXY through the host environment; don’t put credentials in the agent’s prompt.

2. 2.

   Check the available tools and site profile

   Call solvethree_capabilities to inspect the available capabilities. For reCAPTCHA Enterprise, the workspace must already have an active profile for the intended hostname, capture action and reCAPTCHA type. Passing site and action to a create tool doesn’t create that profile. Use Site profiles if setup is still needed.

3. 3.

   Confirm that the browser can submit the matching request

   The browser must support the same pinned proxy and the returned userAgent and secChUa. It must also retain the application’s cookies, CSRF fields and session requirements. If the browser tool can’t configure these, stop before paying for a solve rather than substituting an unrelated browser session.

For the reCAPTCHA MCP tool, the single proxy comes from SOLVETHREE_PROXY, not from the tool arguments. Keep that proxy pinned for the browser submission. The host receives private solution data, so keep tokens and proxy credentials out of routine agent reports.

Use this instruction once the MCP server and browser are configured. Supply the target hostname and execution action from the application’s request. solvethree_create_recaptcha defaults to Enterprise v3; its required arguments are site, action and requestId.

Use the already-configured solvethree MCP server for one reCAPTCHA Enterprise task.
The target hostname must have an active workspace profile before creation.
1. Keep one requestId for this logical task. Ask before starting another paid task.
2. Call solvethree_create_recaptcha with site, action and that requestId.
   The server reads its target proxy from SOLVETHREE_PROXY.
3. Save the returned id. Call solvethree_get_task for that id while pending/solving,
   stopping at ready, failed or the agreed deadline. Never poll by creating again.
4. If ready, submit solution.token using the application’s actual token parameter.
   Use the returned userAgent/secChUa and the same pinned proxy in the browser.
   Keep the application’s cookies, CSRF fields and session requirements.
5. Read the application response. Report task ID and outcome, not secret solution data.
If the browser tool cannot configure that proxy and identity, stop and explain the
missing capability instead of claiming it submitted an equivalent request.

The saved task id is for solvethree_get_task; it isn’t the value to submit to the website. pending and solving mean keep waiting within the agreed deadline. Only ready contains a usable solution. On failed, read errorCode and error and stop polling that task.

There’s no universal autofill step. Identify the application request that consumes the result, then use the matching solution field. For every result below, use the returned browser identity and successful proxy for its intended target.

After submission, inspect the application response. A ready task means a solution was generated, not that the target accepted it. If the target rejects it, first inspect the outgoing request: confirm the actual token, cookie or headers were sent, along with the matching proxy, identity and application session. Report the task ID and application outcome without exposing the solution.

Generate one requestId per logical task and retain it with the original inputs. It must contain 1–64 ASCII letters, numbers, underscores or hyphens. If creation times out before you receive an id, repeat the same create request with the same requestId and unchanged inputs to recover the existing task. If you already have the task id, use solvethree_get_task.

Don’t change the inputs while reusing that ID: doing so conflicts. Don’t generate a fresh ID merely because a response was lost or the polling deadline expired. Neither event proves the original task failed.

Each MCP create call makes at most one task, but that doesn’t impose a spending limit on the agent. Require approval before starting another logical task. For a terminal failure, inspect errorCode and error before deciding whether a corrected request is warranted; failed solves are refunded. A request error is a separate problem from a task whose status is failed.