MCP: اگر مجبورید، پس این‌طور انجام دهید…
من زمان زیادی را صرف صحبت با افراد درباره هوش مصنوعی و — متأسفانه — Model Context Protocol (MCP) کرده‌ام. بسیاری از آن‌ها به من گفته‌اند: «من انبوهی از اطلاعات این کنفرانس را جذب کرده‌ام و تنها چیزی که باید بررسی کنم، چیزی است به نام M…C…D؟ نه، MCP!»
اینجا دقیقاً همان نقطه خطرناک است.
در زبان آلمانی واژه‌ای برای این خطر وجود دارد: Dünnbrettbohrer. این ترکیب فوق‌العاده به معنای «سوراخ‌کننده تخته‌های نازک» است و به‌صورت محاوره‌ای برای کسی استفاده می‌شود که سطحی‌ترین رویکرد را به یک مسئله یا وظیفه دارد و نشان‌دهنده کم‌عمقی یا ناکافی بودن کار اوست.
هدف من این نیست که Anthropic را متهم کنم. وقتی آن‌ها MCP را طراحی کردند، هدف این بود که رابط‌های گفتگو را سریع و آسان با قابلیت ابزار گسترش دهند (و چیزهای دیگری که اغلب نادیده گرفته می‌شوند!). در این زمینه، MCP واقعاً مناسب است (به شرط رفع چند نکته جزئی).
نه، dünnbrettbohrer دنیای MCP کسانی هستند که خود سرورهای MCP را پیاده‌سازی می‌کنند. اکنون در اوج چرخه تبلیغاتی انتظارات اغراق‌آمیز هستیم، یعنی بسیاری از افراد ابزارهای کم‌کد یا بدون کد را به عنوان MCP می‌فروشند — اما زیر کاور همان مشکلات قدیمی باقی است.
هدف من در این مقاله ارائه راهنمایی ساده برای استفاده صحیح از MCP است تا «به خودتان شلیک نکنید» (مانند آخرین فاجعه سرور MCP گیت‌هاب که داده‌های مخزن خصوصی را در معرض حمله قرار داد).
درس اول: آیا واقعاً نیاز است این کار در یک رابط گفتگو انجام شود؟
این نکته بزرگ است. تصور کنید دنیای آرمانی MCP به این شکل است: ChatGPT را باز کنید و از آن بخواهید «تمام داده‌های فروش فصل را جمع‌آوری و گزارشی برای هیئت مدیره تولید کند» یا «در CRM ما جستجو کند و فهرستی از همه مشتریان کانادایی که به گلف علاقه دارند ایجاد کند».
این عالی است، اما در واقعیت، رابط گفتگو شما باید مجموعه‌ای از GPTهای سفارشی باشد (چت‌روم‌های مخصوص این هدف با چندین جریان داده و ابزار).
به یاد داشته باشید، LLMها نمی‌توانند بیش از حدود ده ابزار را مدیریت کنند بدون اینکه کارکرد آن‌ها به هم بریزد.
برای مثال جمع‌آوری داده‌های فروش و تولید گزارش، نیازمند موارد زیر است:
-
یک رابط گفتگو برای مالیات و حسابداری، که بتواند فایل‌های Excel را بررسی کند و فایل آخرین نسخه را تشخیص دهد.
-
رابط گفتگو با دسترسی به ابزار کدنویسی (یا حتی MCP برای Excel) برای جمع‌آوری و پردازش داده‌ها.
-
رابط گفتگو به ابزاری برای ویرایش فایل‌های PowerPoint.
راه جایگزین؟ باز کردن Excel، کپی جدول، اصلاح دستی، و وارد کردن آن به PowerPoint.
با این جریان AI مبتنی بر چت، به سه چت‌روم نیاز دارید، جایی که می‌توانید با کامپیوتر صحبت کنید و آن هم به نوعی پاسخ دهد، یا نرم‌افزار ساده‌ای که خودتان انجام دهید و نتیجه مطمئن باشد.
اعتماد بزرگ‌ترین چالش است: آیا واقعاً به خروجی LLM اعتماد دارید؟ قطعاً خیر.
سؤال این است: وقتی MCP برای هدف اصلی خود — بهبود تعامل با داده در رابط گفتگو — استفاده می‌شود، آیا واقعاً نیاز است این کار در یک رابط گفتگو انجام شود؟
درس دوم: این کد دیگران است، نه کم‌کد یا بدون کد
MCP به معماران سازمانی مانند لگو فروخته می‌شود: «این ابزار plug-and-play برای رابط چت هوش مصنوعی شماست. ما می‌توانیم با چند کلیک آن‌ها را برای شما بسازیم!»
مگر اینکه ابزار MCP توسط فروشنده ارائه شده باشد، معمولاً یک ادغام سفارشی است. یعنی پلتفرم کم‌کد با کانکتورها، نمودارها و گراف‌های زیبا، که چند ماه اول کار می‌کنند و بعداً خراب می‌شوند. چرا؟ چون ادغام‌ها شامل منطق، کانکتورهای ورودی و خروجی هستند. اگر نرم‌افزار در زنجیره تغییر کند، ادغام خراب می‌شود.
پس چه کسی مالک ادغام است؟ سرور MCP یا ایجاد آن؟ چه اختیاراتی دارد؟ بسیاری تصور می‌کنند تیم داخلی آن‌ها مسئول است، اما معمولاً می‌گویند: «باید صبر کنیم فروشنده MCP کانکتورها را به‌روزرسانی کند…»
این مشکل مدیریت وابستگی، در جامعه توسعه نرم‌افزار با فرآیندهای DevOps حل شده است: همه چیز به‌عنوان کد ذخیره، نسخه‌بندی و قابل بازگشت است. اما در MCP، همه چیز خارج از زنجیره عملیات شماست.
نتیجه؟ اگر MCP را اجرا می‌کنید، مطمئن شوید خودتان سرورها و ادغام‌ها را می‌سازید و مالک آن‌ها هستید تا بتوانید بهترین شیوه‌های DevOps را اعمال کنید.
درس سوم: مسئله فرآیندهاست، نه APIها
MCP به عنوان راهی برای کاهش نیروی انسانی و سپردن کارهای «پایین‌رده» به عامل‌های هوشمند دیده می‌شود. اگر از MCP برای این هدف استفاده می‌کنید، به یاد داشته باشید: موضوع APIها نیست، موضوع فرآیند است.
هنگام ایجاد سرور MCP یا دریافت آن از فروشنده SaaS، بررسی کنید که آیا MCPها فرآیندها را به‌عنوان ابزار ارائه می‌دهند یا فقط API فروشنده را در دسترس قرار می‌دهند. چرا؟ چون LLMها نمی‌دانند سازمان شما چگونه کار می‌کند.
می‌توانید دستورالعمل‌ها را در پرامپت قرار دهید، اما اگر فرآیند تغییر کند، مجبورید پرامپت را دوباره تغییر داده و آزمایش کنید.
راه درست؟ رمزگذاری فرآیندها در ابزار، چیزی که فروشندگان مدیریت API قدیمی آن را API orchestration می‌نامند: اسناد قابل‌خواندن توسط ماشین، نسخه‌بندی‌شده، قابل تأیید و پیگیری، که فرآیندهای پیچیده APIهای قدیمی را توضیح می‌دهد و به توزیع آسان بین ادغام‌ها کمک می‌کند.
وقتی ابزار MCP را ارزیابی می‌کنید، به فرآیندها، نه APIها نگاه کنید.
نتیجه‌گیری نهایی: اجازه ندهید MCP پیشرفت را نابود کند
نوشتن درباره این موضوع گاهی کمی مرا عصبانی می‌کند. بسیاری از مشکلات موجود در مدیریت و ادغام APIها قبلاً حل شده‌اند، اما هیاهوی MCP می‌تواند این پیشرفت‌ها را تهدید کند.
امیدوارم این سه درس به شما کمک کند تا MCP را بهتر و با هوشمندی استفاده کنید، و قبل از اعمال آن در محیط‌های هوش مصنوعی، دو بار فکر کنید.
