Servidor MCP e API proxy: troca automática de IP para agente de IA

Um parser clássico recebe uma lista de proxies, simplesmente a percorre em um ciclo e falha assim que o sistema anti-bot detecta um padrão. O agente de IA funciona de forma diferente: ele vê o bloqueio, toma a decisão de mudar o IP, altera os cabeçalhos, desacelera as solicitações — e tudo isso sem a sua intervenção. Vamos entender como conectar o agente, o servidor MCP e a API proxy em uma configuração funcional que mantém as sessões ativas mesmo em sites protegidos.

O que é o servidor MCP e por que ele é necessário para o parser

MCP (Model Context Protocol) — um protocolo aberto que permite que o agente de IA (por exemplo, baseado em Claude ou qualquer LLM com suporte a chamadas de ferramentas) acesse ferramentas externas através de uma interface única. Anteriormente, para dar acesso à modelo a uma API externa, era necessário escrever uma camada personalizada para cada tarefa. O servidor MCP resolve isso de forma diferente: ele descreve um conjunto de "ferramentas" — funções que o agente pode chamar por conta própria quando entende que são necessárias.

No contexto da extração, isso funciona assim: o agente recebe a tarefa "colete preços de 500 produtos de um marketplace". Ele começa a fazer solicitações através da ferramenta fetch_page, vê a resposta 403 ou um captcha, chama a ferramenta rotate_proxy, obtém um novo IP e repete a solicitação — sem a intervenção do operador. O servidor MCP aqui atua como uma "ponte" entre a lógica do agente e a infraestrutura real do proxy.

A principal diferença em relação a um script comum com rotação por timer: o agente toma a decisão de mudar o IP com base no contexto — código de resposta, conteúdo da página, velocidade de bloqueio de um domínio específico. Ele pode manter um IP para a sessão de autenticação e mudar o IP apenas para solicitações "frias" de coleta de dados, combinando estratégias em tempo real.

Por que o agente de IA precisa trocar de IP, e não apenas uma lista de proxies

Se você simplesmente der ao agente uma lista estática de 50 proxies e pedir para percorrê-los em um ciclo, você obterá exatamente o mesmo que com um script comum: o padrão de solicitações é rapidamente calculado pelo sistema anti-bot com base nos intervalos, cabeçalhos e sequência de IP. Wildberries, Ozon, Avito e outros grandes sites usam análise comportamental — eles observam não apenas o IP, mas também como mudam o User-Agent, cookies, impressão digital TLS e a velocidade das solicitações em conjunto com um endereço específico.

O agente de IA resolve essa tarefa de maneira fundamentalmente diferente. Ele pode:

Determinar pelo código de resposta (403, 429, redirecionamento para captcha) que o IP atual está "queimado" e solicitar um novo especificamente para esse domínio;
Manter uma "sessão pegajosa" (sticky session) em um IP para cenários de múltiplas etapas — por exemplo, autenticação + extração do painel de controle;
Adaptar a frequência das solicitações à reação do site, em vez de trabalhar com um timer rígido;
Combinar a troca de IP com a mudança de cabeçalhos e emulação de navegador através de ferramentas anti-detect como Dolphin Anty ou AdsPower, se a extração for feita através de um navegador headless.

É por isso que a combinação "agente + servidor MCP + API proxy" reduz significativamente a porcentagem de banimentos em comparação com a rotação estática: a decisão de mudar o IP é tomada com base no fato de bloqueio, e não em um cronograma.

Arquitetura da configuração: agente → MCP → API proxy → parser

O esquema de trabalho consiste em quatro camadas, e é importante entender a área de responsabilidade de cada uma:

Agente de IA (LLM com tool-calling) — toma decisões: qual página extrair a seguir, se precisa mudar o IP, se deve desacelerar;
Servidor MCP — fornece ao agente um conjunto de ferramentas: get_page, rotate_ip, check_proxy_status;
API do provedor de proxy — fornece um novo IP sob demanda, mostra geolocalização, tipo de conexão (residencial, móvel, data center);
Parser/cliente HTTP — executa a solicitação real ao site alvo com os parâmetros de proxy obtidos.

Um ponto importante: o servidor MCP não extrai o site — ele apenas fornece ao agente as possibilidades. A lógica "o que fazer ao receber 403" permanece com o modelo, e o servidor MCP apenas executa os comandos e retorna o resultado. Essa separação permite trocar o provedor de proxy ou o parser sem reescrever a lógica do agente — basta atualizar a implementação da ferramenta no servidor MCP.

Dica prática

Não dê ao agente acesso direto à API "crua" do provedor de proxy — encapsule-a em uma ferramenta MCP separada com um conjunto limitado de parâmetros (país, tipo de IP, session_id). Isso reduz o risco de que o modelo gere acidentalmente uma solicitação incorreta e "queime" o limite.

Qual tipo de proxy escolher para a extração do agente

O tipo de proxy influencia diretamente a frequência com que o agente precisará chamar rotate_ip e quantas solicitações passam sem bloqueio. Abaixo está uma comparação de tarefas relevantes para a extração do agente.

Tipo de proxy	Quando usar para o agente	Vantagens	Desvantagens
Proxies residenciais	Extração de marketplaces, sites com proteção anti-bot (Wildberries, Ozon)	IPs reais de usuários, baixa porcentagem de bloqueios	Mais caros que os de data center, velocidade depende do nó
Proxies móveis	Trabalho com redes sociais e painéis de anúncios dentro do fluxo do agente	Máxima confiança dos sites, IPs como os de operadoras de telefonia	Custo mais alto, velocidade de rotação limitada
Proxies de data center	Coleta massiva de dados de sites sem proteção anti-bot rigorosa	Alta velocidade, baixo custo por IP	Fácil de detectar, exigem rotação mais frequente através do agente

Na prática, o agente pode combinar tipos: iniciar a sessão através de proxies residenciais para "aquecimento", e para contornar limites técnicos, mudar para proxies de data center — se a ferramenta MCP permitir especificar o tipo de IP como parâmetro da solicitação.

Configuração passo a passo do servidor MCP com rotação de proxies

Vamos analisar uma configuração mínima funcional em Python. O servidor MCP descreve duas ferramentas: obtenção de página e troca de IP através da API do provedor de proxy.

from mcp.server.fastmcp import FastMCP
import httpx

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

# Armazenamento da sessão atual do proxy
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """Solicita um novo IP ao provedor de proxy através de sua 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:
    """Ferramenta para o agente: troca de endereço IP por um novo do país especificado"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP atualizado, região: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """Ferramenta para o agente: obtenção de página através do proxy atual"""
    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()

A lógica é simples: o agente chama fetch_page, vê na resposta status_code: 403 e com base nisso decide chamar rotate_ip. Nenhum hardcode de regras "trocar IP a cada 10 solicitações" — o modelo se orienta pela resposta real do servidor.

Para produção, é recomendável adicionar a este código: registro de cada rotação com timestamp, limite no número de rotações por minuto (para que o modelo não "fique preso" na troca de IP em vez de resolver um problema real) e timeouts no nível da sessão, para que o IP "pegajoso" não permaneça por mais tempo do que o necessário.

Integração com Claude, LangChain e AutoGPT

O MCP é inicialmente promovido como um protocolo para Claude Desktop e Claude API, mas graças à especificação aberta, também é suportado por frameworks de terceiros. Se você está construindo um agente no LangChain, o servidor MCP se conecta através do adaptador langchain-mcp-adapters, que transforma as ferramentas MCP em ferramentas comuns do LangChain — o agente as vê da mesma forma que qualquer outra função.

Para agentes semelhantes ao AutoGPT, onde não há suporte nativo ao MCP, é possível levantar uma ponte HTTP local: o servidor MCP funciona como um serviço REST comum, e o agente chama os endpoints através de seu mecanismo padrão de chamadas de função. Isso é um pouco menos elegante, mas uma opção viável para equipes que já estão ligadas a uma pilha específica.

Vale mencionar a combinação com navegadores anti-detect. Se a extração não for feita através de solicitações HTTP diretas, mas sim através do Chrome/Playwright headless (necessário para sites com proteção pesada em JavaScript), o servidor MCP pode gerenciar não apenas proxies, mas também o perfil do navegador — passando ao agente a ferramenta para iniciar o perfil no Dolphin Anty ou Octo Browser com o proxy já vinculado. O agente, nesse caso, simplesmente indica qual perfil e qual país usar, enquanto toda a parte técnica está oculta atrás da ferramenta MCP.

Casos práticos: Wildberries, Ozon, análise SMM

Monitoramento de preços no Wildberries. O agente recebe uma lista de 2000 SKU, percorre as páginas dos produtos, e ao receber um captcha ou uma resposta vazia, muda o IP através de proxies residenciais e repete a solicitação com atraso. Ao contrário de um script estático com rotação fixa, essa combinação mantém uma velocidade de coleta estável mesmo com o aumento da proteção do lado da plataforma — o agente simplesmente reage "mais lentamente" aos padrões de bloqueio, reduzindo a frequência das solicitações em vez de apenas percorrer IPs até que todos sejam banidos.

Coleta de dados da API do Ozon Seller e da interface web. Aqui, o agente combina dois modos: solicitações autenticadas ao painel de controle são feitas através de um IP "pegajoso" durante todo o dia de trabalho (para não acionar a autenticação de dois fatores novamente), enquanto a extração pública das páginas dos produtos é feita com rotação a cada solicitação.

Análise SMM de concorrentes no Instagram e TikTok. O agente coleta estatísticas públicas (curtidas, comentários, alcance) de uma lista de contas concorrentes, distribuindo as solicitações através de proxies móveis para simular o tráfego normal dos usuários do aplicativo, e não de um bot com um IP de data center.

Em todos os três casos, a economia de tempo da equipe não está na própria extração (que poderia ser automatizada antes), mas na ausência da necessidade de escrever e manter uma lógica manual complexa de tentativas, backoffs e regras de rotação. O agente se adapta às mudanças na proteção do site por conta própria, sem reescrever o código.

Erros comuns ao conectar o agente de IA e proxies

Rotação muito frequente. Se você permitir que o agente mude de IP a cada movimento, o site pode começar a banir todo o intervalo de sub-rede devido à velocidade anômala de troca de endereços de um único User-Agent.
Falta de vinculação de cookies ao IP. Se o agente muda de IP, mas continua usando os cookies antigos da sessão, o sistema anti-bot imediatamente detecta a discrepância entre a geolocalização e a sessão.
Sem limite no número de rotações. Sem uma limitação, o modelo em um ciclo de erros pode "queimar" todo o limite de tráfego em tentativas inúteis durante um problema sistêmico (por exemplo, o site está fora do ar completamente, e não banindo um IP específico).
Desconsideração da impressão digital TLS. Mudar de IP sem mudar o cliente HTTP não ajuda se o site identifica bots pela assinatura do handshake TLS — aqui é necessária uma combinação com um navegador headless, e não apenas solicitações httpx.
Acesso direto do agente às credenciais "cruas" do proxy. Ao dar ao modelo acesso ao login/senha da API do proxy diretamente no prompt, você corre o risco de vazamento durante o registro de diálogos — use a ferramenta MCP como intermediária.

Conclusão

A combinação do agente de IA com o servidor MCP e a API proxy muda a própria lógica de extração: em vez de regras rígidas de rotação por timer, o agente toma a decisão de mudar o IP com base no bloqueio real, combina sessões "pegajosas" e pontuais, e se adapta a sites específicos sem reescrever o código. Isso é especialmente notável em plataformas com proteção anti-bot ativa — marketplaces, redes sociais, plataformas de anúncios.

Para a extração de marketplaces e sites com proteção séria, é melhor já considerar na arquitetura proxies residenciais — eles dão ao agente mais "espaço" para manobrar sem queimar rapidamente os IPs. Se a tarefa estiver relacionada a redes sociais e aplicativos móveis, preste atenção aos proxies móveis — eles raramente levantam suspeitas nos sistemas anti-bot. E para coleta técnica massiva de dados de fontes menos protegidas, os rápidos e acessíveis proxies de data center são adequados, que o agente pode usar em combinação com IPs residenciais para otimizar o orçamento.