MCP-server dan API proxy: penggantian IP otomatis untuk agen AI

Parser klasik mendapatkan daftar proxy, mengulanginya tanpa henti, dan gagal begitu sistem anti-bot mendeteksi pola. Agen AI bekerja secara berbeda: ia melihat pemblokiran, secara mandiri memutuskan untuk mengganti IP, mengubah header, memperlambat permintaan — dan semua ini tanpa campur tangan Anda. Mari kita bahas bagaimana menghubungkan agen, MCP-server, dan API proxy dalam satu kesatuan yang menjaga sesi tetap hidup bahkan di situs yang dilindungi.

Apa itu MCP-server dan mengapa dibutuhkan oleh parser

MCP (Model Context Protocol) — protokol terbuka yang memungkinkan agen AI (misalnya, berbasis Claude atau LLM lainnya dengan dukungan tool-calling) untuk mengakses alat eksternal melalui satu antarmuka. Sebelumnya, untuk memberikan model akses ke API eksternal, Anda harus menulis pembungkus khusus untuk setiap tugas. MCP-server menyelesaikan ini dengan cara lain: ia mendeskripsikan sekumpulan "alat" (tools) — fungsi yang dapat dipanggil oleh agen sendiri ketika ia memahami bahwa alat tersebut diperlukan.

Dalam konteks parsing, ini terlihat seperti ini: agen menerima tugas "kumpulkan harga untuk 500 produk dari marketplace". Ia mulai melakukan permintaan melalui alat fetch_page, melihat respons 403 atau captcha, secara mandiri memanggil alat rotate_proxy, mendapatkan IP baru dan mengulangi permintaan — tanpa campur tangan operator. MCP-server di sini berperan sebagai "jembatan" antara logika agen dan infrastruktur proxy yang nyata.

Perbedaan utama dari skrip biasa dengan rotasi berdasarkan timer: agen mengambil keputusan untuk mengganti IP berdasarkan konteks — kode respons, konten halaman, kecepatan pemblokiran domain tertentu. Ia dapat mempertahankan satu IP untuk sesi otorisasi dan mengganti IP hanya untuk permintaan "dingin" pengumpulan data, mengombinasikan strategi secara dinamis.

Mengapa agen AI membutuhkan penggantian IP, bukan hanya daftar proxy

Jika Anda hanya memberikan agen daftar statis dari 50 proxy dan meminta untuk mengulanginya, Anda akan mendapatkan hasil yang sama seperti dengan skrip biasa: pola permintaan dengan cepat dihitung oleh sistem anti-bot berdasarkan interval, header, dan urutan IP. Wildberries, Ozon, Avito, dan platform besar lainnya menggunakan analisis perilaku — mereka tidak hanya melihat pada IP, tetapi juga bagaimana User-Agent, cookies, fingerprint TLS, dan kecepatan permintaan berubah dalam kaitannya dengan alamat tertentu.

Agen AI menyelesaikan tugas ini dengan cara yang sangat berbeda. Ia dapat:

Menentukan berdasarkan kode respons (403, 429, pengalihan ke captcha), bahwa IP saat ini "terdeteksi", dan meminta yang baru khusus untuk domain ini;
Mempertahankan sesi "lengket" (sticky session) pada satu IP untuk skenario multi-langkah — misalnya, otorisasi + parsing dasbor pribadi;
Mengadaptasi frekuensi permintaan sesuai dengan respons situs, bukan bekerja berdasarkan timer yang kaku;
Mengombinasikan penggantian IP dengan perubahan header dan emulasi browser melalui alat anti-detect seperti Dolphin Anty atau AdsPower, jika parsing dilakukan melalui browser headless.

Itulah sebabnya kesatuan "agen + MCP-server + API proxy" secara signifikan mengurangi persentase pemblokiran dibandingkan dengan rotasi statis: keputusan untuk mengganti IP diambil berdasarkan fakta pemblokiran, bukan berdasarkan jadwal.

Arsitektur kesatuan: agen → MCP → API proxy → parser

Skema kerja terdiri dari empat lapisan, dan penting untuk memahami zona tanggung jawab masing-masing:

Agen AI (LLM dengan tool-calling) — mengambil keputusan: halaman mana yang akan diparsing selanjutnya, apakah perlu mengganti IP, apakah perlu memperlambat;
MCP-server — menyediakan agen dengan sekumpulan alat: get_page, rotate_ip, check_proxy_status;
API penyedia proxy — memberikan IP baru berdasarkan permintaan, menunjukkan geolokasi, jenis koneksi (residensial, seluler, pusat data);
Parser/klien HTTP — menjalankan permintaan aktual ke situs target dengan parameter proxy yang diterima.

Poin penting: MCP-server tidak melakukan parsing situs itu sendiri — ia hanya menyediakan kemampuan kepada agen. Logika "apa yang harus dilakukan saat 403" tetap ada pada model, sementara MCP-server hanya menjalankan perintah dan mengembalikan hasil. Pemisahan ini memungkinkan untuk mengganti penyedia proxy atau parser tanpa menulis ulang logika agen — cukup memperbarui implementasi alat di MCP-server.

Saran praktis

Jangan memberikan agen akses langsung ke API proxy "mentah" — bungkus dalam alat MCP terpisah dengan parameter terbatas (negara, jenis IP, session_id). Ini mengurangi risiko bahwa model secara tidak sengaja menghasilkan permintaan yang tidak valid dan "membakar" kuota.

Jenis proxy apa yang harus dipilih untuk parsing agen

Jenis proxy secara langsung mempengaruhi seberapa sering agen harus memanggil rotate_ip dan berapa banyak permintaan yang dapat dilakukan tanpa pemblokiran. Berikut adalah perbandingan berdasarkan tugas yang relevan untuk parsing agen.

Jenis proxy	Kapan digunakan agen	Kelebihan	Kekurangan
Proxy residensial	Parsing marketplace, situs dengan perlindungan anti-bot (Wildberries, Ozon)	IP nyata pengguna, persentase pemblokiran yang rendah	Lebih mahal daripada pusat data, kecepatan tergantung pada node
Proxy seluler	Bekerja dengan media sosial dan dasbor iklan dalam alur agen	Kepercayaan maksimum dari situs, IP seperti operator seluler	Biaya lebih tinggi, kecepatan rotasi terbatas
Proxy pusat data	Pengumpulan data massal dari situs tanpa perlindungan anti-bot yang ketat	Kecepatan tinggi, harga rendah per IP	Mudah terdeteksi, sering memerlukan rotasi melalui agen

Dalam praktiknya, agen dapat mengombinasikan jenis-jenis tersebut: memulai sesi melalui proxy residensial untuk "pemanasan", dan untuk pengalihan teknis dari rate-limit beralih ke pusat data — jika alat MCP memungkinkan untuk menentukan jenis IP sebagai parameter permintaan.

Pengaturan langkah demi langkah MCP-server dengan rotasi proxy

Mari kita bahas kesatuan kerja minimal dalam Python. MCP-server mendeskripsikan dua alat: pengambilan halaman dan penggantian IP melalui API penyedia proxy.

from mcp.server.fastmcp import FastMCP
import httpx

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

# Penyimpanan sesi proxy saat ini
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """Meminta IP baru dari penyedia proxy melalui API-nya"""
    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:
    """Alat untuk agen: mengganti alamat IP dengan yang baru dari negara yang ditentukan"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IP diperbarui, wilayah: {country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """Alat untuk agen: mengambil halaman melalui proxy saat ini"""
    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()

Logika sederhana: agen memanggil fetch_page, melihat dalam respons status_code: 403 dan berdasarkan itu ia memutuskan untuk memanggil rotate_ip. Tidak ada hardcode aturan "setelah 10 permintaan ganti IP" — model berorientasi pada respons nyata dari server.

Untuk produksi, kode ini perlu ditambahkan: pencatatan setiap rotasi dengan timestamp, pembatasan jumlah rotasi per menit (agar model tidak "terjebak" dalam penggantian IP alih-alih menyelesaikan masalah nyata) dan timeout pada tingkat sesi, agar IP "lengket" tidak bertahan lebih lama dari yang diperlukan.

Integrasi dengan Claude, LangChain, dan AutoGPT

MCP awalnya dipromosikan sebagai protokol untuk Claude Desktop dan Claude API, tetapi berkat spesifikasi terbuka, ia juga didukung oleh kerangka kerja pihak ketiga. Jika Anda membangun agen di LangChain, MCP-server terhubung melalui adaptor langchain-mcp-adapters, yang mengubah alat MCP menjadi Alat LangChain biasa — agen melihatnya sama seperti fungsi lainnya.

Untuk agen yang mirip AutoGPT, di mana tidak ada dukungan native untuk MCP, Anda dapat membangun jembatan HTTP lokal: MCP-server berfungsi sebagai layanan REST biasa, dan agen memanggil endpoint melalui mekanisme pemanggilan fungsi standar mereka. Ini sedikit kurang elegan, tetapi merupakan pilihan yang berfungsi untuk tim yang sudah terikat pada tumpukan tertentu.

Secara terpisah, perlu disebutkan tentang integrasi dengan browser anti-detect. Jika parsing dilakukan tidak melalui permintaan HTTP langsung, tetapi melalui headless Chrome/Playwright (diperlukan untuk situs dengan perlindungan JS yang berat), MCP-server dapat mengelola tidak hanya proxy, tetapi juga profil browser — memberikan agen alat untuk menjalankan profil di Dolphin Anty atau Octo Browser dengan endpoint proxy yang sudah terikat. Dalam hal ini, agen cukup menunjukkan profil mana dan negara mana yang akan digunakan, sementara semua bagian teknis tersembunyi di balik alat MCP.

Kasus praktis: Wildberries, Ozon, analisis SMM

Monitoring harga di Wildberries. Agen menerima daftar 2000 SKU, mengunjungi halaman produk, saat menerima captcha atau respons kosong, ia secara mandiri mengganti IP melalui proxy residensial dan mengulangi permintaan dengan jeda. Berbeda dengan skrip statis dengan rotasi tetap, kesatuan seperti ini mempertahankan kecepatan pengumpulan yang stabil bahkan saat perlindungan diperkuat di sisi platform — agen hanya "bereaksi lebih lambat" terhadap pola pemblokiran, mengurangi frekuensi permintaan alih-alih hanya mengulang IP hingga semua diblokir.

Pengumpulan data dari Ozon Seller API dan antarmuka web. Di sini agen mengombinasikan dua mode: permintaan terotorisasi ke dasbor pribadi dilakukan melalui IP "lengket" sepanjang hari kerja (agar tidak memicu verifikasi dua faktor ulang), sementara parsing publik halaman produk dilakukan dengan rotasi untuk setiap permintaan.

Analisis SMM terhadap pesaing di Instagram dan TikTok. Agen mengumpulkan statistik publik (likes, komentar, jangkauan) dari daftar akun pesaing, mendistribusikan permintaan melalui proxy seluler, untuk meniru lalu lintas pengguna aplikasi biasa, bukan bot dengan IP pusat data.

Dalam ketiga kasus tersebut, penghematan waktu tim — bukan dalam parsing itu sendiri (yang bisa diotomatisasi sebelumnya), tetapi dalam tidak perlu menulis dan memelihara logika manual yang rumit untuk retry, backoff, dan aturan rotasi. Agen beradaptasi dengan perubahan perlindungan situs secara mandiri, tanpa menulis ulang kode.

Kesalahan umum saat menghubungkan agen AI dan proxy

Rotasi terlalu sering. Jika Anda mengizinkan agen mengganti IP untuk setiap gerakan kecil, situs dapat mulai memblokir seluruh rentang subnet karena kecepatan perubahan alamat yang tidak normal dari satu User-Agent.
Kurangnya pengikatan cookies ke IP. Jika agen mengganti IP tetapi terus menggunakan cookies sesi lama, sistem anti-bot segera mencatat ketidaksesuaian geolokasi dan sesi.
Tidak ada batasan pada jumlah rotasi. Tanpa pembatasan, model dalam siklus kesalahan dapat "membakar" seluruh kuota lalu lintas pada upaya yang tidak berguna saat ada masalah sistem (misalnya, situs tidak dapat diakses sepenuhnya, bukan memblokir IP tertentu).
Mengabaikan fingerprint TLS. Mengganti IP tanpa mengganti klien HTTP tidak membantu, jika situs mendeteksi bot berdasarkan tanda tangan TLS handshake — di sini diperlukan kesatuan dengan browser headless, bukan hanya permintaan httpx.
Akses langsung agen ke kredensial proxy "mentah". Dengan memberikan model akses langsung ke login/password API proxy dalam prompt, Anda berisiko mengalami kebocoran saat mencatat dialog — gunakan alat MCP sebagai perantara.

Kesimpulan

Kesatuan agen AI dengan MCP-server dan API proxy mengubah logika parsing itu sendiri: alih-alih aturan rotasi yang kaku berdasarkan timer, agen mengambil keputusan untuk mengganti IP berdasarkan fakta pemblokiran, mengombinasikan sesi "lengket" dan sekali pakai, menyesuaikan diri dengan situs tertentu tanpa menulis ulang kode. Ini sangat terlihat di platform dengan perlindungan anti-bot aktif — marketplace, media sosial, platform iklan.

Untuk parsing marketplace dan situs dengan perlindungan serius, lebih baik segera mengintegrasikan proxy residensial — mereka memberikan agen lebih banyak "ruang" untuk bermanuver tanpa cepatnya kehabisan IP. Jika tugas terkait dengan media sosial dan aplikasi seluler, perhatikan proxy seluler — mereka lebih jarang menimbulkan kecurigaan dari sistem anti-bot. Dan untuk pengumpulan data teknis massal dari sumber yang kurang terlindungi, proxy pusat data yang cepat dan terjangkau proxy dapat digunakan oleh agen dalam kombinasi dengan IP residensial untuk mengoptimalkan anggaran.