MCP-Server und API-Proxy: automatische IP-Wechsel für den KI-Agenten

Ein klassischer Parser erhält eine Liste von Proxys, durchläuft sie einfach und bricht zusammen, sobald das Anti-Bot-System ein Muster erkennt. Der KI-Agent funktioniert anders: Er erkennt die Blockierung, trifft selbst die Entscheidung, die IP zu wechseln, ändert die Header, verlangsamt die Anfragen – und das alles ohne Ihr Eingreifen. Wir klären, wie man den Agenten, den MCP-Server und den API-Proxy in eine funktionierende Kombination bringt, die die Sessions selbst auf geschützten Websites lebendig hält.

Was ist ein MCP-Server und wozu benötigt er der Parser

MCP (Model Context Protocol) ist ein offenes Protokoll, das es dem KI-Agenten (zum Beispiel basierend auf Claude oder jedem LLM mit Unterstützung für Tool-Calling) ermöglicht, über eine einheitliche Schnittstelle auf externe Werkzeuge zuzugreifen. Früher musste man, um der Modell Zugriff auf eine externe API zu gewähren, eine benutzerdefinierte Wrapper für jede Aufgabe schreiben. Der MCP-Server löst dies anders: Er beschreibt eine Reihe von „Werkzeugen“ (tools) – Funktionen, die der Agent selbst aufrufen kann, wenn er erkennt, dass sie benötigt werden.

Im Kontext des Scraping sieht das so aus: Der Agent erhält die Aufgabe „Sammle Preise für 500 Produkte von einem Marktplatz“. Er beginnt, Anfragen über das Werkzeug fetch_page zu stellen, sieht die Antwort 403 oder ein Captcha, ruft selbst das Werkzeug rotate_proxy auf, erhält eine neue IP und wiederholt die Anfrage – ohne Eingreifen des Operators. Der MCP-Server spielt hier die Rolle einer „Brücke“ zwischen der Logik des Agenten und der tatsächlichen Infrastruktur der Proxys.

Der entscheidende Unterschied zu einem normalen Skript mit Rotation nach Zeitplan: Der Agent trifft die Entscheidung über den IP-Wechsel basierend auf dem Kontext – dem Antwortcode, dem Inhalt der Seite, der Geschwindigkeit der Blockierung einer bestimmten Domain. Er kann eine IP für die Autorisierungssitzung halten und die IP nur für „kalte“ Datenabfragen wechseln, indem er Strategien in Echtzeit kombiniert.

Warum der KI-Agent einen IP-Wechsel benötigt und nicht nur eine Proxy-Liste

Wenn man dem Agenten einfach eine statische Liste von 50 Proxys gibt und ihn bittet, sie im Kreis zu durchlaufen, erhält man genau das gleiche Ergebnis wie mit einem normalen Skript: Das Muster der Anfragen wird schnell vom Anti-Bot-System anhand der Intervalle, Header und der Reihenfolge der IPs erkannt. Wildberries, Ozon, Avito und andere große Plattformen nutzen Verhaltensanalysen – sie achten nicht nur auf die IP, sondern auch darauf, wie sich User-Agent, Cookies, TLS-Fingerabdruck und die Geschwindigkeit der Anfragen in Verbindung mit einer bestimmten Adresse ändern.

Der KI-Agent löst diese Aufgabe grundlegend anders. Er kann:

Durch den Antwortcode (403, 429, Umleitung auf Captcha) feststellen, dass die aktuelle IP „verbrannt“ ist, und eine neue speziell für diese Domain anfordern;
Eine „sticky session“ (klebrige Sitzung) auf einer IP für mehrstufige Szenarien halten – zum Beispiel Autorisierung + Scraping des persönlichen Kontos;
Die Frequenz der Anfragen an die Reaktion der Website anpassen, anstatt nach einem strengen Zeitplan zu arbeiten;
Den IP-Wechsel mit dem Wechsel der Header und der Emulation eines Browsers durch Anti-Detect-Tools wie Dolphin Anty oder AdsPower kombinieren, wenn das Scraping über einen Headless-Browser erfolgt.

Genau deshalb reduziert die Kombination „Agent + MCP-Server + API-Proxy“ die Ban-Rate im Vergleich zur statischen Rotation erheblich: Die Entscheidung über den IP-Wechsel wird aufgrund der Blockierung und nicht nach einem Zeitplan getroffen.

Architektur der Kombination: Agent → MCP → API-Proxy → Parser

Das Funktionsschema besteht aus vier Schichten, und es ist wichtig, die Verantwortungsbereiche jeder Schicht zu verstehen:

KI-Agent (LLM mit Tool-Calling) – trifft Entscheidungen: welche Seite als nächstes zu scrapen ist, ob die IP gewechselt werden muss, ob es sinnvoll ist, langsamer zu werden;
MCP-Server – stellt dem Agenten eine Reihe von Werkzeugen zur Verfügung: get_page, rotate_ip, check_proxy_status;
API des Proxy-Anbieters – liefert eine neue IP auf Anfrage, zeigt den Standort, den Verbindungstyp (residential, mobile, datacenter);
Parser/HTTP-Client – führt die tatsächliche Anfrage an die Zielwebsite mit den erhaltenen Proxy-Parametern aus.

Ein wichtiger Punkt: Der MCP-Server scrapt die Website nicht selbst – er bietet dem Agenten nur die Möglichkeiten. Die Logik „was tun bei 403“ bleibt beim Modell, und der MCP-Server führt nur die Befehle aus und gibt das Ergebnis zurück. Diese Trennung ermöglicht es, den Proxy-Anbieter oder den Parser zu wechseln, ohne die Logik des Agenten neu zu schreiben – es reicht aus, die Implementierung des Werkzeugs auf dem MCP-Server zu aktualisieren.

Praktischer Rat

Geben Sie dem Agenten keinen direkten Zugang zu den „rohen“ API-Credentials des Proxy-Anbieters – verpacken Sie sie in ein separates MCP-Werkzeug mit einer begrenzten Parameteranzahl (Land, IP-Typ, session_id). Dies reduziert das Risiko, dass das Modell versehentlich eine ungültige Anfrage generiert und das Limit „verbrennt“.

Welchen Proxy-Typ für das Agenten-Scraping wählen

Der Typ des Proxys beeinflusst direkt, wie oft der Agent rotate_ip aufrufen muss und wie viele Anfragen ohne Blockierung durchgehen. Unten ist ein Vergleich der Aufgaben, die für das Agenten-Scraping relevant sind.

Proxy-Typ	Wann der Agent ihn verwenden sollte	Vorteile	Nachteile
Residential Proxys	Scraping von Marktplätzen, Websites mit Anti-Bot-Schutz (Wildberries, Ozon)	Echte IPs von Nutzern, niedrige Blockierungsrate	Teurer als Rechenzentrumsproxys, Geschwindigkeit hängt vom Knoten ab
Mobile Proxys	Arbeiten mit sozialen Netzwerken und Werbe-Dashboards innerhalb des Agenten-Workflows	Maximales Vertrauen der Websites, IP wie beim Mobilfunkanbieter	Höhere Kosten, begrenzte Rotationsgeschwindigkeit
Rechenzentrumsproxys	Massensammlung von Daten von Websites ohne strengen Anti-Bot-Schutz	Hohe Geschwindigkeit, niedriger Preis pro IP	Leicht erkennbar, erfordern häufiger eine Rotation über den Agenten

In der Praxis kann der Agent die Typen kombinieren: Er kann eine Sitzung über Residential Proxys für das „Aufwärmen“ beginnen und für rein technische Umgehungen von Rate-Limits auf Rechenzentrumsproxys umschalten – wenn das MCP-Werkzeug es erlaubt, den IP-Typ als Anfrageparameter anzugeben.

Schritt-für-Schritt-Einrichtung des MCP-Servers mit Proxy-Rotation

Lassen Sie uns die minimale funktionale Kombination in Python durchgehen. Der MCP-Server beschreibt zwei Werkzeuge: das Abrufen einer Seite und den IP-Wechsel über die API des Proxy-Anbieters.

from mcp.server.fastmcp import FastMCP
import httpx

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

# Speicher für die aktuelle Proxy-Sitzung
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """Fragt eine neue IP beim Proxy-Anbieter über seine API an"""
    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:
    """Werkzeug für den Agenten: Wechsel der IP-Adresse auf eine neue aus dem angegebenen Land"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP aktualisiert, Region: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """Werkzeug für den Agenten: Abrufen einer Seite über den aktuellen 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()

Die Logik ist einfach: Der Agent ruft fetch_page auf, sieht in der Antwort status_code: 403 und entscheidet basierend darauf selbst, rotate_ip aufzurufen. Keine Hardcodierung von Regeln „nach 10 Anfragen IP wechseln“ – das Modell orientiert sich an der tatsächlichen Antwort des Servers.

Für die Produktion sollte dieser Code um Folgendes ergänzt werden: Protokollierung jeder Rotation mit Zeitstempel, Begrenzung der Anzahl der Rotationen pro Minute (damit das Modell sich nicht „verliert“ beim Wechsel der IP anstelle der Lösung eines echten Problems) und Timeouts auf Sitzungsebene, damit die „klebrige“ IP nicht länger gehalten wird als nötig.

Integration mit Claude, LangChain und AutoGPT

MCP wird ursprünglich als Protokoll für Claude Desktop und Claude API beworben, aber dank der offenen Spezifikation wird es auch von Drittanbieter-Frameworks unterstützt. Wenn Sie einen Agenten auf LangChain aufbauen, wird der MCP-Server über den Adapter langchain-mcp-adapters angeschlossen, der MCP-Werkzeuge in normale LangChain Tools umwandelt – der Agent sieht sie wie jede andere Funktion.

Für Agenten, die AutoGPT-ähnlich sind und keine native Unterstützung für MCP haben, kann eine lokale HTTP-Brücke eingerichtet werden: Der MCP-Server funktioniert wie ein gewöhnlicher REST-Service, und der Agent ruft die Endpunkte über seinen Standard-Mechanismus für Funktionsaufrufe auf. Das ist etwas weniger elegant, aber eine funktionierende Lösung für Teams, die bereits an einen bestimmten Stack gebunden sind.

Besonders erwähnenswert ist die Kombination mit Anti-Detect-Browsern. Wenn das Scraping nicht über direkte HTTP-Anfragen, sondern über Headless Chrome/Playwright erfolgt (was für Websites mit schwerem JS-Schutz erforderlich ist), kann der MCP-Server nicht nur die Proxys verwalten, sondern auch das Browser-Profil – er kann dem Agenten ein Werkzeug zur Verfügung stellen, um ein Profil in Dolphin Anty oder Octo Browser mit bereits gebundenem Proxy-Endpunkt zu starten. Der Agent gibt in diesem Fall einfach an, welches Profil und welches Land verwendet werden soll, während der gesamte technische Teil hinter dem MCP-Werkzeug verborgen bleibt.

Praktische Anwendungsfälle: Wildberries, Ozon, SMM-Analyse

Preismonitoring auf Wildberries. Der Agent erhält eine Liste von 2000 SKUs, durchläuft die Produktkarten, ändert bei Erhalt eines Captchas oder einer leeren Antwort selbst die IP über Residential Proxys und wiederholt die Anfrage mit Verzögerung. Im Gegensatz zu einem statischen Skript mit fester Rotation hält eine solche Kombination eine stabile Geschwindigkeit beim Sammeln, selbst bei verstärktem Schutz auf der Plattform – der Agent reagiert einfach „langsamer“ auf Blockierungsmuster, indem er die Frequenz der Anfragen reduziert, anstatt einfach die IPs bis zur vollständigen Sperrung durchzuprobieren.

Datenabfrage über die Ozon Seller API und das Web-Interface. Hier kombiniert der Agent zwei Modi: Autorisierte Anfragen an das persönliche Konto laufen über eine „klebrige“ IP für den gesamten Arbeitstag (um eine erneute Zwei-Faktor-Authentifizierung nicht auszulösen), während das öffentliche Scraping von Produktkarten über Rotation bei jeder Anfrage erfolgt.

SMM-Analyse der Wettbewerber in Instagram und TikTok. Der Agent sammelt öffentliche Statistiken (Likes, Kommentare, Reichweite) für eine Liste von Wettbewerberkonten und verteilt die Anfragen über mobile Proxys, um normalen Nutzerverkehr im App-Traffic zu simulieren, anstatt einen Bot mit einer Rechenzentrums-IP.

In allen drei Fällen liegt die Zeitersparnis des Teams nicht im Scraping selbst (das hätte man auch früher automatisieren können), sondern in der Vermeidung der Notwendigkeit, komplexe manuelle Logik für Retries, Backoffs und Rotationsregeln zu schreiben und zu pflegen. Der Agent passt sich selbstständig an Änderungen im Schutz der Website an, ohne den Code neu zu schreiben.

Häufige Fehler bei der Kombination von KI-Agent und Proxy

Zu häufige Rotation. Wenn man dem Agenten erlaubt, die IP bei jedem Huster zu wechseln, kann die Website beginnen, den gesamten Subnetzbereich aufgrund der anomalen Geschwindigkeit des Wechsels von Adressen mit einem User-Agent zu sperren.
Fehlende Bindung von Cookies an die IP. Wenn der Agent die IP wechselt, aber weiterhin die alten Cookies der Sitzung verwendet, erkennt das Anti-Bot-System sofort die Diskrepanz zwischen Geolokalisierung und Sitzung.
Kein Limit für die Anzahl der Rotationen. Ohne Begrenzung kann das Modell im Fehlerzyklus das gesamte Traffic-Limit für nutzlose Versuche bei einem systematischen Problem „verbrauchen“ (zum Beispiel, wenn die Website insgesamt nicht erreichbar ist und nicht nur eine bestimmte IP sperrt).
Ignorieren des TLS-Fingerabdrucks. Der IP-Wechsel ohne Wechsel des HTTP-Clients hilft nicht, wenn die Website Bots anhand der TLS-Handshake-Signatur identifiziert – hier ist eine Kombination mit einem Headless-Browser erforderlich und nicht nur httpx-Anfragen.
Direkter Zugang des Agenten zu den „rohen“ Proxy-Credentials. Wenn Sie dem Modell direkten Zugang zu den Login-/Passwort-API-Proxys im Prompt gewähren, riskieren Sie eine Leckage bei der Protokollierung von Dialogen – verwenden Sie das MCP-Werkzeug als Vermittler.

Fazit

Die Kombination des KI-Agenten mit dem MCP-Server und dem API-Proxy verändert die Logik des Scraping selbst: Anstatt strenger Rotationsregeln nach Zeitplan trifft der Agent die Entscheidung über den IP-Wechsel basierend auf der Blockierung, kombiniert „klebrige“ und einmalige Sessions und passt sich an die spezifische Website an, ohne den Code neu zu schreiben. Dies ist besonders auffällig auf Plattformen mit aktivem Anti-Bot-Schutz – Marktplätzen, sozialen Netzwerken, Werbeplattformen.

Für das Scraping von Marktplätzen und Websites mit ernsthaftem Schutz sollten Sie von Anfang an Residential Proxys in die Architektur einplanen – sie geben dem Agenten mehr „Spielraum“ für Manöver, ohne dass die IP schnell „verbraucht“ wird. Wenn die Aufgabe mit sozialen Netzwerken und mobilen Anwendungen verbunden ist, achten Sie auf mobile Proxys – sie rufen seltener den Verdacht von Anti-Bot-Systemen hervor. Und für die massenhafte technische Datensammlung von weniger geschützten Quellen eignen sich schnelle und kostengünstige Rechenzentrumsproxys, die der Agent in Kombination mit Residential IPs zur Budgetoptimierung nutzen kann.