MCP-server e API proxy: cambio automatico dell'IP per l'agente IA

Un parser classico riceve un elenco di proxy, li scorre in modo circolare e si blocca non appena il sistema anti-bot rileva un pattern. L'agente AI funziona in modo diverso: vede il blocco, decide autonomamente di cambiare IP, modifica gli header, rallenta le richieste — e tutto questo senza il tuo intervento. Vediamo come collegare l'agente, il server MCP e l'API proxy in un sistema operativo che mantiene le sessioni attive anche su siti protetti.

Che cos'è un server MCP e a cosa serve al parser

MCP (Model Context Protocol) è un protocollo aperto che consente all'agente AI (ad esempio, basato su Claude o qualsiasi LLM con supporto per tool-calling) di accedere a strumenti esterni tramite un'interfaccia unica. In passato, per dare accesso alla modello a un'API esterna, era necessario scrivere un wrapper personalizzato per ogni compito. Il server MCP risolve questo in modo diverso: descrive un insieme di "strumenti" (tools) — funzioni che l'agente può chiamare autonomamente quando capisce che sono necessarie.

Nel contesto del parsing, questo appare così: l'agente riceve il compito "raccogli i prezzi di 500 prodotti da un marketplace". Inizia a fare richieste tramite lo strumento fetch_page, vede una risposta 403 o un captcha, chiama autonomamente lo strumento rotate_proxy, ottiene un nuovo IP e ripete la richiesta — senza l'intervento dell'operatore. Il server MCP qui funge da "ponte" tra la logica dell'agente e la reale infrastruttura dei proxy.

La chiave differenza rispetto a uno script normale con rotazione basata su timer: l'agente decide di cambiare IP in base al contesto — codice di risposta, contenuto della pagina, velocità di blocco di un dominio specifico. Può mantenere un IP per la sessione di autenticazione e cambiare IP solo per le richieste "fredde" di raccolta dati, combinando strategie al volo.

Perché l'agente AI ha bisogno di cambiare IP, e non solo di una lista di proxy

Se semplicemente dai all'agente una lista statica di 50 proxy e chiedi di scorrerli in modo circolare, otterrai esattamente lo stesso risultato di uno script normale: il pattern delle richieste viene rapidamente calcolato dal sistema anti-bot in base agli intervalli, agli header e alla sequenza degli IP. Wildberries, Ozon, Avito e altri grandi marketplace utilizzano l'analisi comportamentale — non guardano solo all'IP, ma anche a come cambiano User-Agent, cookies, fingerprint TLS e velocità delle richieste in relazione a un indirizzo specifico.

L'agente AI affronta questo compito in modo fondamentalmente diverso. Può:

Determinare dal codice di risposta (403, 429, reindirizzamento a captcha) che l'IP attuale è "bruciato" e richiedere un nuovo IP specificamente per quel dominio;
Mantenere una sessione "appiccicosa" (sticky session) su un IP per scenari multi-step — ad esempio, autenticazione + parsing del pannello personale;
Adattare la frequenza delle richieste in base alla reazione del sito, invece di lavorare su un timer rigido;
Combinare il cambio di IP con il cambio di header e l'emulazione del browser tramite strumenti anti-detect come Dolphin Anty o AdsPower, se il parsing avviene tramite un browser headless.

È proprio per questo che la combinazione "agente + server MCP + API proxy" riduce significativamente la percentuale di ban rispetto alla rotazione statica: la decisione di cambiare IP viene presa in base al blocco effettivo, non secondo un programma.

Architettura del sistema: agente → MCP → API proxy → parser

Lo schema di lavoro consiste in quattro livelli, ed è importante comprendere l'area di responsabilità di ciascuno:

Agente AI (LLM con tool-calling) — prende decisioni: quale pagina parsare successivamente, se è necessario cambiare IP, se vale la pena rallentare;
Server MCP — fornisce all'agente un insieme di strumenti: get_page, rotate_ip, check_proxy_status;
API del fornitore di proxy — fornisce un nuovo IP su richiesta, mostra la geolocalizzazione, il tipo di connessione (residenziale, mobile, data center);
Parser/HTTP-client — esegue la richiesta effettiva al sito target con i parametri proxy ottenuti.

Un punto importante: il server MCP non esegue il parsing del sito — fornisce solo all'agente le possibilità. La logica "cosa fare in caso di 403" rimane nel modello, mentre il server MCP esegue solo i comandi e restituisce il risultato. Questa separazione consente di cambiare fornitore di proxy o parser senza riscrivere la logica dell'agente — è sufficiente aggiornare l'implementazione dello strumento sul server MCP.

Consiglio pratico

Non dare all'agente accesso diretto all'API "grezza" del fornitore di proxy — incapsulalo in uno strumento MCP separato con un insieme limitato di parametri (paese, tipo di IP, session_id). Questo riduce il rischio che il modello generi accidentalmente una richiesta errata e "bruci" il limite.

Quale tipo di proxy scegliere per il parsing dell'agente

Il tipo di proxy influisce direttamente su quanto spesso l'agente dovrà chiamare rotate_ip e quante richieste passano senza blocco. Di seguito è riportato un confronto per compiti rilevanti per il parsing dell'agente.

Tipo di proxy	Quando usarlo per l'agente	Vantaggi	Svantaggi
Proxy residenziali	Parsing di marketplace, siti con protezione anti-bot (Wildberries, Ozon)	IP reali degli utenti, bassa percentuale di blocchi	Più costosi dei data center, velocità dipendente dal nodo
Proxy mobili	Lavoro con social media e pannelli pubblicitari all'interno del flusso dell'agente	Massimo fiducia dei siti, IP come quelli dell'operatore telefonico	Costo più elevato, velocità di rotazione limitata
Proxy dei data center	Raccolta massiva di dati da siti senza protezione anti-bot rigida	Alta velocità, basso costo per IP	Facilmente rilevabili, richiedono più spesso rotazione tramite l'agente

Nella pratica, l'agente può combinare i tipi: iniziare la sessione tramite proxy residenziali per "riscaldarsi", e per il bypass tecnico del rate-limit passare a quelli dei data center — se lo strumento MCP consente di specificare il tipo di IP come parametro della richiesta.

Impostazione passo-passo del server MCP con rotazione dei proxy

Analizziamo una combinazione minima funzionante in Python. Il server MCP descrive due strumenti: ottenere una pagina e cambiare IP tramite l'API del fornitore di proxy.

from mcp.server.fastmcp import FastMCP
import httpx

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

# Magazzino della sessione proxy attuale
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """Richiede un nuovo IP al fornitore di proxy tramite la 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:
    """Strumento per l'agente: cambio dell'indirizzo IP con uno nuovo proveniente dal paese specificato"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP aggiornato, regione: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """Strumento per l'agente: ottenere una pagina tramite l'attuale proxy"""
    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 logica è semplice: l'agente chiama fetch_page, vede nella risposta status_code: 403 e sulla base di questo decide autonomamente di chiamare rotate_ip. Nessun hardcoding di regole "cambia IP dopo 10 richieste" — il modello si orienta sulla risposta reale del server.

Per la produzione, in questo codice è opportuno aggiungere: logging di ogni rotazione con timestamp, limitazione del numero di rotazioni al minuto (per evitare che il modello si "incastri" nel cambio di IP invece di risolvere un problema reale) e timeout a livello di sessione, in modo che l'IP "appiccicoso" non rimanga più a lungo del necessario.

Integrazione con Claude, LangChain e AutoGPT

Il MCP è inizialmente promosso come protocollo per Claude Desktop e Claude API, ma grazie alla specifica aperta è supportato anche da framework di terze parti. Se stai costruendo un agente su LangChain, il server MCP si collega tramite l'adattatore langchain-mcp-adapters, che trasforma gli strumenti MCP in normali LangChain Tools — l'agente li vede come qualsiasi altra funzione.

Per agenti simili a AutoGPT, dove non c'è supporto nativo per MCP, è possibile creare un ponte HTTP locale: il server MCP funziona come un normale servizio REST, e l'agente chiama gli endpoint tramite il suo meccanismo standard di function calling. Questo è un'opzione leggermente meno elegante, ma funzionante per i team già legati a uno stack specifico.

Vale la pena menzionare la combinazione con browser anti-detect. Se il parsing avviene non tramite richieste HTTP dirette, ma tramite headless Chrome/Playwright (necessario per siti con protezione JS pesante), il server MCP può gestire non solo i proxy, ma anche il profilo del browser — passando all'agente uno strumento per avviare un profilo in Dolphin Anty o Octo Browser con il proxy già collegato. In questo caso, l'agente indica semplicemente quale profilo e quale paese utilizzare, mentre tutta la parte tecnica è nascosta dietro lo strumento MCP.

Casi pratici: Wildberries, Ozon, analisi SMM

Monitoraggio dei prezzi su Wildberries. L'agente riceve un elenco di 2000 SKU, visita le schede dei prodotti, e quando riceve un captcha o una risposta vuota cambia autonomamente IP tramite proxy residenziali e ripete la richiesta con un ritardo. A differenza di uno script statico con rotazione fissa, tale combinazione mantiene una velocità di raccolta stabile anche con un aumento della protezione da parte della piattaforma — l'agente semplicemente reagisce "più lentamente" ai pattern di blocco, riducendo la frequenza delle richieste invece di scorrere gli IP fino a esaurire tutti.

Raccolta dati dall'API Ozon Seller e dall'interfaccia web. Qui l'agente combina due modalità: le richieste autorizzate al pannello personale avvengono tramite un IP "appiccicoso" per tutta la giornata lavorativa (per non attivare nuovamente la doppia autenticazione), mentre il parsing pubblico delle schede dei prodotti avviene con rotazione ad ogni richiesta.

Analisi SMM sui concorrenti in Instagram e TikTok. L'agente raccoglie statistiche pubbliche (like, commenti, copertura) su un elenco di account concorrenti, distribuendo le richieste tramite proxy mobili, per simulare il traffico normale degli utenti dell'app, e non di un bot con un IP di data center.

In tutti e tre i casi, il risparmio di tempo per il team non è nel parsing stesso (che poteva essere automatizzato anche prima), ma nell'assenza della necessità di scrivere e mantenere una logica complessa di retry, backoff e regole di rotazione. L'agente si adatta autonomamente ai cambiamenti nella protezione del sito, senza riscrivere il codice.

Errori comuni nell'integrazione dell'agente AI e dei proxy

Rotazione troppo frequente. Se si consente all'agente di cambiare IP ad ogni piccola variazione, il sito potrebbe iniziare a bloccare l'intero range della sottorete a causa della velocità anomala di cambio degli indirizzi da un singolo User-Agent.
Assenza di associazione dei cookies all'IP. Se l'agente cambia IP, ma continua a utilizzare i vecchi cookies della sessione, il sistema anti-bot rileva immediatamente la discrepanza tra geolocalizzazione e sessione.
Nessun limite sul numero di rotazioni. Senza limitazione, il modello in un ciclo di errori può "bruciare" tutto il limite di traffico in tentativi inutili in caso di problema sistemico (ad esempio, il sito è completamente giù, e non blocca un IP specifico).
Ignorare il fingerprint TLS. Cambiare IP senza cambiare il client HTTP non aiuta, se il sito identifica i bot tramite la firma del handshake TLS — qui è necessaria una combinazione con un browser headless, e non solo richieste httpx.
Accesso diretto dell'agente a credenziali "grezze" dei proxy. Dando al modello accesso diretto a login/password dell'API proxy nel prompt, si rischia una fuga di dati durante il logging delle conversazioni — utilizza lo strumento MCP come intermediario.

Conclusione

La combinazione dell'agente AI con il server MCP e l'API proxy cambia la logica stessa del parsing: invece di regole rigide di rotazione basate su timer, l'agente prende decisioni sul cambio di IP in base al blocco effettivo, combina sessioni "appiccicose" e singole, adattandosi a siti specifici senza riscrivere il codice. Questo è particolarmente evidente su piattaforme con attiva protezione anti-bot — marketplace, social media, piattaforme pubblicitarie.

Per il parsing di marketplace e siti con protezione seria, è meglio prevedere fin da subito nella architettura proxy residenziali — forniscono all'agente maggiore "spazio" di manovra senza un rapido esaurimento degli IP. Se il compito è legato ai social media e alle applicazioni mobili, presta attenzione ai proxy mobili — suscitano meno sospetti nei sistemi anti-bot. E per la raccolta massiva di dati tecnici da fonti meno protette, sono adatti i veloci e accessibili proxy dei data center, che l'agente può utilizzare in combinazione con IP residenziali per ottimizzare il budget.