कैसे MCP-सर्वर और प्रॉक्सी API के माध्यम से AI-एजेंट के लिए IP स्वचालित परिवर्तन सेट करें: कोड के साथ गाइड

क्लासिक पार्सर एक प्रॉक्सी की सूची प्राप्त करता है, उसे बस घुमाता है और जैसे ही एंटी-बॉट सिस्टम पैटर्न को देखता है, वह गिर जाता है। AI-एजेंट अलग तरीके से काम करता है: वह ब्लॉक को देखता है, खुद निर्णय लेता है कि IP बदलना है, हेडर बदलता है, अनुरोधों को धीमा करता है — और यह सब आपके हस्तक्षेप के बिना। हम समझते हैं कि एजेंट, MCP-सर्वर और API प्रॉक्सी को एक कार्यात्मक संयोजन में कैसे जोड़ा जाए, जो सुरक्षित साइटों पर भी सत्रों को जीवित रखता है।

MCP-सर्वर क्या है और यह पार्सर के लिए क्यों आवश्यक है

MCP (Model Context Protocol) — एक ओपन प्रोटोकॉल है जो AI-एजेंट (जैसे, Claude या किसी भी LLM के आधार पर जो टूल-कॉलिंग का समर्थन करता है) को एकल इंटरफेस के माध्यम से बाहरी उपकरणों से संपर्क करने की अनुमति देता है। पहले, बाहरी API तक पहुंच देने के लिए, प्रत्येक कार्य के लिए कस्टम लपेटन लिखना आवश्यक था। MCP-सर्वर इसे अलग तरीके से हल करता है: यह "उपकरणों" (tools) का एक सेट वर्णित करता है — कार्यों की जो एजेंट खुद तब कॉल कर सकता है जब उसे पता हो कि उनकी आवश्यकता है।

पार्सिंग के संदर्भ में यह इस प्रकार दिखता है: एजेंट को "मार्केटप्लेस से 500 उत्पादों की कीमतें इकट्ठा करें" का कार्य मिलता है। वह fetch_page उपकरण के माध्यम से अनुरोध करना शुरू करता है, 403 प्रतिक्रिया या कैप्चा देखता है, स्वयं rotate_proxy उपकरण को कॉल करता है, नया IP प्राप्त करता है और अनुरोध को दोहराता है — बिना ऑपरेटर के हस्तक्षेप के। MCP-सर्वर यहां एजेंट की लॉजिक और प्रॉक्सी की वास्तविक अवसंरचना के बीच "पुल" की भूमिका निभाता है।

सामान्य टाइमर के अनुसार रोटेशन वाले स्क्रिप्ट से मुख्य अंतर: एजेंट IP परिवर्तन का निर्णय संदर्भ के आधार पर लेता है — प्रतिक्रिया कोड, पृष्ठ की सामग्री, विशेष डोमेन की ब्लॉकिंग की गति। वह एक IP को प्रमाणीकरण सत्र के लिए रख सकता है और केवल डेटा संग्रह के "ठंडे" अनुरोधों के लिए IP बदल सकता है, उड़ान में रणनीतियों को संयोजित कर सकता है।

AI-एजेंट को IP परिवर्तन की आवश्यकता क्यों है, केवल प्रॉक्सी सूची नहीं

यदि आप बस एजेंट को 50 प्रॉक्सी की एक स्थिर सूची देते हैं और उन्हें घुमाने के लिए कहते हैं, तो आपको वही मिलेगा जो सामान्य स्क्रिप्ट के साथ होता है: अनुरोधों का पैटर्न एंटी-बॉट सिस्टम द्वारा जल्दी से गणना की जाती है, जो अंतराल, हेडर और IP की अनुक्रम के आधार पर होती है। Wildberries, Ozon, Avito और अन्य बड़े प्लेटफार्म व्यवहारिक विश्लेषण का उपयोग करते हैं — वे केवल IP पर नहीं देखते हैं, बल्कि यह भी देखते हैं कि User-Agent, कुकीज़, TLS-फिंगरप्रिंट और अनुरोधों की गति कैसे बदलती है।

AI-एजेंट इस समस्या को मौलिक रूप से अलग तरीके से हल करता है। वह कर सकता है:

• प्रतिक्रिया कोड (403, 429, कैप्चा पर रीडायरेक्ट) के आधार पर यह निर्धारित करना कि वर्तमान IP "प्रदूषित" है, और विशेष रूप से उस डोमेन के लिए नया अनुरोध करना;
• कई चरणों के परिदृश्यों के लिए एक IP पर "चिपचिपा" सत्र (sticky session) बनाए रखना — जैसे, प्रमाणीकरण + व्यक्तिगत खाते का पार्सिंग;
• साइट की प्रतिक्रिया के अनुसार अनुरोधों की आवृत्ति को अनुकूलित करना, न कि कठोर टाइमर के अनुसार काम करना;
• IP परिवर्तन को हेडर परिवर्तन और एंटी-डिटेक्ट उपकरणों जैसे Dolphin Anty या AdsPower के माध्यम से ब्राउज़र अनुकरण के साथ संयोजित करना, यदि पार्सिंग हेडलेस ब्राउज़र के माध्यम से हो रही है।

यही कारण है कि "एजेंट + MCP-सर्वर + API प्रॉक्सी" का संयोजन स्थिर रोटेशन की तुलना में बैन के प्रतिशत को काफी कम करता है: IP परिवर्तन का निर्णय ब्लॉकिंग के तथ्य के आधार पर लिया जाता है, न कि अनुसूची के अनुसार।

संयोजन की आर्किटेक्चर: एजेंट → MCP → API प्रॉक्सी → पार्सर

काम करने की योजना चार स्तरों में विभाजित है, और प्रत्येक की जिम्मेदारी को समझना महत्वपूर्ण है:

1. AI-एजेंट (टूल-कॉलिंग के साथ LLM) — निर्णय लेता है: अगली कौन सी पृष्ठ को पार्स करना है, क्या IP बदलना है, क्या धीमा होना चाहिए;
2. MCP-सर्वर — एजेंट को उपकरणों का एक सेट प्रदान करता है: get_page, rotate_ip, check_proxy_status;
3. API प्रॉक्सी प्रदाता — अनुरोध पर नया IP प्रदान करता है, भौगोलिक स्थान, कनेक्शन का प्रकार (रिसिडेंशियल, मोबाइल, डेटा सेंटर) दिखाता है;
4. पार्सर/HTTP-क्लाइंट — लक्षित साइट पर प्राप्त प्रॉक्सी पैरामीटर के साथ वास्तविक अनुरोध करता है।

एक महत्वपूर्ण बिंदु: MCP-सर्वर स्वयं साइट को पार्स नहीं करता है — वह केवल एजेंट को संभावनाएँ प्रदान करता है। "403 पर क्या करना है" की लॉजिक मॉडल के पास रहती है, और MCP-सर्वर केवल आदेशों को निष्पादित करता है और परिणाम लौटाता है। यह विभाजन प्रॉक्सी प्रदाता या पार्सर को एजेंट की लॉजिक को फिर से लिखे बिना बदलने की अनुमति देता है — बस MCP-सर्वर पर उपकरण के कार्यान्वयन को अपडेट करना पर्याप्त है।

एजेंट पार्सिंग के लिए किस प्रकार की प्रॉक्सी चुनें

प्रॉक्सी का प्रकार सीधे तौर पर इस पर प्रभाव डालता है कि एजेंट को rotate_ip को कितनी बार कॉल करना होगा और कितने अनुरोध बिना ब्लॉकिंग के गुजरते हैं। नीचे एजेंट पार्सिंग के लिए प्रासंगिक कार्यों के अनुसार तुलना की गई है।

प्रॉक्सी का प्रकार	एजेंट को कब उपयोग करना चाहिए	फायदे	नुकसान
रिसिडेंशियल प्रॉक्सी	मार्केटप्लेस, एंटी-बॉट सुरक्षा वाली साइटों (Wildberries, Ozon) का पार्सिंग	उपयोगकर्ताओं के वास्तविक IP, कम ब्लॉकिंग प्रतिशत	डेटा सेंटर की तुलना में महंगे, गति नोड पर निर्भर करती है
मोबाइल प्रॉक्सी	सोशल मीडिया और विज्ञापन डैशबोर्ड के साथ एजेंट के प्रवाह के भीतर काम करना	साइटों पर अधिकतम विश्वास, ऑपरेटर के रूप में IP	उच्च लागत, रोटेशन की सीमित गति
डेटा सेंटर प्रॉक्सी	कठोर एंटी-बॉट सुरक्षा के बिना साइटों से बड़े पैमाने पर डेटा संग्रह	उच्च गति, IP की कम कीमत	आसानी से पहचान लिए जाते हैं, अक्सर एजेंट के माध्यम से रोटेशन की आवश्यकता होती है

व्यावहारिक रूप से, एजेंट प्रकारों को संयोजित कर सकता है: "गर्म" करने के लिए रिसिडेंशियल प्रॉक्सी के माध्यम से सत्र शुरू करना, और तकनीकी रूप से रेट-सीमा को बायपास करने के लिए डेटा सेंटर पर स्विच करना — यदि MCP-उपकरण अनुरोध पैरामीटर के रूप में IP का प्रकार निर्दिष्ट करने की अनुमति देता है।

प्रॉक्सी रोटेशन के साथ MCP-सर्वर का चरण-दर-चरण सेटअप

हम Python में न्यूनतम कार्यात्मक संयोजन का विश्लेषण करते हैं। MCP-सर्वर दो उपकरणों का वर्णन करता है: पृष्ठ प्राप्त करना और API प्रॉक्सी प्रदाता के माध्यम से IP बदलना।

from mcp.server.fastmcp import FastMCP
import httpx

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

# वर्तमान प्रॉक्सी सत्र का भंडार
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """प्रॉक्सी प्रदाता से नया IP प्राप्त करता है उसके 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:
    """एजेंट के लिए उपकरण: निर्दिष्ट देश से नए IP पते पर स्विच करना"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP अपडेट किया गया, क्षेत्र: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """एजेंट के लिए उपकरण: वर्तमान प्रॉक्सी के माध्यम से पृष्ठ प्राप्त करना"""
    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()

लॉजिक सरल है: एजेंट fetch_page को कॉल करता है, status_code: 403 प्रतिक्रिया में देखता है और इसके आधार पर खुद निर्णय लेता है कि rotate_ip को कॉल करना है। "10 अनुरोधों के बाद IP बदलें" के नियमों का कोई हार्डकोड नहीं है — मॉडल सर्वर की वास्तविक प्रतिक्रिया पर ध्यान केंद्रित करता है।

उत्पादन के लिए, इस कोड में जोड़ना चाहिए: प्रत्येक रोटेशन का लॉगिंग टाइमस्टैम्प के साथ, प्रति मिनट रोटेशन की संख्या पर सीमा (ताकि मॉडल IP परिवर्तन पर "लूप" न हो) और सत्र स्तर पर टाइमआउट, ताकि "चिपचिपा" IP आवश्यक से अधिक समय तक न रहे।

Claude, LangChain और AutoGPT के साथ एकीकरण

MCP मूल रूप से Claude Desktop और Claude API के लिए प्रोटोकॉल के रूप में बढ़ावा दिया गया है, लेकिन खुली विशिष्टता के कारण इसे तृतीय-पक्ष ढांचे द्वारा भी समर्थित किया जाता है। यदि आप LangChain पर एजेंट बना रहे हैं, तो MCP-सर्वर को langchain-mcp-adapters के माध्यम से जोड़ा जा सकता है, जो MCP-उपकरणों को सामान्य LangChain Tools में बदलता है — एजेंट उन्हें किसी अन्य कार्य की तरह देखता है।

AutoGPT-समान एजेंटों के लिए, जहां MCP का स्वदेशी समर्थन नहीं है, एक स्थानीय HTTP-ब्रिज स्थापित किया जा सकता है: MCP-सर्वर सामान्य REST सेवा के रूप में काम करता है, और एजेंट अपने मानक फ़ंक्शन कॉलिंग तंत्र के माध्यम से एंडपॉइंट्स को कॉल करता है। यह थोड़ा कम सुरुचिपूर्ण है, लेकिन उन टीमों के लिए कार्यात्मक विकल्प है जो पहले से ही एक विशिष्ट स्टैक पर निर्भर हैं।

एंटी-डिटेक्ट ब्राउज़रों के साथ संयोजन के बारे में अलग से कहना चाहिए। यदि पार्सिंग सीधे HTTP अनुरोधों के माध्यम से नहीं होती है, बल्कि हेडलेस Chrome/Playwright के माध्यम से होती है (जो भारी JS सुरक्षा वाली साइटों के लिए आवश्यक है), तो MCP-सर्वर केवल प्रॉक्सी का प्रबंधन नहीं कर सकता, बल्कि ब्राउज़र प्रोफ़ाइल का भी प्रबंधन कर सकता है — एजेंट को Dolphin Anty या Octo Browser में प्रोफ़ाइल चलाने के लिए उपकरण प्रदान करना, जिसमें पहले से ही प्रॉक्सी एंडपॉइंट बंधा होता है। इस मामले में, एजेंट बस यह निर्दिष्ट करता है कि कौन सा प्रोफ़ाइल और कौन सा देश उपयोग करना है, और सभी तकनीकी भाग MCP-उपकरण के पीछे छिपा होता है।

व्यावहारिक मामले: Wildberries, Ozon, SMM-विश्लेषण

Wildberries पर कीमतों की निगरानी। एजेंट 2000 SKU की एक सूची प्राप्त करता है, उत्पाद कार्डों को पार करता है, कैप्चा या खाली प्रतिक्रिया मिलने पर खुद रिसिडेंशियल प्रॉक्सी के माध्यम से IP बदलता है और देरी के साथ अनुरोध को दोहराता है। स्थिर रोटेशन वाले स्थिर स्क्रिप्ट की तुलना में, ऐसा संयोजन साइट पर सुरक्षा बढ़ने पर भी स्थिर संग्रह गति बनाए रखता है — एजेंट बस ब्लॉकिंग पैटर्न पर "धीरे" प्रतिक्रिया करता है, अनुरोधों की आवृत्ति को कम करता है, बजाय इसके कि सभी IP को बैन करने के लिए बस घुमाए।

Ozon Seller API और वेब इंटरफेस से डेटा संग्रह। यहां एजेंट दो मोड का संयोजन करता है: व्यक्तिगत खाते के लिए अधिकृत अनुरोध पूरे कार्य दिवस के लिए "चिपचिपे" IP के माध्यम से जाते हैं (ताकि पुनः दो-चरण प्रमाणीकरण को ट्रिगर न करें), जबकि सार्वजनिक उत्पाद कार्डों का पार्सिंग प्रत्येक अनुरोध पर रोटेशन के माध्यम से होता है।

Instagram और TikTok में प्रतिस्पर्धियों के लिए SMM-विश्लेषण। एजेंट प्रतिस्पर्धियों के खातों की सूची के अनुसार सार्वजनिक आंकड़े (लाइक, टिप्पणियाँ, पहुंच) इकट्ठा करता है, मोबाइल प्रॉक्सी के माध्यम से अनुरोधों को वितरित करता है, ताकि ऐप उपयोगकर्ताओं के सामान्य ट्रैफ़िक की नकल की जा सके, न कि डेटा सेंटर के IP के साथ बॉट की।

इन तीनों मामलों में टीम का समय बचत — पार्सिंग में नहीं है (जिसे पहले भी स्वचालित किया जा सकता था), बल्कि जटिल मैनुअल लॉजिक के पुनः लेखन और समर्थन की आवश्यकता नहीं होने में है, जैसे कि रिट्राई, बैकऑफ और रोटेशन के नियम। एजेंट साइट की सुरक्षा में परिवर्तन के लिए स्वयं को अनुकूलित करता है, बिना कोड को फिर से लिखे।

AI-एजेंट और प्रॉक्सी के संयोजन में सामान्य गलतियाँ

• बहुत बार रोटेशन। यदि एजेंट को हर छोटी बात पर IP बदलने की अनुमति दी जाती है, तो साइट एक ही User-Agent से IP के पते की अजीब गति के कारण पूरे सबनेट रेंज को बैन करना शुरू कर सकती है।
• IP के लिए कुकीज़ का अभाव। यदि एजेंट IP बदलता है, लेकिन पुराने सत्र की कुकीज़ का उपयोग जारी रखता है, तो एंटी-बॉट सिस्टम तुरंत भौगोलिक स्थिति और सत्र में असंगति को पकड़ लेता है।
• रोटेशन की संख्या पर कोई सीमा नहीं। बिना सीमा के, मॉडल त्रुटियों के चक्र में "बेवजह" सभी ट्रैफ़िक सीमा को बर्बाद कर सकता है जब कोई प्रणालीगत समस्या होती है (जैसे, साइट पूरी तरह से डाउन है, न कि विशेष IP को बैन कर रही है)।
• TLS-फिंगरप्रिंट की अनदेखी। IP बदलने से HTTP-क्लाइंट को बदलने में मदद नहीं मिलती है, यदि साइट बॉट्स को TLS-हैंडशेक के सिग्नेचर द्वारा पहचानती है — यहां हेडलेस ब्राउज़र के साथ संयोजन की आवश्यकता होती है, न कि केवल httpx अनुरोध।
• एजेंट को "कच्चे" प्रॉक्सी क्रेडेंशियल्स तक सीधी पहुंच। यदि आप मॉडल को सीधे प्रॉक्सी API में लॉगिन/पासवर्ड तक पहुंच देते हैं, तो आप संवादों के लॉगिंग के दौरान लीक का जोखिम उठाते हैं — MCP-उपकरण का उपयोग करें जैसे कि एक मध्यवर्ती।

निष्कर्ष

AI-एजेंट का MCP-सर्वर और API प्रॉक्सी के साथ संयोजन पार्सिंग की लॉजिक को बदलता है: समय के अनुसार रोटेशन के कठोर नियमों के बजाय, एजेंट ब्लॉकिंग के तथ्य के आधार पर IP परिवर्तन का निर्णय लेता है, "चिपचिपे" और एकल सत्रों को संयोजित करता है, बिना कोड को फिर से लिखे विशेष साइट के अनुसार अनुकूलित करता है। यह विशेष रूप से सक्रिय एंटी-बॉट सुरक्षा वाले प्लेटफार्मों — मार्केटप्लेस, सोशल मीडिया, विज्ञापन प्लेटफार्मों पर स्पष्ट है।

मार्केटप्लेस और गंभीर सुरक्षा वाली साइटों के लिए पार्सिंग करते समय, बेहतर है कि आर्किटेक्चर में रिसिडेंशियल प्रॉक्सी को तुरंत शामिल किया जाए — वे एजेंट को IP के तेजी से जलने के बिना अधिक "गति" प्रदान करते हैं। यदि कार्य सोशल मीडिया और मोबाइल ऐप से संबंधित है, तो मोबाइल प्रॉक्सी पर ध्यान दें — वे एंटी-बॉट सिस्टम द्वारा कम संदेह उत्पन्न करते हैं। और कम सुरक्षित स्रोतों से बड़े पैमाने पर तकनीकी डेटा संग्रह के लिए, तेज और सस्ती डेटा सेंटर प्रॉक्सी उपयुक्त हैं, जिन्हें एजेंट रिसिडेंशियल IP के साथ बजट को अनुकूलित करने के लिए संयोजित कर सकता है।