MCP بروتوكول رائع. توقف عن استخدامه كخيارك الافتراضي.
تسارع اعتماد MCP بشكل كبير. ثم وصل المهندسون إلى بيئة الإنتاج وبدأوا يرسلون تقاريرهم. هذا ما تُظهره المعايير المرجعية وبيانات الممارسين والإخفاقات الحقيقية فعلاً — وما يعنيه ذلك لكيفية بنائك لتكاملات الوكلاء.
النتائج الرئيسية
- ثلاثة خوادم MCP يمكنها استهلاك 72% من نافذة سياق الوكيل قبل أن يعالج رسالة مستخدم واحدة.
- في معيار مرجعي من 985 مهمة، لم يكن CLI الخام ولا MCP هو الخيار الأمثل — تصميم CLI مُحسَّن للوكلاء تفوّق على كليهما في كل مقياس: التكلفة، السرعة، الموثوقية، وعدد الدورات.
- يكلّف MCP من 4 إلى 32 ضعفاً من الرموز مقارنةً بـ CLI لنفس العمليات، وفقاً لمعيار Scalekit المُحكَم على 75 تشغيلاً.
- المتغير الحاسم ليس البروتوكول. بل ما إذا كانت الواجهة مصممة لوكيل أم لإنسان.
- حالة الاستخدام الحقيقية لـ MCP هي التوزيع — نشر القدرات لمنظومة الوكلاء الأوسع. بالنسبة للأدوات الداخلية، هو الخيار الافتراضي الخاطئ.
ماذا حدث فعلاً
أُطلق MCP في أواخر 2024 بعرض مقنع: بروتوكول عالمي يتيح لأي وكيل ذكاء اصطناعي اكتشاف واستخدام أي أداة عبر واجهة موحدة. ابنِ مرة واحدة، واتصل في أي مكان. أضاف كل من Claude وCursor وVS Code وWindsurf الدعم له. تحرك الاعتماد أسرع مما تفعل معظم المعايير المفتوحة — 97 مليون تحميل شهري لحزم SDK عبر Python وTypeScript في السنة الأولى، مع أكثر من 10,000 خادم نشط.
ثم انتقل المهندسون من العروض التجريبية إلى الإنتاج، وبدأت التقارير تتوالى. في مارس 2026، أعلن Denis Yarats، المدير التقني لـ Perplexity، في مؤتمر Ask 2026 أن Perplexity تبتعد عن MCP داخلياً — شركة كانت قد أطلقت خادم MCP الخاص بها قبل أربعة أشهر فقط. نشر Garry Tan، الرئيس التنفيذي لـ Y Combinator، أنه شعر بالإحباط فبنى غلاف CLI لـ Playwright في 30 دقيقة وقال إنه يعمل أفضل بـ 100 ضعف. وأفاد المدير التقني لـ Merge أن إعداد MCP لفريقه يستهلك 40–50% من نافذة السياق قبل أن يفعل الوكيل أي شيء.
لم يكن هذا ردة فعل عنيفة. بل كان مهندسين يواجهون مشكلة هيكلية حقيقية على نطاق واسع ويبلّغون عنها بصدق. البروتوكول لم يكن معطلاً. كان يُستخدم في الأماكن الخاطئة.
ضريبة السياق
كل خادم MCP متصل بوكيل يحمّل مخطط أدواته الكامل في نافذة السياق مسبقاً — الأسماء، الأوصاف، أنواع المعاملات، التعدادات، تعليمات النظام. هذا هو البروتوكول يعمل كما صُمّم. المشكلة هي ما يكلّفه ذلك.
| المقياس | القيمة | |--------|-------| | الرموز المستهلكة قبل رسالة مستخدم واحدة (GitHub + Slack + Sentry، ~40 أداة) | 55,000 | | نافذة السياق المحروقة على تعريفات الأدوات في نشر حقيقي بثلاثة خوادم | 72% | | أقصى مضاعف تكلفة رموز MCP مقابل CLI لنفس العمليات | 32x |
أكثر نقطة بيانات دلالةً: مهمة بسيطة كالتحقق من لغة البرمجة المستخدمة في مستودع استهلكت 1,365 رمزاً عبر CLI و44,026 عبر MCP. الفرق بالكامل هو المخطط — 43 تعريف أداة تُحقن في كل محادثة، يستخدم منها الوكيل واحداً أو اثنين.
ضع عدة خوادم فوق بعضها ويتراكم الأمر بسرعة. عند 143,000 رمز مستهلك بتعريفات الأدوات على نموذج بسعة 200K رمز، يتبقى للوكيل 57,000 رمز للمحادثة الفعلية والمستندات المسترجعة والاستدلال والاستجابة. هذه ليست مشكلة إعداد. هذه النتيجة المتوقعة لتصميم يحمّل كل شيء مسبقاً.
"MCP هو كيف نتمنى أن يعمل الذكاء الاصطناعي. CLI هو كيف يعمل فعلاً اليوم." — Vitor Zucher, 3x Founder, مارس 2026
لكن CLI الخام ليس الحل أيضاً
الاستجابة الفورية من المجتمع — إزالة MCP واستبداله بأوامر shell — تحل مشكلة الرموز وتخلق مشاكل مختلفة. CLI الخام غير منظم. يُعيد نصاً على الوكيل تحليله وتفسيره. لا يوجد مخرجات مُنمَّطة، ولا معالجة أخطاء موثوقة، ولا حالات فارغة محددة. الوكلاء يرتجلون عبر أعلام --help ويخمّنون سلوك الأوامر الفرعية.
والأهم من ذلك، CLI الخام يفشل بصمت بطرق لا يفعلها MCP. بيانات المعايير المرجعية تجعل هذا مرئياً.
| الواجهة | معدل النجاح | متوسط التكلفة / المهمة | متوسط المدة | متوسط الدورات | |-----------|-------------|-----------------|--------------|-----------| | AXI (CLI مُحسَّن للوكلاء) | 100% | $0.050 | 15.7s | 3 | | CLI خام | 86% | $0.054 | 17.4s | 4 | | MCP (خام) | 87% | $0.148 | 34.2s | 6 | | MCP + Tool Search | 82% | $0.147 | 41.1s | 8 | | MCP + Code Mode | 84% | $0.101 | 43.4s | 7 |
المصدر: Kun Chen، كبير المهندسين الرئيسيين، Atlassian Rovo. 985 تشغيل مهمة، Claude Sonnet 4.6 كوكيل وحَكَم. مهام مستودعات GitHub تشمل عمليات بحث بسيطة، وتحقيقات متعددة الخطوات، وعدّ تجميعي، ومعالجة أخطاء.
فشل CLI الخام تحديداً في المهام التجميعية. عندما يُعيد CLI قائمة مُقسّمة لصفحات، لا يملك الوكيل طريقة لمعرفة ما إذا كان حجم الصفحة يساوي العدد الإجمالي. يفترض أنه كذلك. والنتيجة هي إجابة خاطئة صامتة وغير قابلة للتصحيح — لا خطأ يُطلَق، ولا إعادة محاولة تُفعَّل. معدل النجاح 86% ليس قريباً بما يكفي للإنتاج.
إضافة Tool Search إلى MCP لتقليل تحميل المخطط المسبق جعلت الأمور أسوأ، حيث انخفض النجاح إلى 82% مع إضافة دورات دون استرداد توفير الرموز. خطوات الاكتشاف الإضافية أحرقت سياقاً أكثر مما وفّره تقليل المخطط.
المتغير الذي لا يتحدث عنه أحد
النتيجة التي ظهرت من معيار Atlassian هي التي تُعيد تأطير النقاش بأكمله. النهج الفائز — AXI، واجهة تجربة الوكيل (Agent eXperience Interface) — ليس بروتوكولاً جديداً. إنه CLI مصمم حول كيفية استهلاك الوكلاء للمعلومات فعلاً، بدلاً من كيفية استهلاك البشر لها.
مبادئ التصميم واضحة: حقول محسوبة مسبقاً حتى لا يضطر الوكيل لاستنتاج الإجماليات، وحالات فارغة صريحة حتى لا يكون "0 نتائج" غامضاً أبداً، ومخرجات أخطاء منظمة يمكن للوكلاء تحليلها دون تخمين، وانضباط في المخرجات يفصل البيانات عن معلومات التصحيح. وكانت النتيجة نجاحاً بنسبة 100% بتكلفة $0.050 لكل مهمة — أرخص بثلثين من أفضل متغير MCP، وأسرع من كل شيء.
الاستنتاج من تحليل Kun Chen صريح: "النقاش بين CLI وMCP يُغفل السؤال الأعمق — ما مبادئ التصميم التي تجعل أي واجهة فعّالة للوكلاء؟ إنها ليست CLI. وليست MCP."
معظم الفرق تختار بين بروتوكولين دون أن تسأل أبداً ما إذا كان أي منهما مصمماً للوكيل الذي يستهلكه. والإجابة دائماً تقريباً لا.
متى يكون MCP هو الخيار الصحيح فعلاً
لا شيء من هذا يجعل MCP الخيار الخاطئ في كل مكان. هناك سيناريو واحد حيث هندسته ليست مقبولة فحسب — بل لا يمكن الاستغناء عنها.
إذا كنت شركة SaaS وتريد لأي وكيل ذكاء اصطناعي، بناه أي شخص، أن يكتشف ويستخدم منتجك، فإن MCP هو كيف تنشر تلك القدرة للمنظومة. فعلت ذلك كل من Stripe وAsana وIntercom وCloudflare وWebflow. إنها قناة توزيع. الوكلاء المتصلون بهذه المنصات لا يحتاجون لمعرفة التنفيذ الأساسي — يكتشفون الأدوات عبر البروتوكول، ويُصادقون، ويستخدمونها. لا يوجد مكافئ CLI لحالة الاستخدام هذه.
يستحق MCP أيضاً تكلفته الإضافية لمجموعات الأدوات الثابتة والمحددة جيداً المستخدمة بكثرة — حالات يتم فيها إطفاء تكلفة المخطط عبر تفاعلات كثيرة وحيث تقلل استدعاءات الأدوات المُنمَّطة والمنظمة معدلات الفشل في سير العمل المعقد متعدد الخطوات. لأي شيء يتطلب OAuth أو أذونات محددة النطاق أو سجلات تدقيق عبر حدود المؤسسات، فإن نموذج المصادقة في MCP أفضل حقاً من مفاتيح API طويلة العمر في ملفات الإعداد.
مثال GitHub مفيد في كلا الاتجاهين: خادم MCP الرسمي لـ GitHub كان أداؤه أقل من CLI الخام في كل معيار مرجعي. لكن خادم MCP مصمم بشكل جيد مع أدوات أقل وأفضل تكويناً — بدلاً من 43 تعريف أداة مُلقاة في كل محادثة — سيُقلّص تلك الفجوة بشكل كبير. المشكلة ليست في البروتوكول. إنها في التنفيذ.
القرار
استخدم CLI (المصمم للوكلاء) عندما:
- سير عمل المطورين الداخلي — git، عمليات النشر، البنية التحتية، CI/CD
- أدوات بواجهات CLI ناضجة يعرفها النموذج بالفعل من التدريب
- النماذج الأولية حيث السرعة أهم من الحوكمة
- أعباء العمل الإنتاجية الحساسة للتكلفة
- بيئات المستخدم الواحد أو المستأجر الواحد
استخدم MCP عندما:
- نشر منتج SaaS الخاص بك لمنظومة الوكلاء
- مجموعات أدوات ثابتة ومحددة جيداً تُستخدم بتردد عالٍ
- منتجات متعددة المستأجرين تتطلب OAuth محدد النطاق وسجلات تدقيق
- أدوات بدون CLI وبدون API عام
- أي تكامل يحتاج أن يكون محايداً تجاه الوكيل
الملخص: إذا كنت تُؤتمت سير عمل داخل بيئتك الخاصة، صمّم CLI للوكلاء. إذا كنت تنشر قدرات للعالم الخارجي لوكلاء لا تتحكم بها، ابنِ خادم MCP.
الفجوة الحقيقية في السوق
تم تأطير نقاش CLI مقابل MCP كحرب بروتوكولات. وهو ليس كذلك. إنها مشكلة تصميم. الغالبية العظمى من تكاملات الوكلاء في الإنتاج اليوم — الأدوات الداخلية، الأنظمة المملوكة، سلاسل أدوات المطورين — بُنيت للبشر أولاً ولم تُراجَع أبداً للوكلاء. هذه هي الفجوة الفعلية.
بناء تكامل وكيل يعمل في الإنتاج يعني طرح سؤال مختلف: ليس أي بروتوكول، بل ما الذي يحتاج الوكيل لمعرفته، بأي صيغة، بأي تكلفة، لإكمال هذه المهمة بموثوقية؟ أجب عن ذلك ويصبح الاختيار بين MCP وCLI واضحاً.
معظم الفرق لم تطرح هذا السؤال بعد.