MCP-сервер и API прокси: автосмена IP для ИИ-агента

Классический парсер получает список прокси, тупо перебирает его по кругу и падает, как только антибот-система замечает паттерн. ИИ-агент работает иначе: он видит блокировку, сам принимает решение сменить IP, меняет заголовки, замедляет запросы — и всё это без вашего участия. Разбираемся, как связать агента, MCP-сервер и API прокси в рабочую связку, которая держит сессии живыми даже на защищённых сайтах.

Что такое MCP-сервер и зачем он парсеру

MCP (Model Context Protocol) — открытый протокол, который позволяет ИИ-агенту (например, на базе Claude или любой LLM с поддержкой tool-calling) обращаться к внешним инструментам через единый интерфейс. Раньше, чтобы дать модели доступ к внешнему API, нужно было писать кастомную обёртку под каждую задачу. MCP-сервер решает это иначе: он описывает набор «инструментов» (tools) — функций, которые агент может вызывать сам, когда понимает, что они нужны.

В контексте парсинга это выглядит так: агент получает задачу «собери цены на 500 товаров с маркетплейса». Он начинает делать запросы через инструмент fetch_page, видит ответ 403 или капчу, сам вызывает инструмент rotate_proxy, получает новый IP и повторяет запрос — без вмешательства оператора. MCP-сервер здесь играет роль «моста» между логикой агента и реальной инфраструктурой прокси.

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

Почему ИИ-агенту нужна смена IP, а не просто прокси-лист

Если просто дать агенту статичный список из 50 прокси и попросить перебирать их по кругу, вы получите ровно то же самое, что и с обычным скриптом: паттерн запросов быстро вычисляется антибот-системой по интервалам, заголовкам и последовательности IP. Wildberries, Ozon, Авито и другие крупные площадки используют поведенческий анализ — они смотрят не только на IP, но и на то, как меняются User-Agent, cookies, TLS-фингерпринт и скорость запросов в связке с конкретным адресом.

ИИ-агент решает эту задачу принципиально иначе. Он может:

Определить по коду ответа (403, 429, редирект на капчу), что текущий IP «прожжён», и запросить новый именно для этого домена;
Держать «липкую» сессию (sticky session) на одном IP для многошаговых сценариев — например, авторизация + парсинг личного кабинета;
Адаптировать частоту запросов под реакцию сайта, а не работать по жёсткому таймеру;
Комбинировать смену IP со сменой заголовков и эмуляцией браузера через антидетект-инструменты типа Dolphin Anty или AdsPower, если парсинг идёт через headless-браузер.

Именно поэтому связка «агент + MCP-сервер + API прокси» ощутимо снижает процент банов по сравнению со статичной ротацией: решение о смене IP принимается по факту блокировки, а не по расписанию.

Архитектура связки: агент → MCP → API прокси → парсер

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

ИИ-агент (LLM с tool-calling) — принимает решения: какую страницу парсить дальше, нужно ли менять IP, стоит ли замедлиться;
MCP-сервер — предоставляет агенту набор инструментов: get_page, rotate_ip, check_proxy_status;
API прокси-провайдера — отдаёт новый IP по запросу, показывает геолокацию, тип соединения (резидентный, мобильный, датацентр);
Парсер/HTTP-клиент — исполняет фактический запрос к целевому сайту с полученными параметрами прокси.

Важный момент: MCP-сервер не сам парсит сайт — он только предоставляет агенту возможности. Логика «что делать при 403» остаётся у модели, а MCP-сервер лишь исполняет команды и возвращает результат. Это разделение позволяет менять прокси-провайдера или парсер без переписывания логики агента — достаточно обновить реализацию инструмента на MCP-сервере.

Практический совет

Не давайте агенту прямой доступ к «сырому» API прокси-провайдера — заворачивайте его в отдельный MCP-инструмент с ограниченным набором параметров (страна, тип IP, session_id). Это снижает риск, что модель случайно сгенерирует некорректный запрос и «сожжёт» лимит.

Какой тип прокси выбрать для агентского парсинга

Тип прокси напрямую влияет на то, как часто агенту придётся вызывать rotate_ip и сколько запросов проходит без блокировки. Ниже — сравнение по задачам, актуальным для агентского парсинга.

Тип прокси	Когда использовать агенту	Плюсы	Минусы
Резидентные прокси	Парсинг маркетплейсов, сайтов с антибот-защитой (Wildberries, Ozon)	Реальные IP пользователей, низкий процент блокировок	Дороже датацентровых, скорость зависит от узла
Мобильные прокси	Работа с соцсетями и рекламными кабинетами внутри агентского флоу	Максимальное доверие сайтов, IP как у оператора связи	Более высокая стоимость, ограниченная скорость ротации
Прокси дата-центров	Массовый сбор данных с сайтов без жёсткой антибот-защиты	Высокая скорость, низкая цена за IP	Легко детектируются, чаще требуют ротации через агента

На практике агент может комбинировать типы: начинать сессию через резидентные прокси для «прогрева», а для чисто технического обхода rate-limit переключаться на датацентровые — если MCP-инструмент позволяет указывать тип IP параметром запроса.

Пошаговая настройка MCP-сервера с ротацией прокси

Разберём минимальную рабочую связку на Python. MCP-сервер описывает два инструмента: получение страницы и смена IP через API прокси-провайдера.

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("proxy-parser-agent")

# Хранилище текущей сессии прокси
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """Запрашивает новый IP у прокси-провайдера через его API"""
    response = httpx.get(
        "https://api.proxycove.com/v1/get-endpoint",
        params={"country": country, "type": "residential"},
        headers={"Authorization": "Bearer YOUR_API_KEY"},
    )
    data = response.json()
    return f"http://{data['username']}:{data['password']}@{data['host']}:{data['port']}"

@mcp.tool()
def rotate_ip(country: str = "ru") -> str:
    """Инструмент для агента: смена IP-адреса на новый из указанной страны"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP обновлён, регион: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """Инструмент для агента: получение страницы через текущий прокси"""
    if not current_session["proxy_url"]:
        current_session["proxy_url"] = get_new_proxy(current_session["country"])

    proxies = {"http://": current_session["proxy_url"], "https://": current_session["proxy_url"]}
    try:
        r = httpx.get(url, proxies=proxies, timeout=15)
        return {"status_code": r.status_code, "content": r.text[:3000]}
    except httpx.RequestError as e:
        return {"status_code": 0, "error": str(e)}

if __name__ == "__main__":
    mcp.run()

Логика простая: агент вызывает fetch_page, видит в ответе status_code: 403 и на основе этого сам решает вызвать rotate_ip. Никакого хардкода правил «через 10 запросов менять IP» — модель ориентируется на реальный ответ сервера.

Для продакшена в этот код стоит добавить: логирование каждой ротации с таймстампом, ограничение количества ротаций в минуту (чтобы модель не «зациклилась» на смене IP вместо решения реальной проблемы) и таймауты на уровне сессии, чтобы «липкий» IP не держался дольше нужного.

Интеграция с Claude, LangChain и AutoGPT

MCP изначально продвигается как протокол для Claude Desktop и Claude API, но благодаря открытой спецификации его поддерживают и сторонние фреймворки. Если вы строите агента на LangChain, MCP-сервер подключается через адаптер langchain-mcp-adapters, который превращает MCP-инструменты в обычные LangChain Tools — агент видит их так же, как любую другую функцию.

Для AutoGPT-подобных агентов, где нет нативной поддержки MCP, можно поднять локальный HTTP-мост: MCP-сервер работает как обычный REST-сервис, а агент вызывает эндпоинты через свой стандартный механизм function calling. Это чуть менее элегантно, но рабочий вариант для команд, которые уже завязаны на конкретный стек.

Отдельно стоит сказать про связку с антидетект-браузерами. Если парсинг идёт не через прямые HTTP-запросы, а через headless Chrome/Playwright (нужно для сайтов с тяжёлой JS-защитой), MCP-сервер может управлять не только прокси, но и профилем браузера — передавать агенту инструмент для запуска профиля в Dolphin Anty или Octo Browser с уже привязанным прокси-эндпоинтом. Агент в этом случае просто указывает, какой профиль и какую страну использовать, а вся техническая часть скрыта за MCP-инструментом.

Практические кейсы: Wildberries, Ozon, SMM-аналитика

Мониторинг цен на Wildberries. Агент получает список из 2000 SKU, обходит карточки товаров, при получении капчи или пустого ответа сам меняет IP через резидентные прокси и повторяет запрос с задержкой. В отличие от статичного скрипта с фиксированной ротацией, такая связка держит стабильную скорость сбора даже при усилении защиты на стороне площадки — агент просто «медленнее» реагирует на паттерны блокировки, снижая частоту запросов вместо того, чтобы просто перебирать IP до бана всех сразу.

Сбор данных с Ozon Seller API и веб-интерфейса. Здесь агент комбинирует два режима: авторизованные запросы к личному кабинету идут через «липкий» IP на весь рабочий день (чтобы не триггерить повторную двухфакторку), а публичный парсинг карточек товаров — через ротацию на каждый запрос.

SMM-аналитика по конкурентам в Instagram и TikTok. Агент собирает публичную статистику (лайки, комментарии, охваты) по списку аккаунтов конкурентов, распределяя запросы через мобильные прокси, чтобы имитировать обычный трафик пользователей приложения, а не бота с датацентрового IP.

Во всех трёх случаях экономия времени команды — не в самом парсинге (его можно было автоматизировать и раньше), а в отсутствии необходимости писать и поддерживать сложную ручную логику ретраев, бэкоффов и правил ротации. Агент адаптируется к изменению защиты сайта сам, без переписывания кода.

Частые ошибки при связке ИИ-агента и прокси

Слишком частая ротация. Если разрешить агенту менять IP на каждый чих, сайт может начать банить сам диапазон подсети из-за аномальной скорости смены адресов с одного User-Agent.
Отсутствие привязки cookies к IP. Если агент меняет IP, но продолжает использовать старые cookies сессии, антибот-система моментально фиксирует несоответствие геолокации и сессии.
Нет лимита на количество ротаций. Без ограничения модель в цикле ошибок может «прожечь» весь лимит трафика на бесполезные попытки при системной проблеме (например, сайт лежит целиком, а не банит конкретный IP).
Игнорирование TLS-фингерпринта. Смена IP без смены HTTP-клиента не помогает, если сайт определяет ботов по сигнатуре TLS-хендшейка — тут нужна связка с headless-браузером, а не просто httpx-запросы.
Прямой доступ агента к «сырым» кредам прокси. Давая модели доступ к логину/паролю API прокси напрямую в промпте, вы рискуете утечкой при логировании диалогов — используйте MCP-инструмент как прокладку.

Заключение

Связка ИИ-агента с MCP-сервером и API прокси меняет саму логику парсинга: вместо жёстких правил ротации по таймеру агент принимает решение о смене IP по факту блокировки, комбинирует «липкие» и разовые сессии, подстраивается под конкретный сайт без переписывания кода. Это особенно заметно на площадках с активной антибот-защитой — маркетплейсах, соцсетях, рекламных платформах.

Для парсинга маркетплейсов и сайтов с серьёзной защитой лучше сразу закладывать в архитектуру резидентные прокси — они дают агенту больше «пространства» для маневра без быстрого выгорания IP. Если задача связана с соцсетями и мобильными приложениями, обратите внимание на мобильные прокси — они реже вызывают подозрение у антибот-систем. А для массового технического сбора данных с менее защищённых источников подойдут быстрые и доступные прокси дата-центров, которые агент может использовать в комбинации с резидентными IP для оптимизации бюджета.