Опубликовали готовый MCP сервер для обхода капчи ИИ-агентами

14.04.2026

Обход капчи для ИИ-агентов: настройка связки MCP cthdth

Опубликовали готовый MCP сервер для обхода капчи ИИ-агентами.

Скрапинг и автоматизация претерпели изменения. Хардкодинг скрипты уступают место LLM-агентам: Claude, Cursor и кастомным скрейперам. Они умеют парсить DOM и понимать, куда кликать. Но есть проблема — современные антибот-системы.

Заставить ИИ-агента решать капчи самостоятельно через компьютерное зрение — плохая идея. Во-первых, тяжелые модели долго думают, и пока идет генерация токенов, динамический виджет капчи часто отваливается по таймауту.

Во-вторых, их движения мыши слишком математически выверенные, что быстро палится поведенческими анализаторами. И самое смешное — пространственная слепота. Тесты показывают, что даже сильные модели вроде GPT-4o или Gemini почти всегда проваливают капчи где объект разбит на несколько квадратов, потому что пытаются выделять идеально ровные прямоугольники и не видят сложных границ.

Реальный выход один — токенизированный обход через специализированные API вроде 2Captcha.

А чтобы связать LLM и API, используют Model Context Protocol (MCP) — универсальный порт для ИИ.

Как ИИ-агенты обходят капчу через MCP и почему обычный подход ломается

Идея браузерного ИИ-агента выглядит просто: модель получает задачу, открывает сайт, находит нужные элементы, нажимает кнопки, читает данные и доводит сценарий до результата. Но на реальных сайтах все быстро усложняется. Почти сразу появляются формы, меняющаяся разметка, нестабильные элементы, а затем и капча.

Именно в этот момент многие реализации начинают разваливаться. Обычно все уходит в одну из двух крайностей.

Первая крайность — заставить модель самой разбираться через команды браузера. В таком варианте агент бесконечно делает click, inspect, find, retry, а логика решения капчи расползается по тексту запроса, проверкам DOM и случайным действиям в браузере.

Вторая крайность — спрятать все в один большой скрипт. Снаружи это по-прежнему называют "агентом", но по факту модель просто вызывает заранее подготовленную функцию, которая уже знает весь путь наперед.

Оба варианта неудобны. В первом случае система становится хрупкой и плохо объяснимой. Во втором — сам агент почти теряет смысл.

Рабочий подход выглядит иначе: капча должна быть не частью запроса и не всем сценарием целиком, а отдельным инструментом, который агент вызывает в нужный момент.

Именно здесь MCP оказывается особенно полезен.

Что меняет MCP в этой задаче

Если говорить совсем просто, MCP позволяет вынести весь процесс решения в отдельный инструмент.

Вместо того чтобы агент сам:

искал sitekey
обращался к API сервиса решения
вставлял ответ в DOM
пытался понять, какое именно скрытое поле нужно заполнить

мы даем ему отдельный инструмент:

решить капчу на нужной странице
вернуть результат

Тогда схема становится заметно чище:

Агент -> инструменты MCP -> сценарий -> Selenium -> результат

Агент продолжает решать свою задачу, а капча перестает быть его внутренней проблемой. Это важно: хороший агент не должен быть Selenium-скриптом, который просто замаскирован под ИИ-модель.

На каком принципе строится такая система

Главная идея здесь очень простая:

агент отвечает за управление сценарием, а инструмент — за специализированное действие.

На практике это означает следующее.

Агент может:

открыть страницу
посмотреть, что на ней происходит
понять, что дальнейшую работу блокирует reCAPTCHA v2
выбрать нужный инструмент MCP
после решения продолжить основную задачу

Но агенту не нужно:

вручную реализовывать весь процесс решения
знать, как устроен сервис изнутри
работать с браузером на уровне "вставь ответ в такое-то поле через JS"

Все это должно быть скрыто внутри отдельного решения.

Как это выглядит на практике

В проекте, на котором построен этот подход, есть две группы инструментов.

Первая группа — инструменты работы с браузером.

Они дают агенту обычные действия:

открыть страницу
посмотреть состояние
найти элементы
кликнуть
извлечь текст
извлечь JSON
закрыть сеанс браузера

Вторая группа — инструменты решения капчи.

Они делают только одно:

снимают блокировку в виде reCAPTCHA v2 на текущей странице

Именно это сочетание делает систему действительно агентной, а не хаотичной.

Если оставить инструменты работы с браузером, а обход вынести в отдельный инструмент MCP, модель будет управлять сценарием, но не будет сама заниматься обходом.

Ниже как раз такой пример: на нем удобно показать связку агент -> MCP -> Selenium.

Почему это лучше, чем один большой скрипт

Пользователь может просить не просто "реши капчу", а что-то более прикладное:

открой страницу и получи результат
пройди проверку на странице, чтобы получить доступ к данным
доведи сценарий до конца

Если внутри процесса встречается reCAPTCHA v2, агент не останавливается. Он вызывает специализированный инструмент, получает решение и идет дальше.

Как устроено решение

В проекте архитектура разбита на четыре части.

Набор зависимостей здесь специально оставили небольшим. В requirements.txt сейчас всего четыре библиотеки:

mcp — нужна для запуска MCP-сервера на Python
selenium — нужна для локального управления браузером, чтения DOM, кликов, ожиданий и извлечения данных со страницы
2captcha-python — используется как библиотека для отправки reCAPTCHA v2 в сервис решения
python-dotenv — нужна для загрузки переменных окружения из .env, чтобы не хардкодить ключ API, настройки браузера и пути к служебным файлам

Если разложить это по частям проекта, получится так:

mcp расположен в mcp_server/server.py
selenium используется в app/browser/driver_factory.py, app/browser/page_utils.py, app/workflows/browser.py, app/workflows/recaptcha_v2.py
2captcha-python вынесена в отдельный модуль app/services/solver_client.py
python-dotenv используется в app/services/config.py

Часть, которая работает с браузером

Это базовая часть на Selenium. Она ничего не знает ни про капчу, ни про MCP.

Служебная часть

Это вспомогательная часть проекта:

конфиг
единый формат результата
хранение состояния
подключение к сервису решения

Именно здесь задается важное правило для всей системы: все функции и сервисы возвращают ответ в одном и том же формате.

Слой сценариев

Это центральная часть всей системы. Именно здесь соединяются:

работа с браузером
логика страницы
решение капчи
подготовка результата

Здесь описано, что именно нужно сделать на странице, в каком порядке выполнять шаги и что вернуть после завершения работы.

Слой инструментов MCP

Это внешний слой, который делает функции проекта доступными агенту как инструменты MCP.

Именно через него агент и работает с системой.

Как собрать такой проект с нуля

Если смотреть на этот проект не как на готовый репозиторий, а как на шаблон для своей реализации, удобнее собирать его по шагам. Ниже — не вариант "вот все файлы сразу", а последовательная сборка понятной архитектуры.

Шаг 1. Сначала определить структуру проекта

На старте проект лучше сразу разбить на отдельные части:

text Copy

app/
  browser/
  services/
  workflows/

mcp_server/
requirements.txt
.env.example

Пояснение:

app/browser/ — базовая часть Selenium: создание браузера, ожидания, поиск элементов, снимки экрана
app/services/ — служебная часть: конфиг, модели результата, хранилище сеансов, модуль для сервиса решения
app/workflows/ — слой сценариев: здесь соединяются работа с браузером, решение капчи и единый формат результата
mcp_server/ — слой MCP: публикует функции сценариев как инструменты, которые будут доступны агенту
requirements.txt — зависимости Python-проекта
.env.example — пример настроек запуска и переменных окружения

Почему это важно:

browser/ не должен знать про MCP
services/ не должен знать весь сценарий Selenium целиком
workflows/ не должен знать, как именно публикуются инструменты
mcp_server/ не должен знать внутреннюю механику сценария решения

Если начать с одного файла вроде solve_recaptcha.py, через пару итераций в нем обычно оказываются вперемешку:

браузер
конфиг
библиотека сервиса решения
локаторы элементов
обработка ошибок
логика возврата результата

Разделить это потом уже намного сложнее.

Шаг 2. Сразу зафиксировать формат результата

Это один из самых полезных шагов. Еще до Selenium, до MCP и до сервиса решения стоит определить единый формат результата.

Создаем файл app/services/result_models.py.

python Copy

from dataclasses import asdict, dataclass
from typing import Any, Literal

RunStatus = Literal["success", "error"]

@dataclass(slots=True)
class WorkflowResult:
    status: RunStatus
    workflow: str
    challenge_type: str
    page_url: str
    message: str
    session_id: str | None = None
    screenshot_path: str | None = None
    verification_payload: dict[str, Any] | None = None
    verification_result_path: str | None = None
    details: dict[str, Any] | None = None

    def to_dict(self) -> dict[str, Any]:
        return asdict(self)

Почему это полезно сделать в самом начале:

у слоя сценариев и у инструментов MCP сразу появляется единый формат ответа
агенту проще разбирать ответы инструментов
можно заранее зафиксировать важные поля:
- session_id
- verification_payload
- details.task_complete
- details.should_retry
- details.should_close_session

На практике это избавляет от путаницы, когда сценарий перестает помещаться в один вызов и превращается в цепочку действий.

Шаг 3. Вынести конфиг из основной логики

Следующий шаг — отделить настройки от основной логики.

Для этого создаем файл app/services/config.py.

Это центральная точка, в которой собраны все настройки запуска.

Что здесь находится:

Settings — структура с явно заданными полями для всех параметров запуска.

get_settings() — функция, которая читает переменные окружения и возвращает готовый объект с настройками.

python Copy

from dataclasses import dataclass
import os
from dotenv import load_dotenv

load_dotenv()

@dataclass(slots=True)
class Settings:
    browser_name: str = "chrome"
    browser_headless: bool = False
    screenshot_dir: str = "artifacts/screenshots"
    result_dir: str = "artifacts/results"
    capture_step_screenshots: bool = False
    two_captcha_api_key: str | None = None

def get_settings() -> Settings:
    return Settings(
        browser_name=os.getenv("BROWSER_NAME", "chrome"),
        browser_headless=os.getenv("BROWSER_HEADLESS", "").lower() in {"1", "true", "yes"},
        screenshot_dir=os.getenv("SCREENSHOT_DIR", "artifacts/screenshots"),
        result_dir=os.getenv("RESULT_DIR", "artifacts/results"),
        capture_step_screenshots=os.getenv("CAPTURE_STEP_SCREENSHOTS", "").lower()
        in {"1", "true", "yes"},
        two_captcha_api_key=os.getenv("API-KEY"),
    )

Что это дает на практике:

все переменные окружения собраны в одном месте
слой сценариев не тянет os.getenv() из разных модулей
запуск проекта проще описывать и документировать
проект легче переносить между машинами и окружениями

Шаг 4. Сначала собрать часть проекта для работы с браузером

На этом этапе правильнее сначала сделать отдельную часть проекта для работы с Selenium, а уже потом переходить к сценарию решения.

Создание браузера

Создаем файл app/browser/driver_factory.py.

Этот модуль отвечает только за запуск браузера и его настройку.

Что в нем находится:

create_driver(...) — функция, которая создает и настраивает браузер для локального запуска.

python Copy

from selenium import webdriver
from selenium.webdriver.chrome.options import Options as ChromeOptions

def create_driver(settings: Settings) -> WebDriver:
    browser_name = settings.browser_name.lower()
    if browser_name != "chrome":
        raise ValueError(f"Unsupported browser: {settings.browser_name}")

    options = ChromeOptions()
    if settings.browser_headless:
        options.add_argument("--headless=new")

    options.add_argument("--window-size=1440,1100")
    options.add_argument("--disable-dev-shm-usage")
    options.add_argument("--no-sandbox")

    return webdriver.Chrome(options=options)

Небольшие вспомогательные функции для браузера

Создаем файл app/browser/page_utils.py.

Это набор переиспользуемых функций Selenium, на которых потом будет строиться слой сценариев.

Что в нем находится:

wait_visible(...) — ждет, пока элемент станет видимым.

wait_clickable(...) — ждет, пока по элементу можно будет кликнуть.

find_elements(...) — находит элементы по выбранному способу поиска.

python Copy

def wait_visible(driver: WebDriver, xpath: str, timeout: int = DEFAULT_TIMEOUT) -> WebElement:
    return WebDriverWait(driver, timeout).until(
        EC.visibility_of_element_located((By.XPATH, xpath))
    )

def wait_clickable(driver: WebDriver, xpath: str, timeout: int = DEFAULT_TIMEOUT) -> WebElement:
    return WebDriverWait(driver, timeout).until(
        EC.element_to_be_clickable((By.XPATH, xpath))
    )

def find_elements(driver: WebDriver, strategy: str, query: str) -> list[WebElement]:
    by = _by_from_strategy(strategy)
    return driver.find_elements(by, query)

Почему это лучше сделать до слоя сценариев:

сразу видно, где заканчивается служебная часть Selenium
сам слой сценариев потом пишется на более простых и понятных функциях
слой MCP не начнет случайно тянуть в себя внутренние детали браузера

Шаг 5. Добавить хранилище сеансов

Как только проект начинает работать в агентном режиме, почти сразу появляется еще одна задача: нужно хранить состояние браузера между отдельными вызовами.

Минимальный вариант выглядит так.

Создаем файл app/services/session_store.py.

Это слой в памяти, который хранит открытый браузер между вызовами инструментов MCP.

Что в нем находится:

BrowserSession — объект, который связывает session_id, объект браузера и данные о текущей странице.

SessionStore.create(...) — регистрирует новый сеанс браузера.

SessionStore.get(...) — возвращает уже существующий сеанс по session_id.

SessionStore.close(...) — закрывает браузер и удаляет сеанс из памяти.

python Copy

from dataclasses import dataclass
from threading import Lock
from uuid import uuid4

@dataclass(slots=True)
class BrowserSession:
    session_id: str
    driver: WebDriver
    workflow: str
    challenge_type: str
    page_url: str

class SessionStore:
    def __init__(self) -> None:
        self._sessions: dict[str, BrowserSession] = {}
        self._lock = Lock()

    def create(self, driver: WebDriver, workflow: str, challenge_type: str, page_url: str) -> BrowserSession:
        session = BrowserSession(
            session_id=uuid4().hex,
            driver=driver,
            workflow=workflow,
            challenge_type=challenge_type,
            page_url=page_url,
        )
        with self._lock:
            self._sessions[session.session_id] = session
        return session

    def get(self, session_id: str) -> BrowserSession:
        ...

    def close(self, session_id: str) -> BrowserSession:
        ...

Зачем нужен этот слой:

browser_open_page() возвращает session_id
все следующие инструменты работы с браузером и капчей используют этот session_id
агент может последовательно взаимодействовать с одной и той же страницей

Если не сделать хранилище сеансов, получится либо монолитный скрипт, либо набор несвязанных команд, между которыми не сохраняется состояние.

Шаг 6. Изолировать сервис решения в отдельный модуль

Если сценарий решения напрямую использует библиотеку сервиса внутри слоя сценариев, архитектура очень быстро становится запутанной и неудобной для развития.

Поэтому следующий шаг — вынести сервис в отдельный модуль.

Добавляем app/services/solver_client.py.

Это промежуточный модуль между слоем сценариев и внешним сервисом решения.

Что в нем находится:

RecaptchaV2Request — минимальный набор данных, который нужен сервису решения.

TwoCaptchaSolver.solve_recaptcha_v2(...) — отправляет задачу в сервис и возвращает готовый ответ.

python Copy

from dataclasses import dataclass
from twocaptcha import TwoCaptcha

@dataclass(slots=True)
class RecaptchaV2Request:
    page_url: str
    sitekey: str

class TwoCaptchaSolver:
    def __init__(self, api_key: str) -> None:
        self._client = TwoCaptcha(api_key)

    def solve_recaptcha_v2(self, request: RecaptchaV2Request) -> str:
        result = self._client.recaptcha(
            sitekey=request.sitekey,
            url=request.page_url,
        )
        return str(result["code"])

Польза здесь не только в понятной структуре.

Такой модуль:

отделяет браузерный сценарий от библиотеки конкретного сервиса
упрощает замену сервиса в будущем
делает логику решения заметно чище и понятнее

Шаг 7. Реализовать слой сценариев

Теперь можно собирать основной слой, где соединяются все части системы.

Именно здесь встречаются:

сеанс браузера
логика страницы
решение капчи
единый формат результата

Открытие страницы

Создаем app/workflows/browser.py.

Это модуль со сценариями работы в браузере. Здесь находятся действия, которые работают через сохраненный сеанс, и логика открытия страницы.

Что в нем находится:

browser_open_page(...) — основная функция сценария, которая открывает страницу по URL из задачи и возвращает session_id.

python Copy

def browser_open_page(page_url: str) -> WorkflowResult:
    return _open_page(page_url)

Что происходит внутри _open_page(...):

создается браузер
открывается URL
сеанс регистрируется в session_store
наружу возвращается WorkflowResult

Сценарий решения

Создаем отдельный файл app/workflows/recaptcha_v2.py.

Это модуль сценария для reCAPTCHA v2. Логично держать возможность решения и вспомогательные шаги именно здесь, а не смешивать их с общими действиями браузера.

Что в нем находится:

captcha_solve_recaptcha_v2(...) — основной сценарий решения: получает sitekey, обращается к сервису и вставляет ответ в страницу.

python Copy

def captcha_solve_recaptcha_v2(session: BrowserSession) -> WorkflowResult:
    settings = get_settings()
    sitekey = _get_sitekey(session.driver)
    solver = TwoCaptchaSolver(settings.two_captcha_api_key)
    token = solver.solve_recaptcha_v2(
        RecaptchaV2Request(
            page_url=get_current_url(session.driver),
            sitekey=sitekey,
        )
    )
    _inject_token(session.driver, token)
    ...

Вставка полученного ответа в страницу

В том же файле app/workflows/recaptcha_v2.py делаем внутреннюю вспомогательную функцию для вставки полученного ответа.

Это именно внутренняя функция слоя сценариев, а не отдельный открытый инструмент.

Что в ней происходит:

_inject_token(...) — записывает полученный ответ в g-recaptcha-response и вызывает событие change, чтобы страница увидела новое значение.

python Copy

def _inject_token(driver: WebDriver, token: str) -> None:
    driver.execute_script(
        """
        const responseField = document.getElementById(arguments[0]);
        if (!responseField) {
            throw new Error("reCAPTCHA response field was not found.");
        }

        responseField.value = arguments[1];
        responseField.innerHTML = arguments[1];
        responseField.dispatchEvent(new Event('change', { bubbles: true }));
        """,
        RESPONSE_FIELD_ID,
        token,
    )

Здесь важно понимать границу ответственности: на этом инструмент решения заканчивается. Его задача — снять препятствие, а не довести весь сценарий на странице до финала.

Шаг 8. Дать агенту инструменты для продолжения работы

Если после решения агент должен сам идти дальше, ему нужны обычные возможности работы с браузером.

В app/workflows/browser.py добавляем общие действия для продолжения работы.

Это модуль, который оставляет управление происходящим на странице за агентом уже после решения капчи.

Что в нем находится:

browser_find_elements(...) — помогает агенту найти кандидатов для следующего действия.

browser_click(...) — кликает по выбранному элементу.

browser_extract_json(...) — читает JSON из элемента на странице и сохраняет его как файл с результатом.

python Copy

def browser_find_elements(session_id: str, strategy: str, query: str, limit: int = 5) -> WorkflowResult:
    session = session_store.get(session_id)
    resolved_strategy, resolved_query = _selector_query(strategy, query)
    elements = find_elements(session.driver, resolved_strategy, resolved_query)
    ...

def browser_click(session_id: str, strategy: str, query: str, index: int = 0) -> WorkflowResult:
    session = session_store.get(session_id)
    resolved_strategy, resolved_query = _selector_query(strategy, query)
    elements = find_elements(session.driver, resolved_strategy, resolved_query)
    target = elements[index]
    target.click()
    ...

def browser_extract_json(session_id: str, strategy: str, query: str, index: int = 0) -> WorkflowResult:
    text_result = browser_extract_text(session_id, strategy, query, index)
    extracted_text = text_result.details.get("text")
    payload = json.loads(str(extracted_text))
    verification_result_path = _save_verification_payload(payload, session.session_id)
    ...

Именно на этом этапе система перестает быть просто "скриптом с API сервиса решения" и превращается в архитектуру, с которой агенту проще работать.

Потому что дальше агент уже сам:

ищет кнопку
кликает по ней
извлекает результат
решает, завершен ли сценарий

Шаг 9. И только после этого публиковать инструменты MCP

Самый верхний слой — mcp_server/server.py.

Это отдельный файл, который превращает функции слоя сценариев в инструменты MCP, доступные агенту.

Что в нем находится:

FastMCP(...) — создает объект MCP-сервера.

@mcp.tool() — публикует Python-функции как инструменты, доступные агенту.

Каждая функция MCP здесь — это тонкая обертка над функцией слоя сценариев.

python Copy

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("mcp-captcha-demo")

@mcp.tool()
def browser_open_page(page_url: str) -> dict[str, object | None]:
    return browser_open_page_workflow(page_url).to_dict()

@mcp.tool()
def browser_get_page_state(session_id: str) -> dict[str, object | None]:
    return browser_get_page_state_workflow(session_id).to_dict()

@mcp.tool()
def captcha_solve_recaptcha_v2(session_id: str) -> dict[str, object | None]:
    return captcha_solve_recaptcha_v2_workflow(session_id).to_dict()

Здесь главное — не перетащить логику Selenium наверх.

Слой MCP не должен:

знать про DOM
искать sitekey
вставлять ответ в страницу
решать, где находится кнопка отправки

Его задача проще: делать функции проекта доступными как инструменты MCP, а не выполнять внутреннюю механику браузера.

Почему важен подход с сохранением состояния

В таких проектах быстро становится ясно: агент почти никогда не решает задачу за один вызов.

Обычно цепочка выглядит так:

открыть страницу
посмотреть текущее состояние
запустить решение
продолжить сценарий
получить результат

Значит, состояние браузера должно сохраняться между несколькими вызовами.

Именно для этого в проекте есть session_store, который хранит идентификатор сеанса, открытый браузер, связанный сценарий и данные о текущей странице.

За счет этого агент воспринимает работу как непрерывное взаимодействие с одной и той же страницей, хотя технически вызывает несколько разных инструментов MCP.

Без такого механизма инструменты MCP быстро превращаются в набор разрозненных действий, из которых трудно собрать полноценный рабочий сценарий.

Как выглядит сценарий решения

Когда агент попадает на страницу и видит reCAPTCHA v2, дальше сценарий обычно выглядит так.

Сначала по состоянию страницы агент понимает, что работу блокирует reCAPTCHA v2.

После этого он вызывает captcha_solve_recaptcha_v2.

Внутри сценария решения происходят уже более технические шаги:

из DOM извлекается sitekey
собирается запрос к сервису решения
через отдельный модуль запрашивается ответ
полученный ответ вставляется в g-recaptcha-response

После этого препятствие в виде капчи считается снятым.

И здесь важно не смешивать роли. Инструмент решения не обязан завершать задачу вместо агента. Его работа уже сделана: блокировка снята.

Дальше агент продолжает сценарий через инструменты работы с браузером.

Где здесь роль агента, а где — роль инструмента

Этот вопрос возникает почти всегда.

Если инструмент умеет решать капчу и даже может продолжить часть сценария, что тогда остается агенту?

Ответ простой: ценность агента не в том, чтобы вручную выполнять все технические шаги, а в том, чтобы управлять задачей.

Агент:

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

Инструмент:

выполняет специализированное действие
скрывает технические детали реализации
возвращает структурированный результат

Если агент начнет сам реализовывать сценарий решения, логика Selenium окажется прямо внутри запроса. Это плохая граница ответственности и плохая архитектура.

Как подключить это в Claude Desktop

Для локального показа такой архитектуры удобно использовать Claude Desktop как клиент MCP.

Это не единственный вариант, но для проверки и демонстрации он подходит хорошо.

macOS

На macOS конфиг Claude Desktop обычно лежит здесь:

~/Library/Application Support/Claude/claude_desktop_config.json

В mcpServers нужно добавить запись для локального Python MCP-сервера.

Пример:

json Copy

{
  "mcpServers": {
    "mcp-captcha-demo": {
      "command": "/usr/bin/env",
      "args": [
        "python3",
        "/Users/USERNAME/projects/example_for_mcp/mcp_server/server.py"
      ],
      "env": {
        "PYTHONPATH": "/Users/USERNAME/projects/example_for_mcp",
        "APIKEY_2CAPTCHA": "API-KEY",
        "BROWSER_NAME": "chrome",
        "BROWSER_HEADLESS": "true",
        "SCREENSHOT_DIR": "/Users/USERNAME/projects/example_for_mcp/artifacts/screenshots",
        "RESULT_DIR": "/Users/USERNAME/projects/example_for_mcp/artifacts/results",
        "CAPTURE_STEP_SCREENSHOTS": "false"
      }
    }
  }
}

Windows

На Windows логика та же, меняются только пути и команда запуска Python.

Пример:

json Copy

{
  "mcpServers": {
    "mcp-captcha-demo": {
      "command": "python",
      "args": [
        "C:\\Users\\USERNAME\\projects\\example_for_mcp\\mcp_server\\server.py"
      ],
      "env": {
        "PYTHONPATH": "C:\\Users\\USERNAME\\projects\\example_for_mcp",
        "APIKEY_2CAPTCHA": "API-KEY",
        "BROWSER_NAME": "chrome",
        "BROWSER_HEADLESS": "true",
        "SCREENSHOT_DIR": "C:\\Users\\USERNAME\\projects\\example_for_mcp\\artifacts\\screenshots",
        "RESULT_DIR": "C:\\Users\\USERNAME\\projects\\example_for_mcp\\artifacts\\results",
        "CAPTURE_STEP_SCREENSHOTS": "false"
      }
    }
  }
}

Что важно после правки конфига

После изменения файла нужно:

Полностью закрыть Claude Desktop
Открыть Claude заново
Проверить Settings -> Developer -> Local MCP servers
Убедиться, что сервер подключился без ошибок

После этого в новом чате можно дать команду:

text Copy

Вызови `healthcheck` и `list_available_workflows`.

Если все настроено правильно, Claude увидит инструменты работы с браузером и инструменты решения капчи.

Почему Claude Desktop все равно иногда неудобен

Для локального показа Claude Desktop подходит хорошо. Но у него есть одна особенность: программа может часто спрашивать разрешение на использование инструментов.

С инженерной точки зрения это не проблема сервера. Это особенность самого клиента.

В демонстрации это мешает, потому что вместо непрерывной работы без лишних подтверждений приходится постоянно подтверждать действия:

открыть страницу
посмотреть текущее состояние страницы
запустить решение
кликнуть кнопку

Поэтому, чтобы демонстрация шла спокойно, обычно приходится включать Always allow для инструментов этого сервера.

Из-за этого Claude хорош как локальный клиент для отладки и показа, но не всегда удобен как среда для полностью автономной работы.

Как протестировать эту связку в Claude Desktop

После того как MCP-сервер подключен, агенту уже можно давать не пошаговые команды Selenium, а обычный запрос высокого уровня.

Для локального показа удобно использовать короткий запрос, который:

задает цель
фиксирует правила работы с сеансом браузера
ограничивает формат финального ответа

Пример:

text Copy

Открой страницу https://2captcha.com/demo/recaptcha-v2.

Если на странице есть капча, реши ее через инструмент решения капчи, затем через инструменты работы с браузером доведи страницу до успешного состояния и верни итоговый результат со страницы.

Работай в рамках одного сеанса браузера.
Если details.task_complete = true, считай задачу завершенной.
Если details.should_close_session = true, прекрати работу с этим сеансом.
Не открывай новый сеанс, пока не закрыл текущий.
В конце обязательно закрой браузер.

В финальном ответе верни только:
- verification_payload
- verification_result_path
- screenshot_path

Почему такой запрос полезен:

он показывает практический смысл всей статьи: агенту дают цель, а не набор низкоуровневых команд браузера
он фиксирует критерий завершения задачи
он не дает агенту бесконтрольно плодить новые сеансы браузера
он заставляет вернуть только нужные файлы и данные результата, без лишнего пересказа шагов

Что изменится, если MCP-сервер будет удаленным

Если смотреть на систему уже не как на локальную схему, а как на рабочую систему, быстро возникает следующий вопрос: что меняется, если MCP-сервер не локальный, а удаленный?

Самое интересное в том, что сама идея инструментов почти не меняется.

Меняются в основном:

способ обмена данными
развертывание и поддержка
безопасность

Локально схема выглядит так:

Агент/клиент -> локальный клиент MCP -> MCP-сервер через stdio -> Selenium -> результат

В удаленном варианте она выглядит так:

Агент/клиент -> удаленное подключение к MCP -> MCP-сервер -> Selenium -> результат

То есть:

инструменты остаются примерно теми же
слой сценариев по сути тоже остается тем же
Selenium по-прежнему работает на стороне сервера

Но появляются и новые вопросы:

как выдавать и закрывать session_id
как долго хранить данные и когда их очищать
где хранить файлы с результатом
как организовать сетевое взаимодействие вместо stdio

Поэтому переход к удаленному MCP-серверу — это не столько переписывание логики, сколько переход на другой уровень развертывания и поддержки.

Что в итоге получилось

Главный результат такого подхода не в том, что агент "научился ставить галочку на тестовой странице".

Главный результат в другом:

капча перестает быть кустарной логикой внутри запроса
сценарий решения становится отдельной возможностью
агент остается агентом, а не Selenium-скриптом
система становится понятнее, чище и проще для расширения

В этом и состоит практическая ценность MCP.

Не потому, что он "умеет работать с браузером", а потому, что он позволяет чисто разделить управление сценарием и специализированное исполнение.

Вывод

Будущее нормальной автоматизации строится на разделении обязанностей. LLM должна заниматься только высокоуровневым семантическим планированием. А всю низкоуровневую работу — прохождение проверок, синхронизацию фингерпринтов и обработку таймаутов — нужно выносить в связку удаленного MCP-сервера и API 2Captcha.

Архитектура рабочего проекта держится на трех столпах:

транспорт SSE и примитив Tasks для асинхронного выполнения долгих задач без разрыва соединения;
точный перехват скрытых контекстных переменных вроде cData и pageAction;
идеальная консистентность браузерных отпечатков.

Локальные скрипты не считаются хорошей практикой. MCP-серверы упаковывают в защищенные Docker-контейнеры и запускают прямо внутри CI/CD-пайплайнов, например в GitHub Actions.

Дополнительно растет популярность умных роутеров инструментов, которые сами выбирают, какому узкоспециализированному агенту отдать обход антибот-системы в рантайме.

Инструмент делает пайплайны действительно масштабируемыми и устойчивыми.

Каталог программ

Блог

How-to

Опубликовали готовый MCP сервер для обхода капчи ИИ-агентами