۱. این یک آشفتگی ناامن است
این اصلیترین مشکل است – MCP قرار بود با یک کامپوننت سمت سرور مناسب پشتیبانی شود. اما در پیادهسازیهای مرجع؟ هیچ چیزی نبود. و نتیجهی پیشبینیشده، ظهور پیادهسازیهای DIY توسط توسعهدهندگان مشتاق AI بود که حالا گیتهاب و سرورهای Discord را با سرورهای MCP خانگی، اغلب ناامن و قابل سؤال، پر کردهاند.
درست است؛ صدها، احتمالاً هزاران کد ناامن نوشتهشده توسط تکنولوژیبازان وجود دارد که انتظار میرود بهعنوان یک فرآیند محلی در فضای کاربر اجرا شوند. هر مدیر IT یا متخصص امنیت باید موهایش را از عصبانیت بکشد – این چه مزخرفی است؟ نه تنها این فرآیندها محلی هستند، بلکه در بدترین زبانها ساخته شدهاند: Python و NodeJS.
با Node و Python مشکل ندارم، اما آنها به شدت ناامن و مستعد حملات زنجیره تأمین هستند. وقتی این وحشتها را نصب میکنید، شما صرفاً آنها را از وب اجرا میکنید با NPX یا UVX.
کی جمعی تصمیم گرفتیم که اجرای کد از GitHub با هدایت به شل، کاری پذیرفتهشده است؟
تا زمانی که سرورها SSE را با احراز هویت فعال پشتیبانی نکنند و توسط تیم IT داخلی بررسی و مدیریت نشوند، MCP باید از سازمانهای بزرگ دور بماند.
نکته: البته اگر سازمان شما سرورهای MCP را خودش میسازد، مشکلی نیست – اما در این صورت با مشکل بعدی روبرو خواهید شد…
۲. نسخهبندی – کی اهمیت پیدا کرد؟
برخلاف APIهای بالغ، MCPها فاقد استانداردهای نسخهبندی هستند. آنها فقط فرآیند هستند. هیچ استانداردی برای سازگاری، مدیریت تغییرات یا حتی دانستن نسخه در حال اجرا وجود ندارد.
اگر شما سرورهای خودتان را اجرا میکنید، تبریک! حالا باید مدیریت وابستگیها و نسخهها را خودتان اختراع کنید. هماهنگ کردن بروزرسانیها یا حتی دانستن زمان وقوع مشکل، یک کابوس خواهد بود.
شما اساساً یک یکپارچهسازی ساده را به یک مشکل سیستم توزیعشده تبدیل کردهاید.
۳. جهنم کاربردپذیری
هیچکس نگفته APIها آسان هستند، اما میتوان با curl یک API را بررسی کرد. برای MCP، شما به انواع ابزارهای وابسته به زبان نیاز دارید تا سرورهای MCP را بررسی و اشکالزدایی کنید. هدف چیست؟ برای اینکه کلاینت LLM بتواند API را فراخوانی کند.
و در زمان پیکربندی، بسیاری از این ابزارها نیازمند کلون کردن مخازن تصادفی، دستکاری YAML و امیدواری به موفقیت هستند. اگر میخواهید بفهمید چرا LLM شما نمیتواند با سرور محلی پلاگین ارتباط برقرار کند، معمولاً در JSON بدون نوع فرو میروید. اصلاً خوشایند نیست.
کاربرانی که Claude Desktop یا ChatGPT Desktop را اجرا میکنند، قرار نیست vim بیاورند و JSON را درک کنند.
در کلاینتهای هوشمند، مخازن به نمایندگی از شما ارائه و مدیریت میشوند. مثالی که اخیراً تجربه کردم:
-
VSCode را باز میکنم
-
Cline یا RooCode را نصب میکنم تا کمک برنامهنویسی AI فعال شود
-
Cline دارای مخزن MCP است و میتوانم MCPها را نصب کنم
-
این یک پلاگین است که یک پلاگین دیگر را اجرا و نصب میکند و API فراخوانی میکند
چرا خودمان را درگیر این پیچیدگی میکنیم؟
۴. فقط SDKهایی با مراحل اضافی هستند
میخواهم دربارهی استفاده تبلیغشده MCP برای “باز کردن جریانهای کاری عاملمحور” صحبت کنیم.
این چرند است، و دلیلش این است: مگر اینکه AGI بسازید یا یک عامل «عمومی»، عوامل شما همیشه برنامههای سفارشی خواهند بود – احتمالاً با فریمورکهایی مثل ADK یا AgentChat ساخته میشوند. عامل شما یک فایل YAML ساده نخواهد بود؛ کد زیادی برای کنترل رفتار دارد. چرا MCP اضافه کنیم وقتی میتوان مستقیماً ادغام کرد؟
به یاد داشته باشید – احتمالاً عامل شما توسط AI ساخته میشود، پس بهتر است یک ادغام سریع و بهصرفه با کمک دستیار کدنویسی AI انجام دهید تا با استانداردهای اضافی پیچیده شوید.
با توجه به اینکه مدلها در تکرارپذیری و قابلیت اعتماد به پاسخها ناسازگار هستند، باید همه عوامل را بهعنوان آثار کد موقت در نظر گرفت.
SmolAgents سبک آینده است
به همین دلیل من (احتمالاً نظر اقلیت) فکر میکنم فریمورکهایی مثل SmolAgents از Huggingface راه حل واقعی هستند. به جای ساخت زیرساخت پایدار، اجازه میدهند مدل اسکریپتهای کوتاهمدت را در محیط ایزوله اجرا کند تا وظایف حل شود.
سبک، چابک و مطابق با طبیعت LLMهای امروزی: ناپایدار، خلاق و کوتاهمدت. همچنین بسیار مقاومتر از ساخت کل زنجیره ابزار حول یک رابط MCP است.
واقعیت
MCP ایده هوشمندانهای است، اما به دلیل سوءتفاهم اساسی درباره جایگاه ما در زنجیره تأمین AI، بیش از حد بزرگنمایی شده است. ما عوامل عمومی نداریم. چیزی که داریم، جریانهای کاری سفارشی و خاص برنامه است.
تا زمانی که این تغییر کند، یکپارچهسازی مستقیم API سریعتر، ایمنتر و قابل نگهداریتر خواهد بود.
این باعث میشود MCP تنها در یک مکان کاربردی باشد: رابطهای چت. حتی در آنجا هم تجربه غالباً دست و پاگیر است.
بیایید وانمود نکنیم که بیش از این کاربرد دارد.
