إرهاق مسؤوليات MCP
أحد الانتقادات الشائعة هو تكليف MCP بالكثير من المسؤوليات. يجادل المؤلف بأنه يجب أن يكون بمثابة بوابة لنماذج LLM للوصول إلى الموارد الخارجية والتفاعل معها. إن النظر إليه على أنه مجرد ‘باب’ أو ‘جسر’ يساعد في توضيح الغرض منه وقيوده.
إن عزو قضايا مثل التعرض العرضي للبيانات، ونقاط الضعف في حقن المطالبات، وأوجه القصور في التحكم في التكاليف مباشرة إلى MCP هو سوء توجيه للوم. هذه مشاكل يجب على المطورين معالجتها ضمن الحدود التي يتحكمون فيها. يحتاج المطورون إلى تنفيذ حدود المعدل ومراقبة الاستخدام، بغض النظر عن البروتوكول المستخدم. إن مساواة هذا بلوم الطريق بسبب السرعة أمر مناسب – فالبنية التحتية ليست مسؤولة عن السلوك الفردي.
في نهاية المطاف، فإن العديد من المخاوف المثارة هي قضايا أوسع تتعلق بتفويض المهام إلى وكلاء الذكاء الاصطناعي. يجب على المطورين تحمل مسؤولية إدارة هذه التحديات داخل تطبيقاتهم المحددة، بدلاً من توقع أن تتعامل واجهة برمجة التطبيقات نفسها مع كل شيء.
سيف LLMs ذو حدين وحقن المطالبات
غالبًا ما تشبه المناقشات الحديثة حول MCP تحذيرات بشأن المخاطر الكامنة في السكاكين الحادة - يمكن أن تقطع إذا أسيء التعامل معها. إن حقن المطالبات، وهو مصدر قلق كبير، هو نتيجة لطبيعة نماذج LLM نفسها. إن محاولات القضاء على خطر حقن المطالبات تؤدي إلى تدهور القدرات التي تجعل نماذج LLM ذات قيمة.
إن مفهوم الفصل بين ‘التحكم مقابل البيانات’، الشائع في الأنظمة التقليدية، غير موجود بشكل طبيعي في نماذج LLM. تكتسب LLMs قوتها وعموميتها على وجه التحديد لأنها تفتقر إلى هذا الفصل الجامد. هذه الخاصية المتأصلة تجعلها عرضة لهجمات حقن المطالبات.
في حين أن MCPs البعيدة كخدمة قد تمثل مخاطر، فإن الخطأ لا يقع على البروتوكول نفسه ولكن على تكليف مهام حساسة بأطراف ثالثة غير موثوق بها. يمتد هذا التشبيه إلى فكرة لصق سكين بشريط لاصق على Roomba غير منتظم - المشكلة ليست في السكين نفسه، ولكن في قرار توصيله بجهاز لا يمكن التنبؤ به.
إن التحذيرات ‘كن حذرًا’ أو اقتراحات معدات الحماية، على الرغم من دقتها من الناحية الفنية، تفوت القضية الأساسية: القرار غير الحكيم بدمج أداة حادة مع نظام غير خاضع للرقابة.
تحديات قابلية التوسع
بالإضافة إلى المخاوف الأمنية، يواجه MCP قيودًا أساسية في قابلية التوسع. يسلط المؤلف الضوء على الارتباط السلبي بين موثوقية LLM وكمية السياق التعليمي المقدم. هذا يتحدى الاعتقاد السائد بأن إضافة المزيد من البيانات والتكاملات سيحل المشكلات تلقائيًا. مع زيادة عدد الأدوات والتكاملات، قد يتدهور أداء الوكيل مع زيادة تكلفة كل طلب في الوقت نفسه.
يؤكد المؤلف على أن MCP لا يتوسع إلى ما بعد عتبة معينة. إن محاولة إضافة عدد غير محدود من الأدوات إلى سياق الوكيل سيؤثر حتمًا سلبًا على قدراته. هذا القيد متأصل في مفهوم MCP ويتطلب اهتمامًا أكبر من مشكلات المصادقة.
قد يواجه المستخدمون في النهاية انخفاضًا في الأداء عند تمكين المزيد من خوادم MCP، مما يؤدي إلى تداخل بينها. هذا يتناقض بشكل صارخ مع أنظمة إدارة الحزم النموذجية، حيث عدم التدخل هو خاصية أساسية.
المشكلة الأساسية في MCP هي أن سلوكه الفعلي ينحرف عن توقعات المستخدم. من الضروري الاعتراف بأن MCP ليس حلاً للتوصيل والتشغيل يدمج بسلاسة عددًا غير محدود من الأدوات دون عواقب.
معالجة القيود باستخدام واجهة المستخدم وإدارة الأدوات
أحد الحلول المقترحة لقيود MCP هو تحسين واجهة المستخدم. إذا تم تنفيذ أداة عن غير قصد، فيجب أن توفر واجهة المستخدم طريقة سهلة لتعطيلها أو تعديل وصفها لتوضيح استخدامها المقصود.
يشير المؤلف أيضًا إلى أن نمو السياق غالبًا ما يؤدي إلى تحسين الأداء وقدرات الاستخدام في العالم الحقيقي، مما يتعارض مع فكرة الارتباط السلبي الصارم. ومع ذلك، فإنهم يقرون بأنه في حالات استخدام معينة أو مع سياقات سيئة التصميم، يمكن أن يحدث تدهور في الأداء.
لمعالجة الاختيار الساحق للأدوات، يُقترح اتباع نهج ‘فرق تسد’. يتضمن ذلك إضافة أداة مصممة خصيصًا لتحديد الأدوات الأكثر صلة بمهمة معينة. يمكن أن تكون ‘أداة اختيار الأدوات’ هذه عبارة عن استدعاء LLM آخر، مكلف بإرجاع مجموعة فرعية من الأدوات المتاحة إلى الوكيل ‘الأصل’. يضيف هذا النهج متعدد الطبقات مستويات إضافية من الاتجاه غير المباشر لإدارة التعقيد.
ومع ذلك، فإن مجرد وجود أدوات في السياق يمكن أن يغير بشكل كبير من إخراج النموذج. في حين أن الأدوات ذات الصلة بالسياق (التي يتم تحقيقها من خلال تقنيات مثل الاسترجاع المعزز أو RAG) مفيدة، إلا أن إخفاء جميع الأدوات خلف طلب ‘get_tools’ يمكن أن يكون ضارًا.
MCP كطبقة نقل وتفويض
يعمل MCP بشكل أساسي كطبقة نقل وتنسيق سلكي مع دورة حياة طلب/استجابة، مع التركيز على التفويض على مستوى الأداة. يجادل المقال بأن أكبر مشكلة في MCP هي فشله في تمكين وكلاء الذكاء الاصطناعي من تجميع الأدوات وظيفيًا.
يفترض المؤلف أن MCP قد يكون غير ضروري في المقام الأول، حيث أن LLMs تمتلك بالفعل القدرة على التفاعل مع واجهات برمجة التطبيقات الموثقة باستخدام مواصفات OpenAPI. العنصر المفقود هو التفويض – القدرة على التحكم في واجهات برمجة التطبيقات التي يمكن للذكاء الاصطناعي الوصول إليها. بدلاً من MCP، يقترح المؤلف السماح للذكاء الاصطناعي بتقديم طلبات HTTP مع تطبيق التفويض على نقاط نهاية محددة. يتماشى هذا النهج مع الاتجاه الحالي المتمثل في تغليف واجهات برمجة التطبيقات الحالية بأدوات MCP رقيقة.
أحد الجوانب المزعجة بشكل خاص في MCP هو افتقاره إلى دعم نتائج استدعاء الأداة المتدفقة. يجبر زوج الطلب/الاستجابة الفردي العملاء على استدعاء الأدوات بشكل متكرر للتصفح، مما يعيق العمليات طويلة الأمد. يمكن لتنفيذ إمكانية البث، ربما باستخدام gRPC، أن يحسن بشكل كبير من كفاءة MCP.
سهولة كشف البيانات الحساسة
أحد المخاوف الكبيرة بشأن MCP هو الاحتمال في سهولة كشف البيانات الحساسة. علاوة على ذلك، لا تجعل MCP وكلاء الذكاء الاصطناعي أكثر موثوقية بطبيعتها؛ بل إنها ببساطة تمنحهم الوصول إلى المزيد من الأدوات، مما قد يقلل بشكل متناقض من الموثوقية في مواقف معينة.
يقر المؤلف بأنهم لا يتوقعون أن يحل MCP أو يكون مسؤولاً عن كل هذه المشكلات. بدلاً من ذلك، يخلق MCP مساحة سطح أكبر لهذه المشكلات، مما يتطلب من مطوري التطبيقات والمستخدمين أن يكونوا يقظين.
القياس والتحضير الحضري
يستخدم المؤلف تشبيه التخطيط الحضري لتوضيح القضية. إن مقارنة MCP بطريق مدينة بستة حارات بحد أقصى للسرعة يبلغ 25 ميلاً في الساعة يسلط الضوء على الانفصال بين التصميم والاستخدام المقصود. إن مجرد فرض الغرامات أو إضافة ‘إصلاحات’ سطحية لا يعالج المشكلة الأساسية المتمثلة في التصميم الضعيف.
يتضمن التخطيط الحضري الفعال تصميم طرق تشجع بشكل طبيعي على الالتزام بحدود السرعة. وبالمثل، يجب تصميم MCP لتقليل المخاطر المحتملة بطبيعتها، بدلاً من الاعتماد فقط على الضوابط الخارجية.
LLMs تتخذ إجراءات غير مرغوب فيها
تنتقل المقالة إلى نقد أوسع للبروتوكولات التي تسمح لـ LLMs بتنفيذ إجراءات على الخدمات. يحدد المؤلف مشكلة أساسية: قد تتخذ LLMs إجراءات لا ينوي المستخدمون اتخاذها. يميزون بين الإجراءات التي يمكن لـ LLMs اتخاذها بشكل مستقل والإجراءات التي تتطلب مطالبة المستخدم.
في حين أن الهدف النهائي قد يكون أن تدير LLMs الشركات بأكملها، إلا أن التكنولوجيا ليست جاهزة بعد لمثل هذا الاستقلالية. حاليًا، قد لا يرغب المستخدمون حتى في أن ترسل الذكاء الاصطناعي رسائل بريد إلكتروني دون مراجعة مسبقة.
يرفض المؤلف حل مطالبة المستخدم بالتأكيد، مستشهداً بخطر وقوع المستخدمين في نمط من التأكيد التلقائي (‘وضع YOLO’) عندما تبدو معظم الأدوات غير ضارة. وهذا يشبه الظاهرة النفسية المتمثلة في إنفاق الأشخاص المزيد بالبطاقات مقارنة بالنقد – وهي مشكلة متجذرة في السلوك البشري، وليس التكنولوجيا.
السؤال الأساسي: لماذا لا تستخدم واجهات برمجة التطبيقات ببساطة؟
السؤال المتكرر في المناقشات حول MCP هو لماذا لا تستخدم واجهات برمجة التطبيقات ببساطة بشكل مباشر.
يسمح MCP لعملاء LLM الذين لا يتحكم فيهم المستخدمون بشكل مباشر (مثل Claude وChatGPT وCursor وVSCode) بالتفاعل مع واجهات برمجة التطبيقات. بدون MCP، سيحتاج المطورون إلى إنشاء عملاء مخصصين باستخدام واجهات برمجة تطبيقات LLM، وهي مهمة أكثر تكلفة بكثير من استخدام العملاء الحاليين مع اشتراك وتعليمهم كيفية استخدام أدوات معينة.
يشارك أحد المطورين تجربته في بناء خادم MCP للاتصال بجهاز توليف الأجهزة FM الخاص به عبر USB، مما يتيح تصميم الصوت المدفوع بالذكاء الاصطناعي.
تكامل عميل LLM والتوحيد القياسي
تتمثل المشكلة الأساسية في أن ليس كل عملاء LLM يدعمون أصلاً التفاعل المباشر مع واجهة برمجة التطبيقات، مع كون إجراءات ChatGPT المخصصة GPT استثناءً ملحوظًا. وافقت Anthropic وGoogle وOpenAI على اعتماد MCP كبروتوكول مشترك لتبسيط العملية للعملاء المدعومين بـ LLM مثل Claude وChatGPT وCursor.
يبسط MCP العملية لأولئك الذين يبنون عملاء LLM. إذا كنت تريد أن يتفاعل LLM مع واجهة برمجة تطبيقات، فلا يمكنك ببساطة تقديم مفتاح واجهة برمجة تطبيقات وتوقع أن يعمل - تحتاج إلى إنشاء وكيل.
يمكن اعتبار MCP طريقة لتوثيق واجهات برمجة التطبيقات ووصف كيفية استدعائها، إلى جانب أدوات موحدة لعرض هذا التوثيق وتسهيل المكالمات. يوفر تجريدًا كافيًا لتغليف واجهات برمجة التطبيقات دون تعقيد غير ضروري، ولكن هذه البساطة يمكن أن تؤدي أيضًا إلى ‘إطلاق النار على أنفسهم في القدم’.
كفاءة MCP وإعادة استخدامه
بدون MCP، سيحتاج المطورون إلى شرح كيفية استخدام أداة لـ LLM بشكل متكرر في كل مرة يتم استدعاؤها. يحمل هذا خطر فشل LLM في استخدام الأداة بشكل صحيح بسبب المعلومات المنسية أو سلوك واجهة برمجة التطبيقات غير القياسي.
يؤدي هذا الشرح والتكرار المستمر إلى إهدار الرموز في السياق، مما يزيد التكاليف والوقت. يعمل MCP على تبسيط هذه العملية عن طريق تجميع جميع المعلومات الضرورية، مما يجعل استخدام الأداة أكثر كفاءة وتسهيل مشاركة الأداة.
من خلال إخبار مزود LLM ‘إليك أداة يمكنك استخدامها’ جنبًا إلى جنب مع وثائق واجهة برمجة التطبيقات، يمكن للمستخدمين إعادة استخدام هذه الأداة عبر محادثات متعددة دون تذكيرات متكررة. يتيح ذلك أيضًا لعملاء LLM على سطح المكتب الاتصال بالبرامج التي تعمل محليًا، ومعالجة مشكلة عمليات التنفيذ الخاصة بنظام التشغيل.
MCP والوصول إلى الموارد المحلية
يسهل MCP الوصول إلى الموارد المحلية مثل الملفات ومتغيرات البيئة والوصول إلى الشبكة لـ LLMs. إنه مصمم ليتم تشغيله محليًا، مما يمنح LLM وصولاً خاضعًا للرقابة إلى هذه الموارد.
يشبه ‘شكل’ استدعاء أداة LLM القياسي عن كثب ‘شكل’ استدعاء أداة MCP، مما يجعله معيارًا واضحًا لتوصيل الأدوات بالوكلاء.
يعمل MCP كجسر بين مخطط استدعاء الوظيفة المعروض على نموذج الذكاء الاصطناعي وواجهات برمجة التطبيقات الأساسية. يترجم استدعاءات الوظائف إلى أدوات، مما يتيح اتصالاً سلسًا.
إذا كنت مزود أداة، فإن MCP يقدم بروتوكولًا موحدًا لواجهات الذكاء الاصطناعي للوكيل الأمامية للاتصال بأداتك. هذا يجيب على سؤال لماذا لا يمكن أن يكون البروتوكول القياسي ببساطة HTTP وOpenAPI.
MCP عبارة عن واجهة برمجة تطبيقات وصفية تتضمن نقاط نهاية وتفاصيلها التشغيلية في المواصفات، مما يمكن LLMs من التفاعل معها بشكل أكثر فعالية.
MCP في سيناريوهات محددة
يمكن لـ MCP حل المشكلات عندما يطرح المستخدمون أسئلة أو يكونون غير متأكدين من واجهات برمجة التطبيقات التي يجب استخدامها. يمكنه أيضًا معالجة الطلبات بناءً على الرسائل السابقة.
يشارك أحد المستخدمين تجربته في الرغبة في استرداد ‘X’ الخاص بالمستخدم وإرساله إلى نقطة نهاية. وجدوا أن MCP مبالغ فيه لمثل هذه المهمة البسيطة، مما يشير إلى أنه ليس ضروريًا دائمًا للتفاعلات الأساسية مع واجهة برمجة التطبيقات.
يشبه MCP إطار عمل تطبيق ويب FastAPI لبناء برامج يمكنها الاتصال عبر الشبكة، ومصممة خصيصًا لتجارب الوكيل. يمكن اعتباره ‘Rails-for-Skynet’، مما يوفر إطارًا موحدًا لتطوير وكيل الذكاء الاصطناعي.
مخاوف بشأن سيطرة المزود
هناك مخاوف من أن يتم دفع MCP لزيادة سيطرة المزود على النظام. قد يقيد مزودو LLM في النهاية الوصول إلى واجهة برمجة التطبيقات، على غرار الطريقة التي جعلت بها Google من الصعب استخدام IMAP/SMTP مع Gmail.
يتيح استخدام OpenAPI للوكلاء استرداد مواصفات واجهة برمجة التطبيقات من ‘/openapi.json’.
يتيح MCP تفاعلات سريعة، مما يسمح للمستخدمين بإنجاز المهام في ثوانٍ بدلاً من قضاء الوقت في إعداد بيانات الإدخال وإرسالها إلى واجهة برمجة التطبيقات وتحليل الإخراج وتكرار العملية لكل رسالة.
الحماية من التلاعب والمخاطر الأمنية
تتمثل إحدى أكبر المشكلات في كيفية تأثير إخراج أداة خادم MCP واحد على الأدوات الأخرى في نفس سلسلة الرسائل. وهذا يستلزم الحماية من التلاعب بين الأدوات لمنع العواقب غير المقصودة. عالجت مختبرات Invariant هذا بأوصاف الأدوات، بينما استخدم آخرون مرفقات موارد MCP. يؤدي عدم الحماية من التلاعب إلى تفاقم مخاطر حقن المطالبات.
وهذا يشبه حقن SQL – نظام تم تجميعه معًا حيث يمكن استغلال نقاط الضعف في أي نقطة بأقل قدر من الملاحظة.
واجهة المطالبة عرضة أيضًا لشكل من أشكال حقن SQL، حيث لا يستطيع النموذج التمييز بين الأجزاء الموثوقة من المطالبة والإدخال الملوث للمستخدم. يتطلب حل هذا تغييرات جوهرية في الترميز وفك الترميز وتدريب النموذج.
يسمح هذا بكل من حقن المطالبات وحقن الأدوات، مما قد يؤدي إلى تنفيذ تعليمات برمجية غير جديرة بالثقة.
الحاويات والوصول الخاضع للرقابة
قام أحد المطورين بإنشاء خادم MCP يبدأ حاوية Docker مع تركيب رمز المشروع. يسمح هذا النهج لـ LLM بالوصول إلى مجموعة أدوات Unix بأكملها والأدوات الخاصة بالمشروع داخل بيئة محمية من التلاعب.
لقد ثبت أن سير العمل هذا، الذي يتم تشغيله من خلال واجهة قائمة على الدردشة، أكثر فعالية من الطرق التقليدية.
المفتاح هو منح وكلاء MCP الوصول إلى ما يحتاجون إليه، وليس أكثر. الحاويات و UX الأداة الشفافة أمران بالغان الأهمية للتخفيف من المخاطر الأمنية.
الآلات الافتراضية والوصول إلى الإنترنت
يمكن أن يؤدي منح الوكلاء جهاز كمبيوتر مع تثبيت Linux بسيط (كجهاز افتراضي أو حاوية) إلى نتائج أفضل، مما يسمح لهم بجلب المعلومات من الإنترنت. ومع ذلك، يثير هذا مخاوف أمنية بشأن التعليمات الضارة وتسريب البيانات.
يمكن أن يؤدي تقييد الوصول إلى مواقع الويب الموثوقة إلى التخفيف من بعض المخاطر، ولكن حتى المصادر الموثوقة يمكن أن تستضيف محتوى ضارًا. يجب النظر بعناية في المفاضلة بين احتمالية مواجهة تعليمات ضارة وفوائد الإنتاجية.
الاختلافات بين الموظفين ووكلاء الذكاء الاصطناعي كبيرة. الموظفون هم أشخاص اعتباريون يخضعون للقوانين والعقود، مما يوفر المساءلة. يفتقر وكلاء الذكاء الاصطناعي إلى هذا الإطار القانوني، مما يجعل الثقة أكثر صعوبة.
المراحل المبكرة من تطوير MCP
تم الإعلان عن MCP فقط في نوفمبر 2024، و RFC يتطور بنشاط.
يرى البعض أن مفهوم المساعد الشخصي للذكاء الاصطناعي بأكمله، بما في ذلك MCP، معيب بشكل أساسي.
فشلت الدفعة الأولية لمساعدي الذكاء الاصطناعي في أواخر التسعينيات وأوائل العقد الأول من القرن الحادي والعشرين لأن مجمعي المحتوى مع التكامل الرأسي وقوة الشراء بالجملة أثبتوا أنهم أكثر فعالية. أدى ذلك إلى ظهور منصات مثل Expedia وeBay.
تتطلب الأنظمة متعددة الوكلاء من المبرمجين التأثير على حالة الوكلاء، وهي مهمة برمجة صعبة.
حدود القيمة المجانية
تسلط الرغبة في ‘ترتيب النتائج حسب توفر مواقف السيارات’ الضوء على قضية الوصول إلى البيانات خلف واجهات برمجة تطبيقات مدفوعة أو واجهات أمامية مدعومة بالإعلانات. من غير المرجح أن توفر الشركات وصولاً مجانيًا إلى مجموعة البيانات بأكملها من خلال واجهة برمجة تطبيقات.
في حين أن ليس كل الشركات ستدمج بياناتها في وكلاء الذكاء الاصطناعي، إلا أن إمكانية الجمع بين الأدوات المختلفة لتشغيل سير العمل تظل كبيرة.
من المرجح أن تقاوم الشركات التي تعطي الأولوية للحفاظ على خندق بيانات التكنولوجيات الجديدة التي تهدد هذا الخندق.
إذا كان لدى booking.com واجهة برمجة تطبيقات، فمن المحتمل أنهم سيعيدون نفس النتائج التي يعرضها موقع الويب الخاص بهم، ربما بتنسيق JSON أو XML.
تجاوز الوسيط
ليس من المنطقي أن يسمح وسيط مثل booking.com للمستخدمين بتجاوز خدماتهم تمامًا.
ومع ذلك، قد تجد الفنادق الفردية أنه من المفيد تجاوز booking.com، وهو وسيط غالبًا ما يكرهونه.
يمكن لـ Deep Research AI البحث عن الفنادق بناءً على معايير محددة والتفاعل مع خوادم Hotel Discovery MCP التي تديرها الفنادق الفردية، متجاوزة الحاجة إلى التنقل في واجهة booking.com وإعلاناتها.
حالات الاستخدام العملية
يمكن لـ MCP تسهيل مهام مثل جلب السجلات من Elasticsearch أو الاستعلام عن قواعد البيانات بطريقة أكثر تنظيماً.
يمكن أن تكون الطبيعة الثابتة لتكوين خادم MCP، حيث تتطلب الخوادم الجديدة تحرير ملف ‘.json’ وإعادة تشغيل التطبيق، محدودة.
نماذج مضبوطة بدقة
يمكن اعتبار MCP نموذجًا صغيرًا ومضبوطًا بدقة يفهم العديد من أدوات MCP ويختار الأدوات المناسبة لكل محادثة.
قد يكون تعديل الأدوات ديناميكيًا بناءً على السياق ضروريًا لسيناريوهات معينة.
محادثات مفتوحة ومشاكل تجارية
يعد MCP مناسبًا تمامًا لأنظمة المحادثة العامة والمفتوحة ذات النهاية التي ليس لها تدفق محدد مسبقًا. ومع ذلك، فهو ليس حلاً واحدًا يناسب الجميع لكل مشكلة تجارية. لم يتم تصميمه ليحل محل أطر عمل مثل LangChain.
البديل لـ MCP، وهو معيار مفتوح مدفوع بالمجتمع، هو بروتوكولات مجزأة وخاصة ومغلقة من البائعين. إن المعيار المعيب ولكنه المتطور أفضل من عدم وجود معيار على الإطلاق.
أفضل طريقة لعرض MCP هي الانتقال من قيام المطورين الأفراد ببناء أغلفة عملاء حول واجهات برمجة التطبيقات إلى قيام موفري واجهة برمجة التطبيقات أو الأغلفة التي يحتفظ بها المجتمع ببنائها. يوفر هذا مجموعة أدوات كبيرة، على غرار NPM أو PyPi. ومع ذلك، لا تزال هناك حاجة إلى التنسيق والأمن وتعريف الاستخدام.
سيستفيد الجيل التالي من Langchains من صندوق الأدوات الأكبر هذا، ولكن لا تزال هناك حاجة إلى الابتكار.
أدوات خاصة بالمستخدم
في بعض الحالات، قد تكون الأدوات خاصة ببيانات المستخدم، مثل أدوات لتقطيع ومعالجة ملفات CSV التي تم تحميلها.
إحدى المشكلات التي غالبًا ما يتم تجاهلها هي أن MCP يمكن أن تزدحم سياق النموذج بالعديد من الخيارات. تعد الأولوية وعرض البيانات التعريفية أمرًا بالغ الأهمية لتجنب الاستخدام المسرف للرمز وسلوك النموذج غير المنتظم.
المعايير والتكنولوجيا المتطورة
تظهر معايير جديدة بمرور الوقت، وقد مضى وقت طويل على أهمية المعايير حقًا لدرجة أن الناس نسوا كيف تتطور.
يمكن أن يكون تنزيل برامج الخادم الصغيرة من مطورين عشوائيين لإضافة ‘أدوات’ إلى عملاء LLM أمرًا محفوفًا بالمخاطر.
المشكلات المثارة هي مشاكل مشروعة يجب على نظام MCP البيئي معالجتها. ستكون بعض الحلول ضمن مواصفات MCP، بينما سيكون البعض الآخر خارجيًا.
رمز كلود والاستخدام في العالم الحقيقي
هناك آراء متباينة حول نجاح MCP. سمع البعض قصصًا عن شركات تتكامل مع MCP، بينما سمع آخرون من المستخدمين الذين وجدوا أنها مخيبة للآمال.
وهذا يسلط الضوء على عيب الضجيج والتبني المبكر.
يرى بعض المطورين أن واجهات برمجة تطبيقات HTTP متفوقة على MCP لمعظم حالات الاستخدام. يجادلون بأن استخدام ‘الأداة’ يقتصر على نقاط نهاية واجهة برمجة التطبيقات للقدرات والوظائف.
واجهات برمجة التطبيقات ليست ذاتية الوصف افتراضيًا، مما يمثل فرصة ضائعة لأنصار REST وHATEOAS لعرض مناهجهم.
MCP كبديل لـ LangChain؟
وُصف MCP بأنه يحتوي على ‘رائحة LangChain’ - لا يحل مشكلة ملحة، كونه مجردة بشكل مفرط، ويواجه صعوبة في شرح مزاياه.
ربما يحتاج إلى أن يقول ‘نهاية الخط’ ونفي المتسللين الطموحين إلى شبكة الألعاب!
السؤال الرئيسي هو ما إذا كان نموذج Chatbot ‘العام’ سيستمر. قد لا تحتاج التطبيقات المتخصصة التي تحتوي على أدواتها الخاصة إلى MCP.
على العكس من ذلك، مع زيادة قدرة LLMs، قد تصبح الأدوات الخارجية أقل ضرورة. لماذا ترغب في MCP لتشغيل Photoshop عندما يمكن لـ LLM ببساطة تعديل الصورة مباشرة؟
قد لا يتحقق حلم المساعد الروبوتي الخيال العلمي، وقد تكون أدوات معالجة اللغة المتخصصة أكثر فائدة.
قاعدة المستخدمين والوعي الأمني
تتضمن قاعدة مستخدمي MCP أفرادًا أقل تقنية، مما يجعل المشكلات الأمنية ذات صلة خاصة. إن زيادة الوعي بأفضل الممارسات الأمنية أمر بالغ الأهمية.
يساعد بناء Xops على OpenRPC، الذي يتطلب تحديد مخطط النتيجة، في التخطيط لكيفية اتصال المخرجات بالمدخلات، وتحسين الموثوقية لسير العمل المعقدة.
من المرجح أن تتطور التكنولوجيا وتستقر بمرور الوقت.
التكرار والبنية التحتية السحابية
يشكك البعض في المكاسب من استخدام MCP عبر معيار OpenAPI، معتبراً أنه زائد عن الحاجة.
ما الذي سيستخدمه LLM للاتصال بنظام OpenAPI؟ كيف سترتبط بالقشرة؟ كيف ستنظم مضيفة LLM ذلك؟
يوفر MCP طريقة منظمة لـ LLMs لإجراء استدعاءات للأدوات.
خوادم MCP هي بالفعل خوادم HTTP.
أكبر ميزة لـ MCP هي لموفري LLM مثل OpenAI، وليس لمطوري التطبيقات.
LLMs هي عقول بدون أدوات، واستدعاء الأدوات يمكّنها. ومع ذلك، مع واجهات برمجة التطبيقات العادية، يفتقر مزودو LLM إلى الوصول إلى تلك الأدوات. يمنحهم MCP حق الوصول، مما يضعهم كبوابة للذكاء الاصطناعي.
CLI مقابل واجهة برمجة التطبيقات
لماذا لا تستخدم CLI مباشرة، نظرًا لأن LLMs يتم تدريبها على اللغة الطبيعية وCLIs هي حل شائع قابل للقراءة والكتابة للبشر؟
ظهر MCP بسرعة كبيرة ويحتاج إلى وقت للنضوج. يفتقر إلى التدقيق من قبل هيئة معايير تقليدية ويقوده الضجيج.
هناك نقص في التطبيقات الواقعية.
التطبيقات الرئيسية لـ MCP
يستخدم MCP في Claude Desktop وتطبيقات الدردشة AI المتخصصة وأدوات أتمتة التعليمات البرمجية وأطر أتمتة الوكيل/LLM.
إنها تقنية أخرى متسرعة من المحتمل أن يتم التخلص منها عند وصول الاختصار التالي القابل للتضخيم.
هناك نوعان من بروتوكولات استدعاء أدوات نموذج اللغة: تلك التي يشكو منها الناس وتلك التي لا يستخدمها أحد.
قامت Anthropic بتطوير هذا ‘المعيار’ في فراغ، مما أدى إلى مشاكل أمنية.
JSON-RPC 2.0
تم تصميم MCP على JSON-RPC 2.0، وهو بروتوكول خفيف الوزن يسمح باتصال العميل والخادم باستخدام JSON.
إنه يشبه المواصفات المركزية المصممة لنظام بيئي محدد، ويدعي العالمية دون كسبها.
MCP قوي بما يكفي للقيام بأشياء مفيدة، مما يثير مخاوف أمنية.
إنه ليس معيارًا ناضجًا ولم يتم تصميمه ليكون آمنًا.
في حين أن التوصيات موجودة، إلا أنها ليست مفروضة أو مطبقة.
Langchain واستدعاء الأدوات
Langchain هو أحد الأطر العديدة التي تنفذ نمط ‘استدعاء الأدوات’.
MCP هو مواصفات لكيفية دخول المعلومات الخارجية إلى نافذة سياق نموذج اللغة، بما في ذلك استدعاء الأدوات والإدخال المقولب والإلغاء وتتبع التقدم واستقرار خوادم الأدوات.
يساعد في توحيد التفاصيل بحيث يكون أي مجموعة مساعد/تكامل متوافقة.
في حين أن MCP لديه مشاكل مشروعة، يجب على النقاد تحسين حججهم.
المصادقة بالغة الأهمية ولا ينبغي حذفها من الإصدار الأولي.
هناك العديد من التعقيدات.