Cómo configurar el cambio automático de IP para un agente de IA a través del servidor MCP y la API de proxy: guía con código

Un parser clásico recibe una lista de proxies, la recorre sin pensar y falla tan pronto como el sistema anti-bot detecta un patrón. El agente de IA funciona de manera diferente: ve el bloqueo, decide cambiar la IP, modifica los encabezados, ralentiza las solicitudes, y todo esto sin su intervención. Vamos a ver cómo conectar el agente, el servidor MCP y el API proxy en una combinación funcional que mantiene las sesiones vivas incluso en sitios protegidos.

Qué es el servidor MCP y por qué lo necesita el parser

MCP (Model Context Protocol) es un protocolo abierto que permite al agente de IA (por ejemplo, basado en Claude o cualquier LLM que soporte tool-calling) acceder a herramientas externas a través de una interfaz única. Antes, para dar acceso a la modelo a una API externa, era necesario escribir un envoltorio personalizado para cada tarea. El servidor MCP lo resuelve de otra manera: describe un conjunto de "herramientas" (tools) — funciones que el agente puede invocar por sí mismo cuando entiende que son necesarias.

En el contexto del scraping, esto se ve así: el agente recibe la tarea "recoge precios de 500 productos de un marketplace". Comienza a hacer solicitudes a través de la herramienta fetch_page, ve una respuesta 403 o un captcha, invoca la herramienta rotate_proxy, obtiene una nueva IP y repite la solicitud — sin intervención del operador. El servidor MCP aquí actúa como un "puente" entre la lógica del agente y la infraestructura real de proxies.

La diferencia clave con un script normal que rota por temporizador: el agente toma la decisión de cambiar la IP en función del contexto — código de respuesta, contenido de la página, velocidad de bloqueo de un dominio específico. Puede mantener una IP para la sesión de autorización y cambiar la IP solo para solicitudes "frías" de recopilación de datos, combinando estrategias sobre la marcha.

Por qué el agente de IA necesita cambiar de IP y no solo una lista de proxies

Si simplemente le das al agente una lista estática de 50 proxies y le pides que los recorra, obtendrás exactamente lo mismo que con un script normal: el patrón de solicitudes se calcula rápidamente por el sistema anti-bot a través de intervalos, encabezados y secuencia de IP. Wildberries, Ozon, Avito y otros grandes sitios utilizan análisis de comportamiento — no solo miran la IP, sino también cómo cambian el User-Agent, las cookies, el fingerprint TLS y la velocidad de las solicitudes en combinación con una dirección específica.

El agente de IA resuelve esta tarea de manera fundamentalmente diferente. Puede:

• Determinar por el código de respuesta (403, 429, redirección a captcha) que la IP actual está "quemada" y solicitar una nueva específicamente para ese dominio;
• Mantener una sesión "pegajosa" (sticky session) en una IP para escenarios de múltiples pasos — por ejemplo, autorización + scraping del panel personal;
• Adaptar la frecuencia de las solicitudes a la reacción del sitio, en lugar de trabajar con un temporizador rígido;
• Combinar el cambio de IP con el cambio de encabezados y la emulación de navegador a través de herramientas anti-detección como Dolphin Anty o AdsPower, si el scraping se realiza a través de un navegador headless.

Es por eso que la combinación "agente + servidor MCP + API proxy" reduce significativamente el porcentaje de bloqueos en comparación con la rotación estática: la decisión de cambiar la IP se toma en función del hecho de bloqueo, no por un horario.

Arquitectura de la combinación: agente → MCP → API proxy → parser

El esquema de trabajo consta de cuatro capas, y es importante entender la zona de responsabilidad de cada una:

1. Agente de IA (LLM con tool-calling) — toma decisiones: qué página parsear a continuación, si necesita cambiar la IP, si debe ralentizar;
2. Servidor MCP — proporciona al agente un conjunto de herramientas: get_page, rotate_ip, check_proxy_status;
3. API del proveedor de proxies — proporciona una nueva IP a solicitud, muestra la geolocalización, tipo de conexión (residencial, móvil, centro de datos);
4. Parser/cliente HTTP — ejecuta la solicitud real al sitio objetivo con los parámetros de proxy obtenidos.

Un punto importante: el servidor MCP no hace scraping del sitio — solo proporciona al agente las capacidades. La lógica de "qué hacer ante un 403" permanece en el modelo, y el servidor MCP solo ejecuta comandos y devuelve resultados. Esta separación permite cambiar el proveedor de proxies o el parser sin reescribir la lógica del agente — solo es necesario actualizar la implementación de la herramienta en el servidor MCP.

Qué tipo de proxy elegir para el scraping del agente

El tipo de proxy afecta directamente la frecuencia con la que el agente tendrá que invocar rotate_ip y cuántas solicitudes pasan sin ser bloqueadas. A continuación, se presenta una comparación de tareas relevantes para el scraping del agente.

Tipo de proxy	Cuándo usarlo para el agente	Ventajas	Desventajas
Proxies residenciales	Scraping de marketplaces, sitios con protección anti-bot (Wildberries, Ozon)	IPs reales de usuarios, bajo porcentaje de bloqueos	Más caros que los de centros de datos, velocidad depende del nodo
Proxies móviles	Trabajo con redes sociales y paneles publicitarios dentro del flujo del agente	Máxima confianza de los sitios, IPs como las de los operadores de telecomunicaciones	Costo más alto, velocidad de rotación limitada
Proxies de centros de datos	Recopilación masiva de datos de sitios sin protección anti-bot estricta	Alta velocidad, bajo costo por IP	Fácilmente detectables, requieren rotación más frecuente a través del agente

En la práctica, el agente puede combinar tipos: comenzar la sesión a través de proxies residenciales para "calentarse", y para eludir técnicamente el rate-limit cambiar a proxies de centros de datos — si la herramienta MCP permite especificar el tipo de IP como parámetro de solicitud.

Configuración paso a paso del servidor MCP con rotación de proxies

Vamos a desglosar una combinación mínima funcional en Python. El servidor MCP describe dos herramientas: obtener una página y cambiar la IP a través de la API del proveedor de proxies.

from mcp.server.fastmcp import FastMCP
import httpx

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

# Almacenamiento de la sesión actual de proxy
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """Solicita una nueva IP al proveedor de proxies a través de su 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:
    """Herramienta para el agente: cambio de dirección IP a una nueva de la país especificado"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP actualizada, región: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """Herramienta para el agente: obtener una página a través del proxy actual"""
    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()

La lógica es simple: el agente llama a fetch_page, ve en la respuesta status_code: 403 y en base a esto decide invocar rotate_ip. No hay reglas de codificación rígidas como "cambiar IP cada 10 solicitudes" — el modelo se orienta en la respuesta real del servidor.

Para producción, este código debería incluir: registro de cada rotación con timestamp, limitación del número de rotaciones por minuto (para que el modelo no "se quede atrapado" en el cambio de IP en lugar de resolver un problema real) y timeouts a nivel de sesión, para que la IP "pegajosa" no se mantenga más tiempo del necesario.

Integración con Claude, LangChain y AutoGPT

MCP se promueve inicialmente como un protocolo para Claude Desktop y Claude API, pero gracias a su especificación abierta, también es compatible con frameworks de terceros. Si estás construyendo un agente en LangChain, el servidor MCP se conecta a través del adaptador langchain-mcp-adapters, que convierte las herramientas MCP en herramientas LangChain comunes — el agente las ve igual que cualquier otra función.

Para agentes similares a AutoGPT, donde no hay soporte nativo para MCP, se puede levantar un puente HTTP local: el servidor MCP funciona como un servicio REST normal, y el agente llama a los endpoints a través de su mecanismo estándar de llamada a funciones. Esto es un poco menos elegante, pero es una opción funcional para equipos que ya están atados a una pila específica.

Vale la pena mencionar la combinación con navegadores anti-detección. Si el scraping no se realiza a través de solicitudes HTTP directas, sino a través de Chrome/Playwright headless (necesario para sitios con protección JS pesada), el servidor MCP puede gestionar no solo los proxies, sino también el perfil del navegador — pasando al agente la herramienta para iniciar el perfil en Dolphin Anty o Octo Browser con el proxy endpoint ya vinculado. En este caso, el agente simplemente indica qué perfil y qué país utilizar, y toda la parte técnica está oculta detrás de la herramienta MCP.

Casos prácticos: Wildberries, Ozon, análisis SMM

Monitoreo de precios en Wildberries. El agente recibe una lista de 2000 SKU, revisa las tarjetas de productos, y al recibir un captcha o una respuesta vacía, cambia la IP a través de proxies residenciales y repite la solicitud con un retraso. A diferencia de un script estático con rotación fija, esta combinación mantiene una velocidad de recopilación estable incluso con el aumento de la protección del lado del sitio — el agente simplemente reacciona "más lentamente" a los patrones de bloqueo, disminuyendo la frecuencia de las solicitudes en lugar de simplemente recorrer IPs hasta que todas sean bloqueadas.

Recopilación de datos de Ozon Seller API e interfaz web. Aquí el agente combina dos modos: las solicitudes autorizadas al panel personal se realizan a través de una IP "pegajosa" durante todo el día laboral (para no activar la verificación de dos factores nuevamente), mientras que el scraping público de las tarjetas de productos se realiza con rotación en cada solicitud.

Análisis SMM de competidores en Instagram y TikTok. El agente recopila estadísticas públicas (me gusta, comentarios, alcance) de una lista de cuentas de competidores, distribuyendo las solicitudes a través de proxies móviles para imitar el tráfico normal de usuarios de la aplicación, y no de un bot con una IP de centro de datos.

En los tres casos, el ahorro de tiempo del equipo no está en el propio scraping (que se podía automatizar antes), sino en la ausencia de la necesidad de escribir y mantener una lógica manual compleja de reintentos, backoffs y reglas de rotación. El agente se adapta a los cambios en la protección del sitio por sí mismo, sin reescribir el código.

Errores comunes al conectar el agente de IA y proxies

• Rotación demasiado frecuente. Si se permite al agente cambiar la IP por cada pequeño problema, el sitio puede comenzar a bloquear el rango completo de la subred debido a la velocidad anómala de cambio de direcciones desde un solo User-Agent.
• Falta de vinculación de cookies a la IP. Si el agente cambia la IP, pero sigue utilizando las cookies antiguas de la sesión, el sistema anti-bot detecta instantáneamente la discrepancia entre la geolocalización y la sesión.
• Sin límite en el número de rotaciones. Sin una limitación, el modelo en un ciclo de errores puede "quemar" todo el límite de tráfico en intentos inútiles ante un problema sistémico (por ejemplo, el sitio está completamente caído, y no bloquea una IP específica).
• Ignorando el fingerprint TLS. Cambiar IP sin cambiar el cliente HTTP no ayuda si el sitio identifica bots por la firma del handshake TLS — aquí se necesita una combinación con un navegador headless, no solo solicitudes httpx.
• Acceso directo del agente a las credenciales "crudas" del proxy. Al dar al modelo acceso directo al nombre de usuario/contraseña de la API del proxy en el prompt, corres el riesgo de filtraciones al registrar los diálogos — utiliza la herramienta MCP como intermediario.

Conclusión

La combinación del agente de IA con el servidor MCP y el API proxy cambia la lógica misma del scraping: en lugar de reglas rígidas de rotación por temporizador, el agente toma decisiones sobre el cambio de IP en función del bloqueo real, combina sesiones "pegajosas" y únicas, y se adapta a un sitio específico sin reescribir el código. Esto es especialmente notable en plataformas con protección activa contra bots — marketplaces, redes sociales, plataformas publicitarias.

Para el scraping de marketplaces y sitios con protección seria, es mejor incorporar desde el principio proxies residenciales en la arquitectura — ofrecen al agente más "espacio" para maniobrar sin un rápido agotamiento de IP. Si la tarea está relacionada con redes sociales y aplicaciones móviles, presta atención a los proxies móviles — generan menos sospechas en los sistemas anti-bot. Y para la recopilación masiva de datos técnicos de fuentes menos protegidas, son adecuados los rápidos y accesibles proxies de centros de datos, que el agente puede usar en combinación con IPs residenciales para optimizar el presupuesto.