اگر امروز از هوش مصنوعی برای پیدا کردن مشتریان احتمالی (Lead Generation) استفاده می‌کنید، احتمالاً با پاسخ‌های تخیلی و ایمیل‌های اشتباه دست‌وپنجه نرم کرده‌اید. عامل‌های هوش مصنوعی وقتی به داده‌های لحظه‌ای دسترسی ندارند، در یافتن شرکت‌های B2B متخصص‌ترین «دروغگوهای مطمئن» هستند. برای مثال، اگر مدل کلود (Claude) را به یک CRM متصل کنید و از آن بخواهید «لیدهایی در حوزه فین‌تک با ۵۰ تا ۲۰۰ کارمند پیدا کند»، به احتمال زیاد نتایجی را از خودش ابداع (Hallucinate) خواهد کرد.
به نقل از مستندات پروژه، توسعه‌دهنده‌ای به نام الکسی پانف (Aleksey Panf) برای جلوگیری از این اتفاق و حل این مشکل ابزار b2b-enrichment-mcp را منتشر کرد. این ابزار یک سرور متن‌باز است که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — را مستقیماً به منابع تأییدشده داده متصل می‌کند تا توهمات مدل با واقعیت‌های دیتابیس جایگزین شود.
بسیاری از گردش‌های کاری تولید لید با پراکندگی داده‌ها دست‌وپنجه نرم می‌کنند. معمولاً شما مجبورید بین Hunter.io برای کشف ایمیل‌ها یا Apollo.io برای تحلیل ویژگی‌های شرکت (Firmographics) یکی را انتخاب کنید. این وضعیت کاربران را مجبور به پذیرش یکی از سه سناریوی ناخوشایند می‌کند: پرداخت هزینه به هر دو فروشنده و نوشتن کدهای رابط (Glue Code) شکننده، انتخاب یکی از دو سرویس و نادیده گرفتن دیگری، یا ساخت جریان‌های Zapier که به محض تغییر کوچک در ساختار داده‌های ارسالی (Payload)، از کار می‌افتند. در واقع، بسیاری از تیم‌ها برای مدیریت چنین فرآیندهایی میان اتوماسیون بصری n8n و اسکریپت‌های دستی پایتون مردد هستند تا بهره‌وری خود را بهینه کنند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی استقرار ابزارهای عامل‌محور اشاره کردیم، این گسستگی بهره‌وری را کاهش می‌دهد. اما پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) — استانداردی متن‌باز که توسط آنتروپیک (Anthropic) معرفی شده — این وضعیت را تغییر می‌دهد. MCP اجازه می‌دهد LLMها از طریق یک رابط نرمال‌شده با ابزارهای خارجی تعامل کنند. در این ساختار، عامل هوش مصنوعی دیگر اهمیتی نمی‌دهد که داده در کدام API است؛ او صرفاً درخواست «غنی‌سازی این دامنه» را می‌دهد و یک پاسخ یکپارچه دریافت می‌کند. البته توسعه‌ی سریع ابزارهای مبتنی بر این استاندارد، چالش‌های جدیدی را به همراه داشته است؛ چنان‌که بررسی محدودیت‌های رابط کاربری در ۲۰ اپلیکیشن ساخته شده با MCP نشان می‌دهد که هنوز مسیر تکامل این پروتکل ادامه دارد.
طبق گزارش فنی این پروژه، سرور مذکور با استفاده از SDK پایتون FastMCP، نُه ابزار مجزا را در اختیار عامل قرار می‌دهد. این SDK کارهای سخت مربوط به JSON-RPC، انتقال داده‌ها (Transport) و تولید اسکیماهای داده را مدیریت می‌کند. این امر نیاز به نوشتن کدهای تکراری و زیرساختی (Boilerplate) مانند Flask یا FastAPI را کاملاً از بین می‌برد. یک ابزار حداقلی تنها با نوشتن یک تابع async و تزئین آن با @mcp.tool() ایجاد می‌شود. برای مثال، ابزار find_emails تنها با چند خط کد و استفاده از httpx.AsyncClient برای فراخوانی نقطه اتصال (Endpoint) جست‌وجوی دامنه در Hunter.io پیاده‌سازی شده است.
قابلیت‌های ابزاری
این سرور عملکردهای خود را بین دو ارائه‌دهنده اصلی تقسیم کرده است و از یک نمونه واحد httpx.AsyncClient و یک الگوی مشترک برای مدیریت خطاها استفاده می‌کند:
- ابزارهای Hunter.io (۵ مورد):
find_emails_by_domain: لیست کردن ایمیل‌های مرتبط با یک دامنه خاص.find_email_by_name: مکان‌یابی آدرس ایمیل یک شخص مشخص.verify_email: بررسی قابلیت تحویل و معتبر بودن یک آدرس ایمیل خاص.count_emails: انجام بررسی حجم داده‌ها برای جلوگیری از اتمام زودهنگام اعتبارات API.get_account_info: ردیابی سهمیه باقی‌مانده تا عامل هوش مصنوعی بتواند سرعت درخواست‌های خود را تنظیم (Self-throttle) کند.
- ابزارهای Apollo.io (۴ مورد):
enrich_company: استخراج اندازه شرکت، صنعت، پشته تکنولوژی (Tech Stack) و داده‌های مربوط به جذب سرمایه.search_companies: یافتن شرکت‌هایی که با معیارهای خاص مطابقت دارند.get_company_employees: لیست کردن افرادی که در یک شرکت هدف مشغول به کار هستند.bulk_enrich: امکان غنی‌سازی دسته‌ای تا ۱۰ دامنه در یک بار فراخوانی.
غلبه بر محدودیت‌های API
استفاده از نسخه‌های رایگان API یک ریسک بزرگ دارد: عامل (Agent) — مانند کارمندی که بدون وقفه دستور می‌گیرد — ممکن است به راحتی درخواست‌های اسپم ارسال کرده و باعث بروز خطای ۴۲۹ (Rate Limit) شود. این موضوع به‌ویژه خطرناک است زیرا Hunter در سطح رایگان تنها ۲۵ جست‌وجو در ماه و Apollo تنها ۵۰ اعتبار ارائه می‌دهد. برای حل این مشکل، پروژه یک «محدودکننده نرخ» (Rate Limiter) بر اساس مدل سطل توکن (Token Bucket) را در داخل Wrapper کلاینت با استفاده از asyncio و time.monotonic پیاده کرده است.
این مکانیسم از یک کلاس RateLimiter همراه با یک قفل (Lock) برای ردیابی توکن‌ها استفاده می‌کند. اگر سطل توکن خالی باشد، سیستم زمان انتظار مورد نیاز را محاسبه کرده و دستور await asyncio.sleep(wait) را اجرا می‌کند. این کار عامل را مجبور می‌کند در صورت خالی بودن سطل منتظر بماند تا سرور دچار کرش نشود. بر اساس تحلیل‌های فنی، این رویکرد به این دلیل جواب می‌دهد که مدل‌های زبانی مانند کلود (Claude) به اندازه کافی صبور هستند تا یک تأخیر دو ثانیه‌ای را مدیریت کنند. در واقع، بهینه‌سازی جریان داده برای کاهش فشار بر APIها یک استراتژی کلیدی است، مشابه آنچه در معماری Search as Code برای کاهش مصرف توکن‌های Perplexity مشاهده شد.
چرخش استراتژیک در سطح رایگان Apollo
در جریان توسعه، نویسنده با یک مشکل بحرانی مواجه شد: Apollo به‌طور مخفیانه دسترسی به نقاط اتصال people_search و email_finder را برای طرح‌های رایگان محدود کرده بود، در حالی که در مستندات رسمی هیچ اشاره‌ای به این محدودیت نشده بود. این وضعیت منجر به یک «شکست خاموش» (Silent Failure) می‌شد؛ یعنی API بدون دادن خطای ۴۰۳ یا هر کد هشدار دیگری، پاسخ‌های خالی (Empty Payloads) می‌فرستاد.
برای حفظ وعده «رایگان بودن» پروژه برای کاربران، معماری سیستم بازطراحی شد. نویسنده به جای مجبور کردن کاربران به پرداخت هزینه یا حذف کامل Apollo، یک ساختار ماژولار را انتخاب کرد:
- تمام عملیات‌های یافتن ایمیل به‌طور کامل به Hunter.io ارجاع داده شد.
- استخراج ویژگی‌های شرکت‌ها (Firmographics) توسط
enrich_companyدر Apollo مدیریت می‌شود (که هنوز در سطح رایگان فعال است). - جست‌وجوی افراد به یک مسیر کد مخصوص به «سطح پولی» (Paid-tier) منتقل شد و یادداشتی شفاف در فایل README در این مورد قرار گرفت.
این طراحی ماژولار باعث می‌شود که تغییر در یک API واحد، کل سرور را از کار نیندازد. این تجربه ثابت می‌کند که هنگام وابستگی به نسخه‌های رایگان سرویس‌های شخص ثالث، باید طوری برنامه‌ریزی کرد که گویی هر لحظه ممکن است دسترسی‌ها قطع شود.
مهندسی برای جداسازی خطاها
فراخوانی‌های متوالی API یک گلوگاه هستند؛ اگر یکی از ارائه‌دهندگان دچار اختلال شود، کل گردش کار متوقف می‌شود. برای مدیریت یک غنی‌سازی کامل دامنه — که حداقل به سه فراخوانی در دو ارائه‌دهنده مختلف نیاز دارد — سرور از asyncio.gather با پارامتر return_exceptions=True استفاده می‌کند.
این روش تضمین می‌کند که قطع شدن سرویس Hunter باعث از بین رفتن نتایج Apollo نشود. ابزار full_domain_enrichment هر دو تسک را اجرا کرده و نتایج را در یک دیکشنری واحد ادغام می‌کند. اگر تسکی شکست بخورد، یک رشته خطا برای آن فیلد خاص بازگردانده می‌شود، به این صورت:"emails": hunter_result if not isinstance(hunter_result, Exception) else {"error": str(hunter_result)}
عامل در نهایت داده‌های ناقص را دریافت کرده و سپس تصمیم می‌گیرد که آیا دوباره تلاش کند، داده‌های گم‌شده را نادیده بگیرد یا کاربر را مطلع سازد. این رویکرد، منطق مدیریت خطا را به لایه عامل منتقل می‌کند، جایی که در واقع متعلق به آن است.
تأثیر در دنیای واقعی
در یک تست عملیاتی با یک تیم کوچک فروش، این سرور هفته‌ای حدود ۳۰۰ لید را از طریق Claude Desktop پردازش کرد. گردش کار کاملاً بهینه شده است: نماینده فروش دامنه‌های هدف را در محیط چت قرار می‌دهد، کلود ابزار full_domain_enrichment را فراخوانی می‌کند و ایمیل‌های تأییدشده از طریق یک ابزار MCP مجزا به یک گوگل‌شیت (Google Sheet) منتقل می‌شوند.
با استفاده از این لایه MCP، تیم مذکور توانست هزینه‌های خود را در سطح رایگان به صفر برساند. حتی زمانی که رشد کنند و از محدودیت‌های رایگان فراتر روند، هزینه طرح‌های پولی کوچک ترکیبی حدود ۳۰ دلار در ماه خواهد بود. این مبلغ به‌مراتب ارزان‌تر از خرید یک لایسنس Clay یا یک اکانت کامل Apollo است، زیرا هوش مصنوعی تمامی مراحل ادغام داده‌ها و بارگذاری زمینه برای نوشتن پیش‌نویس‌های ارتباطی را بر عهده می‌گیرد.
تکرارهای آینده
نسخه فعلی با مجوز MIT در گیت‌هاب (github.com/Aleksey-Panf/b2b-enrichment-mcp) در دسترس است. با این حال، نویسنده اشاره می‌کند که استفاده از کلاس‌های کلاینت مجزا برای هر ارائه‌دهنده، یک گلوگاه برای مقیاس‌پذیری است. به‌روزرسانی‌های آینده احتمالاً یک کلاس پایه به نام EnrichmentProvider معرفی می‌کنند تا سرور بتواند به‌راحتی APIهای دیگر مانند Clearbit یا PDL را بدون تکرار کد اضافه کند.
علاوه بر این، پیاده‌سازی یک حافظه پنهان (Cache) پایدار با استفاده از SQLite و زمان انقضای ۷ روزه (TTL)، این واقعیت را پوشش می‌دهد که اکثر جست‌وجوهای B2B ماهیت قطعی (Deterministic) دارند. چنین حافظه پنهانی می‌تواند مصرف تکراری API را ۶۰ تا ۷۰ درصد کاهش دهد و به‌طور قابل توجهی عمر کلیدهای API رایگان را برای کاربران حرفه‌ای افزایش دهد.
برای کسانی که در حال ساخت عامل‌های هوش مصنوعی سفارشی هستند، این پروژه ثابت می‌کند که کلید دستیابی به قابلیت اطمینان، نه در میزان هوشمندی مدل، بلکه در استواری و استحکام لایه دسترسی به ابزارهاست.
گام بعدی شما
- اگر از Claude Desktop استفاده می‌کنید، سرور b2b-enrichment-mcp را نصب کرده و دامنه‌های هدف خود را برای استخراج ایمیل تست کنید.
- در صورت استفاده از APIهای رایگان، حتماً مکانیسم Rate Limiter را در کدهای خود پیاده کنید تا از مسدود شدن کلیدهای API جلوگیری شود.
- برای کاهش هزینه‌ها، ساختار Cache-first را در عامل‌های خود پیاده‌سازی کنید تا درخواست‌های تکراری به سرور ارسال نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو