Das Model Context Protocol hat zuerst die falsche Hälfte des Problems gelöst, und das ist keine Kritik, sondern nur die Reihenfolge, in der die Dinge passiert sind. MCP gab uns eine saubere, standardisierte Art, ein Sprachmodell mit Tools und Daten zu verbinden. Was es bewusst nicht löst, ist, was passiert, wenn eines dieser Tools ins offene Web greift und das offene Web mit einem 403 zurückgreift.
Wenn du einen MCP-Server gebaut oder betrieben hast, der URLs holt, Seiten scrapet, Suchergebnisse abfragt oder Live-Daten für ein Modell zieht, bist du dieser Mauer wahrscheinlich schon begegnet. Der Server läuft perfekt auf deinem Laptop. Du deployst ihn auf eine Cloud-Box, richtest deinen Agenten darauf, und plötzlich kommt die Hälfte der Fetches als CAPTCHA-Seiten, “Zugriff verweigert” oder Geo-Redirects auf die Seite des falschen Landes zurück. An deinem MCP-Code hat sich nichts geändert. Die IP schon.
In diesem Beitrag geht es um diese Lücke: warum web-holende MCP-Server geblockt werden, warum das kein Problem ist, das MCP lösen sollte, und wie eine Residential-Proxy-Schicht sie mit ein paar Zeilen Code schließt.
Eine kurze Auffrischung, wo der Webzugriff passiert
MCP hat eine saubere Rollentrennung. Ein Host (Claude Desktop, eine IDE, eine Agent-Runtime) betreibt einen MCP-Client, der mit einem oder mehreren MCP-Servern spricht. Jeder Server stellt Tools, Ressourcen und Prompts bereit. Wenn das Modell beschließt, ein Tool zu nutzen, fließt der Aufruf Host → Client → Server, der Server erledigt die eigentliche Arbeit, und das Ergebnis fließt zurück.
Der wichtige Teil für diese Diskussion: der Server ist da, wo reale Seiteneffekte passieren. Wenn du ein fetch-Tool, ein search-Tool oder ein scrape_page-Tool baust, entsteht der ausgehende HTTP-Request im Prozess des MCP-Servers, wo auch immer dieser Prozess gerade läuft. Das Modell stellt den Request nicht. Der Host nicht. Der Server schon.
Die IP, die die Zielwebsite sieht, ist also die IP des MCP-Servers. Und das ist das ganze Problem.
Warum web-holende MCP-Server geblockt werden
Drei Dinge stapeln sich, und sie stapeln sich speziell gegen MCP-Server in einer Weise, wie sie es gegen einen Menschen mit Browser nicht tun.
Dein MCP-Server läuft fast sicher auf einer Datacenter-IP. Wenn du ihn auf AWS, GCP, Fly, Render, einem VPS oder irgendeinem Cloud-Host deployt hast, gehört seine ausgehende IP zu einem Hosting-Provider-ASN. Anti-Bot-Systeme (Cloudflare, Akamai, DataDome) behandeln Datacenter-ASNs als schuldig bis zum Beweis des Gegenteils. Ein Request von einer AWS-IP an eine geschützte Seite wird geflaggt, bevor der Server auch nur einen Header sendet. Das ist der größte Grund, warum aus “lief lokal” ein “ist in Prod geblockt” wird: deine Heimverbindung ist residential, deine Cloud-Box nicht.
Agent-Traffic ist stoßweise und konzentriert. Ein Agent browst nicht wie ein Mensch. Er feuert eine Sequenz von Requests in einem engen Fenster ab, oft an dieselbe Domain, und wird dann still. Von einer einzigen IP liest sich dieses Muster sofort als Automatisierung. Über die Form des AI-Agent-Traffics haben wir separat geschrieben, aber kurz gesagt: Rate-Limits und Verhaltenserkennung, die ein Mensch nie auslöst, löst ein Agent ständig aus, weil aller Traffic von einer Adresse kommt.
Du hast keine Geo-Kontrolle. Dein MCP-Server läuft in einer Region. Wenn das Modell eine Produktseite als deutscher Käufer, ein Suchergebnis als Tokioter Nutzer oder einen Preis als US-Kunde sehen muss, kann ein Single-Region-Server das physisch nicht. Die Seite geolokalisiert die Server-IP und liefert still den Content des falschen Landes. Das Modell argumentiert dann über Daten, die es für korrekt hält und die es nicht sind.
Keines davon ist ein Bug in deinem MCP-Server. Es sind Eigenschaften davon, wo er läuft und welche Form er hat. MCP macht genau seine Aufgabe, den Tool-Aufruf zu transportieren. Es war nie dafür gedacht, die IP zu waschen.
Warum das nicht MCPs Aufgabe ist
Es lohnt sich, das deutlich zu sagen, weil Leute manchmal darauf warten, dass das Protokoll ein Feature bekommt, das nicht kommt. MCP ist ein Protokoll für die Modell-zu-Tool-Kommunikation. Es standardisiert, wie ein Tool beschrieben, aufgerufen wird und wie Ergebnisse zurückkommen. Der Transport zwischen Client und Server (stdio oder Streamable HTTP) betrifft die Verkabelung des Agenten, nicht, wie der Server ins Internet gelangt.
Wie dein fetch-Tool mit der Außenwelt spricht, ist ein Implementierungsdetail deines Servers, genauso wie welche HTTP-Library du nutzt oder wie du die Antwort parst. Das Protokoll sollte es nicht vorschreiben, und tut es nicht. Das heißt, die Webzugriffs-Schicht ist deine Sache. Die gute Nachricht: es ist eine kleine, gut verstandene Schicht, leite die ausgehenden Requests des Servers über Residential-IPs.
Die Lösung: ein Residential-Proxy hinter dem Fetch-Tool
Das Muster ist simpel. Statt dass das Tool deines MCP-Servers einen direkten Request von seiner Datacenter-IP stellt, stellt es den Request über ein Residential-Proxy-Gateway. Die Zielseite sieht eine echte Consumer-IP im richtigen Land, mit dem Vertrauensprofil einer echten Heimverbindung, und der Request geht durch.
Hier ein minimaler Python-MCP-Server mit einem fetch_url-Tool, das über das Shifter-Gateway leitet. Das MCP-Gerüst ist Standard-FastMCP; der entscheidende Teil ist die proxies-Verkabelung am HTTP-Client.
import osimport httpxfrom mcp.server.fastmcp import FastMCP
mcp = FastMCP("web-fetch")
# Ein Gateway-Endpoint, Targeting steckt im Benutzernamen.# Credentials in env halten, nie in der Tool-Definition.USER = os.environ["SHIFTER_USER"] # z. B. "customer-<id>"PASS = os.environ["SHIFTER_PASS"]GATEWAY = "p.shifter.io:443"
def proxy_url(country: str = "us") -> str: return f"http://{USER}-country-{country}:{PASS}@{GATEWAY}"
@mcp.tool()async def fetch_url(url: str, country: str = "us") -> str: """Holt eine URL über eine Residential-IP im angegebenen Land.""" proxies = proxy_url(country) async with httpx.AsyncClient(proxy=proxies, timeout=30) as client: r = await client.get(url, follow_redirects=True) r.raise_for_status() return r.text
if __name__ == "__main__": mcp.run()Das ist die ganze Änderung. Das Modell ruft fetch_url("https://example.com/product", country="de") auf, der Request verlässt das System über eine Residential-IP in Deutschland, und die Seite liefert die deutsche Seite an etwas, das wie ein deutscher Käufer aussieht. Wechsle country, und das Modell sieht dieselbe Seite mit den Augen eines anderen Markts, ohne Redeploy und ohne zweiten Server.
Geo-Targeting ist der Teil, den Agenten am meisten brauchen
Das Block-Problem ist das, was Leute zuerst bemerken, aber das Geo-Problem ist das, was still die Ergebnisse verfälscht. Ein auf eine Region fixierter MCP-Server ist ein LLM, das die Welt durch ein einziges Schlüsselloch betrachtet.
Weil das Shifter-Gateway das Targeting im Benutzernamen kodiert, kann dein fetch-Tool ein country-Argument (oder Bundesland, Stadt, sogar ASN) nehmen und das Modell pro Aufruf wählen lassen. Das macht aus einem Single-Region-Server einen globalen. Ein Recherche-Agent, der Preise über Märkte vergleicht, ein Lokalisierungs-QA-Agent, der prüft, wie eine Seite in fünf Ländern rendert, ein SERP-Monitoring-Agent, der Google-Ergebnisse als lokaler Nutzer zieht, alle brauchen genau das und bekommen es von einem schlichten cloud-gehosteten Fetch-Tool nicht.
Für Multi-Step-Flows, bei denen der Agent über mehrere Aufrufe dieselbe IP braucht (ein Login, dann eine Sequenz authentifizierter Seiten), füge eine Sticky-Session hinzu, indem du eine Session-ID und ein TTL in den Benutzernamen aufnimmst, dieselbe IP hält für die Lebensdauer des TTL:
def sticky_proxy_url(country: str, session: str, ttl: int = 600) -> str: return f"http://{USER}-country-{country}-sid-{session}-ttl-{ttl}:{PASS}@{GATEWAY}"Jetzt kann ein browse_session-Tool eine stabile Identität über die Schritte einer Aufgabe tragen, statt mitten im Flow die IP zu wechseln und jeden Session-Check der Seite auszulösen.
Was du im Hinterkopf behalten solltest
Eine Proxy-Schicht ist kein magischer “nie geblockt”-Schalter, und sie so zu behandeln, ist die Art, wie Leute Bandbreite verschwenden. Ein paar praktische Hinweise:
Cache aggressiv. Agenten holen dieselben URLs ständig erneut. Ein kleiner Cache vor deinem Fetch-Tool senkt die Proxy-Bandbreite (und deine Kosten) drastisch und ist auch fürs Modell schneller. Proxy keinen Request, dessen Antwort du schon hast.
Reiche das Land durch, hardcode es nicht. Der ganze Wert ist die Geo-Kontrolle pro Aufruf. Mach country zu einem Tool-Argument, das das Modell setzen kann, mit einem sinnvollen Default, statt eine Region in den Server zu backen.
Respektiere das Ziel. Ein Proxy ändert, von welcher IP der Request kommt, nicht, ob du ihn stellen solltest. Halte robots.txt ein, wo sie tragend ist, halte Request-Raten vernünftig, und hämmere keine Seite, nur weil die Blocks weg sind. Unsere Acceptable Use Policy ist die maßgebliche Quelle dafür, was erlaubt ist.
Halte Credentials aus dem Tool-Schema heraus. Proxy-Benutzername und -Passwort leben in Umgebungsvariablen auf dem Server, nie in der Tool-Definition, die das Modell sieht. Das Modell soll ein Land wählen, nicht dein Gateway-Passwort halten.
Datacenter ist okay für ungeschützte, geo-neutrale Fetches. Wenn ein Tool nur deine eigenen APIs oder öffentliche Endpoints trifft, die nicht blocken und nicht geolokalisieren, braucht es den Proxy nicht. Reserviere die Residential-Schicht für die Open-Web-Fetches, die tatsächlich auf Blocks treffen oder Geo brauchen. (Für einen vollständigeren Vergleich, wann welcher IP-Typ passt, siehe Residential- vs Datacenter-Proxies.)
FAQ
Hat MCP eingebauten Proxy-Support? Nein, und sollte es auch nicht. MCP standardisiert die Modell-zu-Tool-Kommunikation, nicht, wie ein Tool ins Internet gelangt. Ausgehender Webzugriff ist ein Implementierungsdetail deines Servers. Du fügst einen Proxy auf HTTP-Client-Ebene innerhalb des Tools hinzu, genau wie oben gezeigt.
Warum betreibe ich meinen MCP-Server nicht einfach über eine Residential-Verbindung? Könntest du, aber das skaliert nicht, gibt dir keine Geo-Kontrolle pro Request und koppelt die Zuverlässigkeit deines Agenten an die Uptime einer Heimverbindung und eine einzige IP. Ein Residential-Proxy-Gateway gibt dir einen großen, rotierenden Pool und Land-Targeting pro Aufruf, ohne etwas auf einer Residential-Leitung zu hosten.
Verhindert ein Proxy komplett, dass mein Agent geblockt wird? Er beseitigt die größte Ursache (die Datacenter-IP) und gibt dir Geo-Kontrolle, aber Verhalten zählt weiter. Stoßweise Request-Muster, fehlende oder inkonsistente Header und das Ignorieren von Rate-Limits können dich weiterhin flaggen. Der Proxy ist notwendig, nicht hinreichend, kombiniere ihn mit vernünftigem Request-Verhalten.
Funktioniert das auch mit TypeScript-MCP-Servern? Ja. Das Konzept ist identisch, konfiguriere deinen HTTP-Client (fetch mit einem Agent, axios, undici, got), um über das Gateway zu leiten. Das Format der Proxy-URL und das Targeting pro Request sind unabhängig von der Sprache gleich.
Kann das Modell das Land pro Request wählen?
Ja, das ist das empfohlene Muster. Exponiere country (und optional Bundesland/Stadt) als Tool-Argument mit Default. Das Modell setzt es je nach Aufgabe, und dein Server kodiert es spontan in den Proxy-Benutzernamen.
Ändert das Routen über einen Proxy, wie Shifter mir berechnet? Nein. Es ist das Standard-Residential-Gateway zum üblichen Preis pro GB (Pricing). Ein MCP-Server ist nur ein weiterer Client, der sich mit demselben Endpoint verbindet. Bandbreite ist Bandbreite.
Das Fazit
MCP ist eine saubere Antwort auf “wie ruft ein Modell ein Tool auf”. Es war nie dafür gedacht, “wie erreicht dieses Tool ein feindliches offenes Web von einer geflaggten Datacenter-IP im falschen Land” zu beantworten. Diese zweite Frage ist real, sie ist deine zu beantworten, und die Antwort ist eine dünne Residential-Proxy-Schicht hinter deinen Fetch-Tools.
Die Verkabelung sind ein paar Zeilen. Der Lohn ist ein MCP-Server, dessen Web-Tools in Produktion tatsächlich funktionieren, die Daten des richtigen Landes zurückgeben und nicht beim ersten Mal umfallen, wenn ein Agent sie auf eine geschützte Seite richtet. Wenn du web-verbundene Agenten baust, starte mit dem Residential-Gateway und setze es vom ersten Tag an hinter deine Tools, das ist viel einfacher, als es nachzurüsten, nachdem die Blocks angefangen haben. Mehr dazu, wie du Agenten zuverlässigen Webzugriff gibst, in den besten Proxies für AI-Agenten, die das Web browsen.