MCP: بررسی انتقادی کاستی‌ها و پتانسیل‌ها

تحمیل مسئولیت‌های بیش از حد به MCP

یکی از انتقادات رایج این است که وظایف بسیار زیادی به MCP محول شده است. نویسنده استدلال می‌کند که MCP باید در درجه اول به عنوان دروازه‌ای برای دسترسی مدل‌های زبانی بزرگ (LLMs) به منابع خارجی و تعامل با آن‌ها عمل کند. نگاه کردن به آن صرفاً به عنوان یک “درگاه” یا “پل” به روشن شدن هدف و محدودیت‌های آن کمک می‌کند.

نسبت دادن مستقیم مشکلاتی مانند افشای تصادفی داده‌ها، آسیب‌پذیری‌های تزریق دستور (Prompt Injection) و نقص‌های کنترل هزینه به MCP، یک انتساب اشتباه است. این‌ها مشکلاتی هستند که توسعه‌دهندگان باید در محدوده کنترلی خود به آن‌ها رسیدگی کنند. توسعه‌دهندگان باید محدودیت نرخ را اعمال کرده و استفاده را نظارت کنند، صرف نظر از پروتکل مورد استفاده. تشبیه این به مقصر دانستن جاده برای سرعت غیرمجاز مناسب است - زیرساخت‌ها مسئول رفتار فردی نیستند.

در نهایت، بسیاری از نگرانی‌های مطرح شده، مسائل گسترده‌تری در رابطه با محول کردن وظایف به عوامل هوش مصنوعی هستند. توسعه‌دهندگان باید مسئولیت مدیریت این چالش‌ها را در برنامه‌های خاص خود بر عهده بگیرند، نه اینکه انتظار داشته باشند خود API همه چیز را اداره کند.

شمشیر دولبه LLMها و تزریق دستور

بحث‌های اخیر پیرامون MCP اغلب شبیه هشدارهایی در مورد خطرات ذاتی چاقوهای تیز است – اگر به درستی استفاده نشوند، می‌توانند ببرند. تزریق دستور، یک نگرانی مهم، پیامدی از ماهیت خود LLMها است. تلاش برای از بین بردن خطر تزریق دستور، توانایی‌هایی را که LLMها را ارزشمند می‌سازد، کاهش می‌دهد.

مفهوم تفکیک “کنترل در مقابل داده”، که در سیستم‌های سنتی رایج است، به طور طبیعی در LLMها وجود ندارد. LLMها قدرت و کلیت خود را دقیقاً به این دلیل به دست می‌آورند که این تفکیک سفت و سخت را ندارند. این ویژگی ذاتی آن‌ها را در برابر حملات تزریق دستور آسیب‌پذیر می‌کند.

در حالی که MCPهای از راه دور به عنوان یک سرویس ممکن است خطراتی را به همراه داشته باشند، تقصیر متوجه خود پروتکل نیست، بلکه مربوط به سپردن وظایف حساس به اشخاص ثالث غیرقابل اعتماد است. این قیاس به ایده چسباندن یک چاقو به یک رومبای نامنظم گسترش می‌یابد - مشکل خود چاقو نیست، بلکه تصمیم به اتصال آن به یک دستگاه غیرقابل پیش‌بینی است.

تذکرات “مراقب باشید” یا پیشنهادات استفاده از وسایل محافظتی، در حالی که از نظر فنی دقیق هستند، موضوع اصلی را نادیده می‌گیرند: تصمیم نابخردانه برای ترکیب یک ابزار تیز با یک سیستم کنترل نشده.

چالش‌های مقیاس‌پذیری

فراتر از نگرانی‌های امنیتی، MCP با محدودیت‌های اساسی مقیاس‌پذیری روبرو است. نویسنده بر همبستگی منفی بین قابلیت اطمینان LLM و میزان بافت آموزشی ارائه شده تأکید می‌کند. این باور رایج مبنی بر اینکه افزودن داده‌ها و ادغام‌های بیشتر به طور خودکار مشکلات را حل می‌کند، به چالش می‌کشد. با افزایش تعداد ابزارها و ادغام‌ها، عملکرد یک عامل ممکن است کاهش یابد در حالی که همزمان هزینه هر درخواست را افزایش می‌دهد.

نویسنده تأکید می‌کند که MCP فراتر از یک آستانه مشخص مقیاس نمی‌یابد. تلاش برای افزودن تعداد نامحدودی ابزار به بافت یک عامل، به ناچار بر توانایی‌های آن تأثیر منفی می‌گذارد. این محدودیت ذاتی مفهوم MCP است و نیاز به توجه بیشتری نسبت به مسائل احراز هویت دارد.

کاربران ممکن است در نهایت با فعال کردن سرورهای MCP بیشتر، کاهشی در عملکرد را تجربه کنند که منجر به تداخل بین آن‌ها می‌شود. این در تضاد کامل با سیستم‌های مدیریت بسته معمولی است که در آن عدم تداخل یک ویژگی اساسی است.

مشکل اصلی MCP این است که رفتار واقعی آن از انتظارات کاربر منحرف می‌شود. بسیار مهم است که تشخیص دهیم MCP یک راه حل پلاگین و پخش نیست که به طور یکپارچه تعداد نامحدودی ابزار را بدون عواقب ادغام کند.

پرداختن به محدودیت‌ها با UI و مدیریت ابزار

یکی از راه‌حل‌های پیشنهادی برای محدودیت‌های MCP، بهبود رابط کاربری (UI) است. اگر ابزاری به طور ناخواسته اجرا شود، UI باید راهی آسان برای غیرفعال کردن آن یا اصلاح توضیحات آن برای روشن کردن کاربرد مورد نظرش ارائه دهد.

نویسنده همچنین خاطرنشان می‌کند که رشد بافت اغلب منجر به بهبود عملکرد و توانایی‌های استفاده در دنیای واقعی می‌شود و این با مفهوم همبستگی کاملاً منفی در تضاد است. با این حال، آن‌ها تصدیق می‌کنند که در موارد استفاده خاص یا با بافت‌های ضعیف طراحی شده، تخریب عملکرد می‌تواند رخ دهد.

برای رسیدگی به انتخاب طاقت‌فرسای ابزارها، یک رویکرد “تفرقه بینداز و حکومت کن” پیشنهاد می‌شود. این شامل افزودن ابزاری است که به طور خاص برای انتخاب مرتبط‌ترین ابزارها برای یک کار معین طراحی شده است. این “ابزار انتخاب ابزار” می‌تواند یک فراخوانی LLM دیگر باشد که وظیفه دارد زیرمجموعه‌ای از ابزارهای موجود را به عامل “والد” برگرداند. این رویکرد لایه‌ای، سطوح غیرمستقیم اضافی برای مدیریت پیچیدگی اضافه می‌کند.

با این حال، صرفاً داشتن ابزارها در بافت می‌تواند به طور قابل توجهی خروجی یک مدل را تغییر دهد. در حالی که ابزارهای مرتبط با متن (که از طریق تکنیک‌هایی مانند تولید افزایش‌یافته بازیابی یا RAG به دست می‌آیند) مفید هستند، پنهان کردن همه ابزارها در پشت یک درخواست “get_tools” می‌تواند مضر باشد.

MCP به عنوان لایه انتقال و مجوز

MCP در درجه اول به عنوان یک قالب انتقال و سیم با چرخه عمر درخواست/پاسخ، با تمرکز بر مجوز سطح ابزار عمل می‌کند. مقاله استدلال می‌کند که بزرگترین مشکل MCP عدم توانایی عوامل هوش مصنوعی در ترکیب عملکردی ابزارها است.

نویسنده فرض می‌کند که MCP ممکن است در وهله اول غیرضروری باشد، زیرا LLMها از قبل توانایی تعامل با APIهای مستند شده با استفاده از مشخصات OpenAPI را دارند. عنصر گمشده مجوز است - توانایی کنترل اینکه کدام APIها یک هوش مصنوعی می‌تواند به آن‌ها دسترسی داشته باشد. نویسنده به جای MCP، پیشنهاد می‌کند به هوش مصنوعی‌ها اجازه داده شود درخواست‌های HTTP ایجاد کنند در حالی که مجوز را برای نقاط پایانی خاص اعمال می‌کنند. این رویکرد با روند فعلی پوشاندن APIهای موجود با ابزارهای MCP نازک مطابقت دارد.

یک جنبه به خصوص آزاردهنده MCP عدم پشتیبانی آن از نتایج فراخوانی ابزار جریانی است. جفت درخواست/پاسخ واحد، مشتریان را مجبور می‌کند تا به طور مکرر ابزارها را برای صفحه‌بندی فراخوانی کنند و مانع از فرآیندهای طولانی‌مدت می‌شود. اجرای یک قابلیت جریانی، شاید با استفاده از gRPC، می‌تواند به طور قابل توجهی کارایی MCP را بهبود بخشد.

سهولت افشای داده‌های حساس

نگرانی مهم در مورد MCP، پتانسیل سهولت افشای داده‌های حساس است. علاوه بر این، MCP ذاتاً عوامل هوش مصنوعی را قابل اعتمادتر نمی‌کند. این به سادگی به آن‌ها امکان دسترسی به ابزارهای بیشتری را می‌دهد که می‌تواند به طور متناقض در برخی موقعیت‌ها قابلیت اطمینان را کاهش دهد.

نویسنده اذعان می‌کند که انتظار ندارند MCP همه این مسائل را حل کند یا مسئول همه آن‌ها باشد. بلکه MCP سطح وسیع‌تری را برای این مشکلات ایجاد می‌کند و نیاز به هوشیاری توسعه‌دهندگان و کاربران برنامه دارد.

قیاس‌ها و برنامه‌ریزی شهری

نویسنده از قیاس برنامه‌ریزی شهری برای نشان دادن مسئله استفاده می‌کند. مقایسه MCP با یک جاده شش بانده شهری با سرعت مجاز 25 مایل در ساعت، گسستگی بین طراحی و استفاده مورد نظر را برجسته می‌کند. صرفاً اعمال جریمه یا افزودن “تعمیرات” سطحی به مشکل اساسی طراحی ضعیف نمی‌پردازد.

برنامه‌ریزی شهری مؤثر شامل طراحی جاده‌هایی است که به طور طبیعی پایبندی به محدودیت‌های سرعت را تشویق می‌کنند. به طور مشابه، MCP باید به گونه‌ای طراحی شود که به طور ذاتی خطرات احتمالی را کاهش دهد، نه اینکه صرفاً به کنترل‌های خارجی متکی باشد.

انجام اقدامات ناخواسته توسط LLMها

مقاله به یک انتقاد گسترده‌تر از پروتکل‌هایی می‌پردازد که به LLMها اجازه می‌دهند اقداماتی را روی سرویس‌ها انجام دهند. نویسنده یک مشکل اصلی را شناسایی می‌کند: LLMها ممکن است اقداماتی را انجام دهند که کاربران قصد انجام آن‌ها را ندارند. آن‌ها بین اقداماتی که LLMها می‌توانند به طور مستقل انجام دهند و اقداماتی که نیاز به اعلان کاربر دارند، تمایز قائل می‌شوند.

در حالی که هدف نهایی ممکن است این باشد که LLMها کل کسب و کارها را مدیریت کنند، این فناوری هنوز برای چنین استقلالی آماده نیست. در حال حاضر، کاربران حتی ممکن است نخواهند هوش مصنوعی‌ها بدون بررسی قبلی ایمیل ارسال کنند.

نویسنده راه حل اعلان کاربر برای تأیید را رد می‌کند و به خطر افتادن کاربران در الگوی تأیید خودکار (“حالت YOLO”) اشاره می‌کند، زمانی که بیشتر ابزارها بی‌ضرر به نظر می‌رسند. این شبیه به پدیده روانشناختی افرادی است که بیشتر با کارت خرج می‌کنند تا با پول نقد - مشکلی که ریشه در رفتار انسان دارد، نه فناوری.

سوال اساسی: چرا فقط از APIها استفاده نکنیم؟

یک سوال مکرر در بحث‌ها در مورد MCP این است که چرا به سادگی از APIها به طور مستقیم استفاده نکنیم.

MCP به مشتریان LLM که کاربران مستقیماً کنترل نمی‌کنند (به عنوان مثال، Claude، ChatGPT، Cursor، VSCode) اجازه می‌دهد تا با APIها تعامل داشته باشند. بدون MCP، توسعه‌دهندگان نیاز دارند که با استفاده از APIهای LLM، مشتریان سفارشی بسازند که این کار بسیار پرهزینه‌تر از استفاده از مشتریان موجود با اشتراک و آموزش آن‌ها در مورد نحوه استفاده از ابزارهای خاص است.

یک توسعه‌دهنده تجربه خود را از ساخت یک سرور MCP برای اتصال به سینتی‌سایزر سخت‌افزاری FM خود از طریق USB به اشتراک می‌گذارد و طراحی صدای مبتنی بر هوش مصنوعی را امکان‌پذیر می‌کند.

یکپارچه‌سازی کلاینت LLM و استانداردسازی

مسئله اصلی این است که همه کلاینت‌های LLM به طور ذاتی از تعامل مستقیم API پشتیبانی نمی‌کنند، در حالی که اقدامات GPT سفارشی ChatGPT یک استثنای قابل توجه است. Anthropic، Google و OpenAI توافق کرده‌اند که MCP را به عنوان یک پروتکل مشترک برای ساده‌سازی فرآیند برای کلاینت‌های مبتنی بر LLM مانند Claude، ChatGPT و Cursor اتخاذ کنند.

MCP این فرآیند را برای کسانی که کلاینت‌های LLM را می‌سازند ساده می‌کند. اگر می‌خواهید یک LLM با یک API تعامل داشته باشد، نمی‌توانید به سادگی یک کلید API ارائه دهید و انتظار داشته باشید که کار کند - شما باید یک Agent ایجاد کنید.

MCP را می‌توان راهی برای مستندسازی APIها و توصیف نحوه فراخوانی آن‌ها، همراه با ابزارهای استاندارد برای افشای آن مستندات و تسهیل تماس‌ها در نظر گرفت. این تنها انتزاع کافی برای پوشاندن APIها بدون پیچیدگی غیرضروری ارائه می‌دهد، اما این سادگی همچنین می‌تواند منجر به این شود که کاربران “به خود شلیک کنند”.

کارایی و قابلیت استفاده مجدد MCP

بدون MCP، توسعه‌دهندگان باید هر بار که ابزاری فراخوانی می‌شود، مکرراً برای LLM توضیح دهند که چگونه از آن استفاده کنند. این خطر وجود دارد که LLM به دلیل اطلاعات فراموش شده یا رفتار غیر استاندارد API نتواند به درستی از ابزار استفاده کند.

این توضیح و تکرار مداوم، توکن‌ها را در بافت هدر می‌دهد و هزینه‌ها و زمان را افزایش می‌دهد. MCP با بسته‌بندی تمام اطلاعات لازم، این فرآیند را ساده می‌کند و استفاده از ابزار را کارآمدتر می‌کند و به اشتراک‌گذاری ابزار را تسهیل می‌کند.

با گفتن به یک ارائه‌دهنده LLM “در اینجا ابزاری وجود دارد که می‌توانید از آن استفاده کنید” همراه با مستندات API، کاربران می‌توانند از آن ابزار در چندین چت بدون یادآوری مکرر استفاده مجدد کنند. این همچنین کلاینت‌های LLM دسکتاپ را قادر می‌سازد تا به برنامه‌هایی که به صورت محلی اجرا می‌شوند متصل شوند و مشکل فرآیندهای اجرایی خاص سیستم‌عامل را برطرف کنند.

MCP و دسترسی به منابع محلی

MCP دسترسی به منابع محلی مانند فایل‌ها، متغیرهای محیطی و دسترسی به شبکه را برای LLMها تسهیل می‌کند. این برای اجرا به صورت محلی طراحی شده است و به LLM دسترسی کنترل شده به این منابع را می‌دهد.

“شکل” فراخوانی ابزار LLM استاندارد به طور دقیق “شکل” فراخوانی ابزار MCP را منعکس می‌کند و آن را به یک استاندارد ساده برای اتصال ابزارها به عوامل تبدیل می‌کند.

MCP به عنوان پلی بین طرح فراخوانی تابع که در معرض مدل هوش مصنوعی قرار دارد و APIهای زیربنایی عمل می‌کند. این فراخوانی‌های تابع را به ابزارها تبدیل می‌کند و ارتباط یکپارچه را امکان‌پذیر می‌کند.

اگر شما ارائه‌دهنده ابزار هستید، MCP یک پروتکل استاندارد برای اتصال فرانت‌اند‌های عامل هوش مصنوعی به ابزار شما ارائه می‌دهد. این به این سوال پاسخ می‌دهد که چرا پروتکل استاندارد نمی‌تواند به سادگی HTTP و OpenAPI باشد.

MCP یک متا-API است که نقاط پایانی و جزئیات عملیاتی آن‌ها را در مشخصات گنجانده است و LLMها را قادر می‌سازد تا به طور مؤثرتری با آن‌ها تعامل داشته باشند.

MCP در سناریوهای خاص

MCP می‌تواند در حل مسائل زمانی که کاربران سؤال می‌پرسند یا مطمئن نیستند که از کدام APIها استفاده کنند، کمک کند. همچنین می‌تواند درخواست‌ها را بر اساس پیام‌های قبلی پردازش کند.

یک کاربر تجربه خود را از این که می‌خواهد “X” یک کاربر را بازیابی کرده و آن را به یک نقطه پایانی ارسال کند به اشتراک می‌گذارد. آن‌ها متوجه شدند که MCP برای چنین کار ساده‌ای بیش از حد است و نشان می‌دهد که برای تعاملات اساسی API همیشه ضروری نیست.

MCP شبیه به یک چارچوب برنامه وب FastAPI برای ساخت نرم‌افزاری است که می‌تواند از طریق شبکه ارتباط برقرار کند، به طور خاص برای تجربیات عامل محور طراحی شده است. این را می‌توان “Rails-for-Skynet” در نظر گرفت که یک چارچوب استاندارد برای توسعه عامل هوش مصنوعی ارائه می‌دهد.

نگرانی‌ها در مورد کنترل ارائه‌دهنده

نگرانی‌هایی وجود دارد که MCP در حال فشار برای افزایش کنترل سمت ارائه‌دهنده بر سیستم است. ارائه‌دهندگان LLM ممکن است در نهایت دسترسی API را محدود کنند، مشابه روشی که Google استفاده از IMAP/SMTP با Gmail را دشوار کرد.

استفاده از OpenAPI به عوامل اجازه می‌دهد تا مشخصات API را از /openapi.json بازیابی کنند.

MCP تعاملات سریع را امکان‌پذیر می‌کند و به کاربران اجازه می‌دهد تا وظایف را در عرض چند ثانیه انجام دهند تا این که زمان صرف تهیه داده‌های ورودی، ارسال آن به API، تجزیه خروجی و تکرار فرآیند برای هر پیام شود.

سندباکس و خطرات امنیتی

یکی از بزرگ‌ترین مشکلات این است که چگونه خروجی ابزار یک سرور MCP می‌تواند بر ابزارهای دیگر در همان رشته پیام تأثیر بگذارد. این امر مستلزم سندباکس بین ابزارها برای جلوگیری از عواقب ناخواسته است. آزمایشگاه‌های اینورینت این موضوع را با توضیحات ابزار برطرف کردند، در حالی که دیگران از پیوست‌های منبع MCP استفاده کرده‌اند. فقدان سندباکس خطرات تزریق سریع را تشدید می‌کند.

این شبیه به تزریق SQL است – سیستمی که به هم متصل شده است که در آن آسیب‌پذیری‌ها را می‌توان در هر نقطه با حداقل قابلیت مشاهده مورد بهره‌برداری قرار داد.

رابط اعلان نیز مستعد نوعی تزریق SQL است، زیرا مدل نمی‌تواند بخش‌های قابل اعتماد اعلان را از ورودی آلوده کاربر تشخیص دهد. حل این امر مستلزم تغییرات اساسی در رمزگذاری، رمزگشایی و آموزش مدل است.

این امر امکان تزریق سریع و تزریق ابزار را فراهم می‌کند و به طور بالقوه منجر به اجرای کد غیرقابل اعتماد می‌شود.

کانتینری‌سازی و دسترسی کنترل‌شده

یک توسعه‌دهنده یک سرور MCP ایجاد کرده است که یک کانتینر داکر را با کد پروژه نصب شده شروع می‌کند. این رویکرد به LLM اجازه می‌دهد تا به کل مجموعه ابزار یونیکس و ابزارهای خاص پروژه در یک محیط سندباکس دسترسی داشته باشد.

این گردش کار مبتنی بر عامل، که از طریق یک رابط مبتنی بر چت هدایت می‌شود، مؤثرتر از روش‌های سنتی ثابت شده است.

نکته کلیدی این است که به عوامل MCP دسترسی به آنچه نیاز دارند و نه بیشتر، بدهیم. کانتینری‌سازی و UX ابزار شفاف برای کاهش خطرات امنیتی بسیار مهم هستند.

ماشین‌های مجازی و دسترسی به اینترنت

دادن یک کامپیوتر با حداقل نصب لینوکس (به عنوان یک ماشین مجازی یا کانتینر) به عوامل می‌تواند نتایج بهتری به همراه داشته باشد و به آن‌ها اجازه می‌دهد اطلاعات را از اینترنت دریافت کنند. با این حال، این امر نگرانی‌های امنیتی را در مورد دستورالعمل‌های مخرب و خروج داده‌ها ایجاد می‌کند.

محدود کردن دسترسی به وب‌سایت‌های مورد اعتماد می‌تواند برخی از خطرات را کاهش دهد، اما حتی منابع مورد اعتماد می‌توانند محتوای مخرب را میزبانی کنند. مبادله بین احتمال مواجهه با دستورالعمل‌های مخرب و مزایای بهره‌وری باید به دقت در نظر گرفته شود.

تفاوت بین کارمندان و عوامل هوش مصنوعی قابل توجه است. کارمندان اشخاص حقوقی مشمول قوانین و قراردادها هستند که مسئولیت‌پذیری را فراهم می‌کنند. عوامل هوش مصنوعی فاقد این چارچوب قانونی هستند و اعتماد را دشوارتر می‌کنند.

مراحل اولیه توسعه MCP

MCP تنها در نوامبر 2024 اعلام شد و RFC به طور فعال در حال تکامل است.

برخی کل مفهوم دستیار شخصی هوش مصنوعی، از جمله MCP را اساساً ناقص می‌دانند.

فشار اولیه برای دستیاران هوش مصنوعی در اواخر دهه 1990 و اوایل دهه 2000 شکست خورد زیرا جمع‌آوری‌کننده‌های محتوا با یکپارچگی عمودی و قدرت خرید عمده مؤثرتر بودند. این منجر به ظهور پلتفرم‌هایی مانند Expedia و eBay شد.

سیستم‌های چندعاملی از برنامه‌نویسان می‌خواهند تا بر وضعیت عوامل تأثیر بگذارند، که یک وظیفه برنامه‌نویسی چالش‌برانگیز است.

محدودیت‌های ارزش رایگان

تمایل به “رتبه‌بندی نتایج بر اساس دسترسی به پارکینگ” مسئله دسترسی به داده‌های پشت APIهای پولی یا فرانت‌اند‌های پشتیبانی‌شده با تبلیغات را برجسته می‌کند. بعید است که شرکت‌ها دسترسی رایگان به کل مجموعه داده‌های خود را از طریق یک API ارائه دهند.

در حالی که همه شرکت‌ها داده‌های خود را در عوامل هوش مصنوعی ادغام نمی‌کنند، پتانسیل ترکیب ابزارهای مختلف برای قدرت بخشیدن به گردش کار همچنان قابل توجه است.

شرکت‌هایی که حفظ یک سنگر داده را در اولویت قرار می‌دهند، احتمالاً در برابر فناوری‌های جدیدی که آن سنگر را تهدید می‌کنند مقاومت می‌کنند.

اگر booking.com یک API داشت، احتمالاً همان نتایج وب‌سایت خود را برمی‌گرداند، احتمالاً با قالب‌بندی JSON یا XML.

دور زدن واسطه

منطقی نیست که یک واسطه مانند booking.com به کاربران اجازه دهد خدمات خود را به طور کامل دور بزنند.

با این حال، هتل‌های انفرادی ممکن است دور زدن booking.com را مفید بدانند، واسطه‌ای که اغلب از آن بیزارند.

یک هوش مصنوعی تحقیقات عمیق می‌تواند هتل‌ها را بر اساس معیارهای خاص اسکن کند و با سرورهای MCP کشف هتل که توسط هتل‌های انفرادی اجرا می‌شوند، تعامل کند و از نیاز به پیمایش رابط و تبلیغات booking.com جلوگیری کند.

موارد استفاده عملی

MCP می‌تواند وظایفی مانند دریافت گزارش‌ها از Elasticsearch یا پرس و جو از پایگاه‌های داده را به روشی ساختاریافته‌تر تسهیل کند.

طبیعت استاتیک پیکربندی سرور MCP، جایی که سرورهای جدید نیاز به ویرایش یک فایل .json و راه اندازی مجدد برنامه دارند، می‌تواند محدود کننده باشد.

مدل‌های خوب تنظیم‌شده

MCP را می‌توان به عنوان یک مدل کوچک و خوب تنظیم‌شده در نظر گرفت که ابزارهای متعدد MCP را درک می‌کند و ابزارهای مناسب را برای هر مکالمه انتخاب می‌کند.

تنظیم پویای ابزارها بر اساس زمینه ممکن است برای سناریوهای خاص ضروری باشد.

مکالمات باز و مسائل تجاری

MCP برای سیستم‌های مکالمه عمومی و باز با جریان از پیش تعریف نشده مناسب است. با این حال، این یک راه حل یک اندازه مناسب برای همه مشکلات تجاری نیست. هدف آن جایگزینی چارچوب‌هایی مانند LangChain نیست.

جایگزین MCP، یک استاندارد باز مبتنی بر جامعه، پروتکل‌های شکسته، اختصاصی و قفل شده توسط فروشنده است. یک استاندارد ناقص اما در حال تکامل بر هیچ استانداردی ترجیح داده می‌شود.

بهترین راه برای مشاهده MCP، انتقال از توسعه‌دهندگان فردی است که پوشش‌های کلاینت را در اطراف APIها می‌سازند به ارائه‌دهندگان API یا پوشش‌های نگهداری شده توسط جامعه که آن‌ها را می‌سازند. این یک جعبه ابزار بزرگ، شبیه به NPM یا PyPi ارائه می‌دهد. با این حال، هماهنگی، امنیت و تعریف استفاده همچنان مورد نیاز است.

نسل بعدی Langchains از این جعبه ابزار بزرگتر بهره‌مند می‌شود، اما نوآوری همچنان مورد نیاز است.

ابزارهای خاص کاربر

در برخی موارد، ابزارها ممکن است مختص داده‌های کاربر باشند، مانند ابزارهایی برای برش و دستکاری فایل‌های CSV آپلود شده.

یکی از مسائل اغلب نادیده گرفته شده این است که MCP می‌تواند با گزینه‌های بسیار زیاد بافت مدل را شلوغ کند. اولویت‌بندی و افشای فراداده برای جلوگیری از استفاده هدر رفته از توکن و رفتار نامنظم مدل بسیار مهم است.

استانداردها و فناوری در حال تحول

استانداردهای جدید با گذشت زمان ظهور می‌کنند و آنقدر مدت زیادی از زمانی که استانداردها واقعاً مهم بودند می‌گذرد که مردم فراموش کرده‌اند که چگونه توسعه می‌یابند.

دانلود برنامه‌های سرور کوچک از توسعه‌دهندگان تصادفی برای افزودن “ابزار” به کلاینت‌های LLM می‌تواند خطرناک باشد.

مسائل مطرح شده مشکلات مشروعی هستند که اکوسیستم MCP باید به آن‌ها رسیدگی کند. برخی از راه‌حل‌ها در مشخصات MCP خواهند بود، در حالی که برخی دیگر خارجی خواهند بود.

کد کلود و استفاده در دنیای واقعی

نظرات متضادی در مورد موفقیت MCP وجود دارد. برخی داستان‌هایی از شرکت‌هایی که با MCP ادغام شده‌اند شنیده‌اند، در حالی که برخی دیگر از کاربرانی شنیده‌اند که آن را ناامیدکننده یافته‌اند.

این نکته ضعف تبلیغات و پذیرش زودهنگام را برجسته می‌کند.

برخی از توسعه‌دهندگان بر این باورند که APIهای HTTP برای اکثر موارد استفاده بر MCP برتر هستند. آن‌ها استدلال می‌کنند که استفاده از “ابزار” به نقاط پایانی API برای قابلیت‌ها و عملکرد خلاصه می‌شود.

APIها به طور پیش‌فرض خود توصیف نمی‌شوند، و فرصت از دست رفته برای طرفداران REST و HATEOAS برای به نمایش گذاشتن رویکردهای خود را نشان می‌دهند.

MCP به عنوان جایگزینی برای LangChain؟

MCP به داشتن “بوی LangChain” توصیف شده است - حل نکردن یک مشکل فوری، بیش از حد انتزاعی بودن و داشتن مشکل در توضیح مزایای خود.

شاید لازم باشد بگوید “پایان خط” و هکرهای مشتاق را به شبکه بازی تبعید کند!

یک سوال کلیدی این است که آیا الگوی چت بات “عمومی” همچنان ادامه خواهد داشت یا خیر. برنامه‌های تخصصی با ابزارهای خاص خود ممکن است نیازی به MCP نداشته باشند.

برعکس، با تواناتر شدن LLMها، ابزارهای خارجی ممکن است کمتر ضروری شوند. چرا باید بخواهید یک MCP Photoshop را هدایت کند، در حالی که LLM می‌تواند به سادگی تصویر را مستقیماً ویرایش کند؟

رویای دستیار روباتیک علمی تخیلی ممکن است محقق نشود و ابزارهای دستکاری زبان تخصصی ممکن است مفیدتر باشند.

پایگاه کاربر و آگاهی امنیتی

پایگاه کاربر MCP شامل افراد کم‌تر فنی است که مسائل امنیتی را به طور خاص مرتبط می‌کند. افزایش آگاهی از بهترین شیوه‌های امنیتی بسیار مهم است.

مبتنی کردن Xops بر OpenRPC که نیاز به تعریف طرح نتیجه دارد، به برنامه‌ریزی نحوه اتصال خروجی‌ها به ورودی‌ها کمک می‌کند و قابلیت اطمینان را برای گردش کارهای پیچیده بهبود می‌بخشد.

این فناوری احتمالاً با گذشت زمان تکامل می‌یابد و مستقر می‌شود.

افزونگی و زیرساخت ابری

برخی در مورد مزایای استفاده از MCP نسبت به استاندارد OpenAPI سوال می‌پرسند و آن را افزونه می‌دانند.

LLM برای تماس با یک سیستم OpenAPI از چه چیزی استفاده خواهد کرد؟ چگونه به شل متصل می‌شود؟ چگونه میزبان LLM آن را هماهنگ می‌کند؟

MCP روشی ساختاریافته برای ایجاد فراخوانی ابزار توسط LLMها فراهم می‌کند.

سرورهای MCP از قبل سرورهای HTTP هستند.

بزرگ‌ترین مزیت MCP برای ارائه‌دهندگان LLM مانند OpenAI است، نه توسعه‌دهندگان برنامه.

LLMها مغزهای بدون ابزار هستند و فراخوانی ابزار به آن‌ها قدرت می‌دهد. با این حال، با APIهای معمولی، ارائه‌دهندگان LLM به آن ابزارها دسترسی ندارند. MCP به آن‌ها دسترسی می‌دهد و آن‌ها را به عنوان دروازه هوش مصنوعی قرار می‌دهد.

CLI در مقابل API

چرا مستقیماً از CLI استفاده نکنیم، با توجه به اینکه LLMها بر روی زبان طبیعی آموزش داده شده‌اند و CLIها یک راه حل قابل خواندن و نوشتن انسانی رایج هستند؟

MCP خیلی سریع ظهور کرد و نیاز به زمان دارد تا بالغ شود. فاقد بررسی توسط یک نهاد استانداردهای متعارف است و با تبلیغات هدایت می‌شود.

کمبود برنامه‌های کاربردی دنیای واقعی وجود دارد.

برنامه‌های کاربردی کلیدی MCP

MCP در کلود دسکتاپ و برنامه‌های چت هوش مصنوعی تخصصی، ابزارهای اتوماسیون کد و چارچوب‌های اتوماسیون عامل/LLM استفاده می‌شود.

این یکی دیگر از فناوری‌های شتاب‌زده است که احتمالاً زمانی که مخفف قابل تبلیغ بعدی وارد شود، کنار گذاشته می‌شود.

دو نوع پروتکل فراخوانی ابزار مدل زبانی وجود دارد: پروتکل‌هایی که مردم از آن‌ها شکایت می‌کنند و پروتکل‌هایی که هیچ‌کس از آن‌ها استفاده نمی‌کند.

Anthropic این “استاندارد” را در خلاء توسعه داد که منجر به مسائل امنیتی شد.

JSON-RPC 2.0

MCP بر روی JSON-RPC 2.0 ساخته شده است، یک پروتکل سبک وزن که ارتباط کلاینت و سرور را با استفاده از JSON امکان‌پذیر می‌کند.

این احساس یک مشخصات متمرکز است که برای یک اکوسیستم خاص طراحی شده است، ادعای جهانی بودن دارد بدون اینکه آن را به دست آورد.

MCP به اندازه کافی قدرتمند است که کارهای مفیدی انجام دهد که نگرانی‌های امنیتی را افزایش می‌دهد.

این یک استاندارد بالغ نیست و برای ایمن بودن طراحی نشده است.

در حالی که توصیه‌هایی وجود دارد، آن‌ها اجرا یا پیاده‌سازی نمی‌شوند.

Langchain و فراخوانی ابزار

Langchain یکی از بسیاری از چارچوب‌هایی است که الگوی “فراخوانی ابزار” را پیاده‌سازی می‌کند.

MCP یک مشخصات برای نحوه ورود اطلاعات خارجی به پنجره بافت یک مدل زبانی است، از جمله فراخوانی ابزار، ورودی الگو، لغو، ردیابی پیشرفت و حالت‌داری سرورهای ابزار.

این به استانداردسازی جزئیات کمک می‌کند تا هر ترکیب دستیار/ادغام سازگار باشد.

در حالی که MCP مشکلات مشروعی دارد، منتقدان باید استدلال‌های خود را اصلاح کنند.

احراز هویت بسیار مهم است و نباید از نسخه اولیه حذف می‌شد.

پیچیدگی‌های بسیار زیادی وجود دارد.