Использование результата CAPTCHA MCP в браузерном агенте

1. 1.

   Настройте локальный сервер MCP

   Следуйте инструкциям по настройке MCP, чтобы запустить solvethree-mcp через npx. Это локальный stdio-сервер, а не размещённая на сервере конечная точка. Передайте SOLVETHREE_API_KEY и SOLVETHREE_PROXY через окружение хоста; не помещайте учётные данные в промпт агента.

2. 2.

   Проверьте доступные инструменты и профиль сайта

   Вызовите solvethree_capabilities, чтобы просмотреть доступные возможности. Для reCAPTCHA Enterprise в рабочем пространстве уже должен быть активный профиль для нужного имени хоста, действия захвата и типа reCAPTCHA. Передача site и action инструменту создания не создаёт этот профиль. Если настройка ещё нужна, откройте Профили сайтов.

3. 3.

   Убедитесь, что браузер может отправить соответствующий запрос

   Браузер должен поддерживать тот же закреплённый прокси и возвращённые userAgent и secChUa. Он также должен сохранять cookie приложения, поля CSRF и соблюдать требования к сессии. Если браузерный инструмент не позволяет это настроить, остановитесь до оплаты решения, а не подменяйте сессию браузера другой, не связанной с ней.

Для инструмента reCAPTCHA MCP единственный прокси берётся из SOLVETHREE_PROXY, а не из аргументов инструмента. Сохраняйте этот прокси закреплённым при отправке из браузера. Хост получает конфиденциальные данные решения, поэтому не включайте токены и учётные данные прокси в обычные отчёты агента.

Используйте эту инструкцию после настройки MCP-сервера и браузера. Передайте целевое имя хоста и действие выполнения из запроса приложения. solvethree_create_recaptcha по умолчанию использует Enterprise v3; обязательные аргументы — site, action и 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.

Сохранённый id задачи предназначен для solvethree_get_task; это не значение для отправки на сайт. pending и solving означают, что нужно продолжать ожидание в пределах согласованного срока. Только ready содержит пригодное для использования решение. При failed прочитайте errorCode и error и прекратите опрос этой задачи.

Универсального шага автозаполнения нет. Определите запрос приложения, который использует результат, затем возьмите соответствующее поле решения. Для каждого результата ниже используйте возвращённые идентификационные данные браузера и прокси, с которым решение было получено, для предусмотренной цели.

После отправки проверьте ответ приложения. Статус задачи ready означает, что решение сгенерировано, а не что целевой сайт его принял. Если сайт отклоняет решение, сначала проверьте исходящий запрос: убедитесь, что фактический токен, cookie или заголовки были отправлены вместе с соответствующими прокси, идентификационными данными и сессией приложения. Укажите в отчёте ID задачи и результат со стороны приложения, не раскрывая решение.

Генерируйте один requestId на каждую логическую задачу и сохраняйте его вместе с исходными входными данными. Он должен содержать 1–64 символа ASCII: буквы, цифры, подчёркивания или дефисы. Если время ожидания создания истекло до получения id, повторите тот же запрос создания с тем же requestId и неизменёнными входными данными, чтобы получить существующую задачу. Если id задачи у вас уже есть, используйте solvethree_get_task.

Не меняйте входные данные при повторном использовании этого ID: это вызывает конфликт. Не генерируйте новый ID лишь потому, что ответ потерян или срок опроса истёк. Ни одно из этих событий не доказывает, что исходная задача завершилась с ошибкой.

Каждый вызов создания MCP создаёт не более одной задачи, но это не ограничивает расходы агента. Требуйте подтверждения перед запуском следующей логической задачи. При окончательном сбое проверьте errorCode и error, прежде чем решать, нужен ли исправленный запрос; за неудачные решения средства возвращаются. Ошибка запроса — отдельная проблема, отличная от задачи со статусом failed.