لماذا كانت MCP فكرة سيئة دائماً

ذهبت مؤخراً إلى فعالية طوال اليوم تركز على أحدث وأكبر التطورات في عالم MCP. بينما كان جميع المتحدثين رائعين وبدوا شغوفين بالعمل الذي يقومون به، أنا بصراحة سئمت من MCP. إنه بروتوكول فظيع تم بناؤه لوقت لم تكن فيه LLMs ذكية جداً، وقد تجاوزناه.

تاريخ موجز

تم إصدار MCP في نوفمبر 2024 من قبل فريق Anthropic كبروتوكول مصمم لمساعدة الوكلاء على الاتصال بالخدمات الخارجية ومصادر البيانات. كانت نماذج ذلك الوقت لا تزال بدائية نسبياً، على الأقل مقارنة بما لدينا الآن. لم يكن لدينا حتى Claude Code في ذلك الوقت، وكانت سير العمل الوكيلة للأغراض العامة أقل موثوقية بكثير. بدأ المستخدمون في رؤية فائدة إعطاء نماذج الذكاء الاصطناعي الخاصة بهم الوصول إلى الخدمات الخارجية. مكن هذا مستوى من الإنتاجية لم نشهده من قبل. شهدنا انفجاراً في تبني MCP، مصادفاً نمواً مشابهاً، إن لم يكن أكثر انفجاراً، في تبني LLM عبر الاقتصاد. مع مرور الوقت، استمرت MCP في التطور تحت إدارة Anthropic قبل أن يتم التبرع بها في النهاية لمؤسسة Agentic AI Foundation، تحت مؤسسة Linux Foundation، في عام 2025.

المجمع الصناعي لـ MCP

مع النمو الهائل في التبني، بدأ المستخدمون في إضافة العديد من خوادم MCP إلى إعداداتهم، وبدأوا في مواجهة مشكلة تضخم السياق. سيأتي كل خادم مع أدوات متعددة، لكل منها مخططها الخاص، مما بدأ في إفراط تحميل سياق كل هذه النماذج. وجد مطورو Harness العديد من الحيل للتغلب على ذلك، بما في ذلك أنماط البحث/التنفيذ العامة التي تقدمها الآن منصات مثل Composio، و Mint MCP، و Pipedream. جميعها تحل بشكل فعال مشكلة وجود مكان واحد لوضع بيانات اعتمادك للخدمات الخارجية المختلفة وإعطاء وكيلك مجموعة mínima من الأدوات (للحد من تضخم السياق) التي يمكنه استخدامها للوصول إليها. أريد أن أوضح أن هذا شيء جيد، على المدى القصير.

مع كل الأشياء التي بنيناها حول MCP، ما لم نأخذه في الاعتبار، أو ربما تجاهلناه، هو تحسن النماذج. لدينا الآن أنظمة كاملة مخصصة لمراقبة خوادم MCP، والتأكد من أن الاستجابات جيدة، والتأكد من أن الوكلاء قادرون على الوصول بسهولة إلى الأدوات، ومعرفة المخططات، وتحديد ما نحتاج إلى إعطائه للوكلاء حتى يتمكنوا من إجراء المكالمة الصحيحة في الوقت المناسب.

مفاجأة، مفاجأة، المختبرات الكبيرة كانت على حق

تحسنت النماذج. أصبحت الآن قادرة على تنفيذ الكود على الكمبيوتر، والتفكير في قواعد الكود الكبيرة، والتصرف بشكل أكثر استقلالية من أي وقت مضى. كان جزء كبير من هذا العمل هو كتابة/تشغيل السكريبتات لأغراض البرمجة. تأثير جانبي (ولكن هل هو كذلك؟) هو أنهم أصبحوا جيدين في استدعاء APIs مباشرة. يمكنهم كتابة السكريبتات، وتركيب خدمات مختلفة متعددة، واستدعاء APIs لم يروها من قبل، وكل ذلك في سير عمل مفيدة مع الحد الأدنى من التدخل من جانب المستخدم.

أصبحت LLMs جيدة جداً في هذا، حتى أن Cloudflare أطلقت Code Mode، وهي طريقة أفضل لاستخدام MCP من خلال جعل LLMs تؤلف المكالمات المختلفة في سكريبتات يمكن تنفيذها في بيئة معزولة. ولكن حتى أفضل من ذلك، اكتشفت LLMs كيفية استخدام أمر --help لاكتشاف CLIs، لذلك لم تعد بحاجة إلى خوادم MCP للوصول إلى العديد من الخدمات المتاحة من خلال APIs الموثقة أو CLIs. معظم خوادم MCP للخدمات البعيدة في النهاية تغلف APIs الموجودة بالفعل.

ماذا الآن؟

نحذف معظم خوادم MCP الخاصة بنا. هذا كل شيء. يمكن للوكلاء الذين لديهم وصول إلى المحطة الطرفية استبدال معظم خوادم MCP وغالباً ما يكونون أكثر قدرة.

لا تزال هناك بعض المشكلات، مثل إرجاع CLIs لاستجابات قابلة للقراءة آلياً (JSON/XML، إلخ)، والتي تميل إلى أن تكون مطولة جداً وثقيلة على استخدام الرموز، لكن لدينا طرق لإصلاح هذا. يوجد معظم البديل بالفعل: APIs HTTP الموثقة، وتفاوض المحتوى القياسي، وآليات المصادقة الناضجة. يجب أن نبدأ في توحيد كيفية استخدام الوكلاء لـ HTTP APIs مباشرة. على سبيل المثال، يمكن لعملاء الوكلاء إرفاق رؤوس لتحديد أنفسهم كوكلاء، ويمكن للخوادم إرسال بيانات الاستجابة إليهم تلقائياً كنص أو Markdown بدلاً من HTML أو....