أُعلن أن MCP ميت بعد موجة من المنشورات تزعم أن أدوات سطر الأوامر (CLI) أرخص لوكلاء الذكاء الاصطناعي. يفصّل هذا المقال أرقام التوكنات الحقيقية، والمفاضلات الأمنية، والحالات التي يتفوق فيها كل نهج، لتختار الأنسب لمشروعك.
في مارس 2026، قال Denis Yarats، المدير التقني لشركة Perplexity، إن شركته تبتعد عن MCP داخليًا وتعتمد أكثر على واجهات API المباشرة وأدوات سطر الأوامر. انتشر منشور حول ذلك بسرعة، وخلال أيام صار الحكم مُتداولًا في كل مكان: MCP ميت. شارك المطورون لقطات شاشة لقوائم أدوات تستهلك نافذة السياق الخاصة بهم، وامتلأت الردود بأوامر صدفية من سطر واحد تؤدي المهمة نفسها في حيز أصغر بكثير.
ثم حدث شيء غريب. لم يمت البروتوكول. ظل يُطلق خوادم جديدة، واستمر في كسب دعم أكبر الأسماء في عالم الذكاء الاصطناعي، وهو اليوم تحت رعاية Linux Foundation. فأيّ الرأيين هو الصحيح؟
يفصل هذا المقال الضجيج عن الأرقام. سترى ما يفعله MCP فعلًا، وأين تكون شكاوى التوكنات في محلها، ولماذا تبدو CLI طبيعية جدًا لوكلاء البرمجة، وأين لا يستطيع سطر الأوامر أداء المهمة. وفي الطريق ستجد جدول قرار يمكنك استخدامه اليوم، وقسمًا قصيرًا عن تجربة النهجين معًا باستخدام موصل MCP وواجهة REST API الخاصين بـPicassoIA.
💡 الإجابة المختصرة: MCP ليس ميتًا، لكن الطريقة الكسولة في استخدامه كذلك. تحميل مئة تعريف أداة مسبقًا مشكلة في التصميم، وليست مشكلة في البروتوكول.
كانت الشرارة تصريحًا قصيرًا له امتداد طويل. قال المدير التقني لشركة Perplexity إن الشركة تنتقل بعيدًا عن MCP في أدواتها الداخلية، وتعود إلى واجهات API المباشرة وCLI. ثم توالت خلال أسابيع منشورات مدونات بعناوين مثل "MCP ميت" و"MCP مقابل CLI"، وتصلّب الجدال إلى معسكرين.
لم يكن أيٌّ من تلك المنشورات حكمًا رسميًا. كانت آراء، وقد دعم عدد منها اختبارات معيارية حقيقية أظهرت وفورات كبيرة في التوكنات عندما ينفّذ الوكيل أمرًا بدلًا من تحميل خادم بروتوكول. كانت الشكاوى في محلها. أما الادعاء بأن البروتوكول بأكمله انتهى فكان أكبر من الأدلة.
الأرقام التي تداولها الناس لافتة. قارنت إحدى المقارنات في أتمتة المتصفح نحو 52,000 توكن لقراءة صفحة منتج عبر لقطة MCP، مقابل نحو 1,200 توكن لبضعة استعلامات مستهدفة من سطر الأوامر. واختبار آخر، يسرد الأجهزة في أداة إدارة من Microsoft، أشار إلى نحو 35 مرة أقل من التوكنات مع CLI. اعتبر هذه الأرقام مؤشرات اتجاه، لأنها تعتمد على الخادم والمهمة والعميل. لكن الاتجاه يصعب الجدال فيه: الخادم المنتفخ مكلف.
إذا أزلنا الآراء الحادة، تبقى أربع شكاوى:
git وcurl وgrep وdocker في أمثلة لا تُحصى، لذلك تستدعيها بمهارة دون تعليمات إضافية.كل نقطة من هذه صحيحة في بعض الإعدادات. ولا واحدة منها عيب في فكرة البروتوكول المشترك.
السياق ليس مجانيًا. كل توكن يُنفق على أوصاف الأدوات هو توكن لم يُنفق على كودك أو مستنداتك أو المحادثة نفسها. كما أن الأوامر النصية الطويلة تكلّف مالًا في كل استدعاء، وتميل النماذج إلى فقدان التفاصيل المدفونة في منتصف سياق ضخم. لهذا تصيب حجة التوكنات أصحاب الوكلاء الذين يعملون طوال اليوم.
قدّمت Anthropic بروتوكول سياق النموذج (Model Context Protocol) في نوفمبر 2024 كوسيلة مشتركة لتطبيقات الذكاء الاصطناعي للوصول إلى الأدوات والبيانات الخارجية. فكّر فيه كمنفذ USB-C للوكلاء. بدون معيار، يحتاج كل تطبيق ذكاء اصطناعي إلى إضافة مخصّصة لكل خدمة، ويتضاعف عدد التكاملات بسرعة.
يتحدث العميل (تطبيق الذكاء الاصطناعي) مع الخادم (التكامل) عبر أنبوب محلي أو عبر HTTP. يعلن الخادم عن أدوات وموارد وأوامر، ويتيح للعميل أن يستدعيها النموذج. تلك هي الفكرة كلها: شكل قابس واحد، وأجهزة كثيرة.
تتوافق اللبنات الثلاث مع الاحتياجات اليومية. الأداة تنفّذ إجراءً، مثل إنشاء مشكلة أو توليد صورة. المورد يعرض بيانات للقراءة، مثل ملف أو صف في قاعدة بيانات. الأمر قالب قابل لإعادة الاستخدام يستطيع المستخدم تشغيله، مثل "راجع طلب السحب هذا". ومعظم الخوادم الحقيقية تعتمد تقريبًا كليًا على الأدوات، وهنا تتراكم تكاليف التوكنات.
في 9 ديسمبر 2025، تبرعت Anthropic بمشروع MCP إلى Linux Foundation كمشروع مؤسِّس لمؤسسة Agentic AI Foundation الجديدة، التي أسستها مع Block وOpenAI، وتدعمها Google وMicrosoft وAmazon Web Services وCloudflare وBloomberg. البروتوكولات المكتملة لا تحصل عادةً على موطن محايد وعلى هذا العدد من المنافسين حول طاولة واحدة.
لذلك فالسؤال المفيد ليس هل سينجو MCP. بل كيف ينبغي للناس أن يستدعوه.
هنا يملك المنتقدون حجة قوية. تشير التقارير إلى أن خادم GitHub الرسمي لبروتوكول MCP يستهلك نحو 50,000 توكن من أوصاف الأدوات قبل أن يفعل الوكيل شيئًا واحدًا. وقد أُفيد بأن ملف مهارة قصيرًا يعلّم سير العمل نفسه عبر سطر الأوامر يستهلك نحو 200 توكن. هذه فجوة بحجم مرتبتين، وهي تُقتطع من المساحة التي يحتاجها نموذجك للمهمة الفعلية.
التكلفة الثانية تختبئ في وسط سير العمل. إذا جلب وكيل نصًا طويلًا من نظام واحد ولصقه في نظام آخر، فإن كل كلمة تعبر النموذج مرتين. قد يصل نص اجتماع مدته ساعة إلى عشرة آلاف توكن أو أكثر، لذلك فإن تمريره مرتين يعني أن تدفع ثمنه مرتين، مع أن النموذج لم يكن بحاجة إلى قراءته أصلًا.
في منشور هندسي نشرته Anthropic بتاريخ 4 نوفمبر 2025 عن تنفيذ الأكواد مع MCP، وصفت سير عمل من Google Drive إلى Salesforce انخفض من نحو 150,000 توكن إلى نحو 2,000، أي وفر يقارب 98.7%. نقل الوكيل النص داخل الكود، فلم يرَ النموذج سوى تأكيد قصير.
اقرأ ذلك بتأنٍّ. الحل كان لا يزال MCP. الوكيل فقط استدعاه عبر الكود بدلًا من استدعاء أداة واحدة كل مرة.
| النهج | السياق المسبق | الأفضل في | نقطة الضعف |
|---|---|---|---|
| استدعاءات أدوات MCP المباشرة | مرتفع مع أدوات كثيرة | مجموعات أدوات صغيرة ومنتقاة | التضخم والتفاف البيانات |
| MCP مع تنفيذ الأكواد | منخفض | البيانات الكبيرة والخطوات الكثيرة | يحتاج إلى بيئة معزولة (sandbox) |
| CLI في الطرفية | شبه معدوم | أدوات المطورين | يحتاج إلى طرفية |
| CLI مع ملف مهارة | منخفض جدًا | سير العمل المتكرر | يحتاج إلى صيانة |
تحمل أدوات سطر الأوامر عقودًا من التوثيق وإجابات المنتديات وسجل الطرفية. ونموذج يُطلب منه سرد طلبات السحب المفتوحة لمؤلف واحد سيكتب السطر الصحيح من المحاولة الأولى:
gh pr list --state open --json number,title,author \
| jq '.[] | select(.author.login == "maria") | .title'
سطر واحد، ولا تصل إلى النموذج سوى العناوين النهائية. لا يدخل JSON الخام السياق أبدًا. الأنابيب والمرشِّحات وإعادة التوجيه تمنح الوكلاء قدرة على التركيب دون أي كلفة.
لا تعلن CLI كامل سطحها منذ البداية. يشغّل الوكيل --help للأمر الفرعي الواحد الذي يحتاجه، ويقرأ بضعة أسطر، ثم يتابع. هذا ما يسمى الكشف التدريجي، وهو بالضبط ما تفتقر إليه مخططات الأدوات الكبيرة.
هناك ميزة بشرية أيضًا. أي شيء يشغّله الوكيل يمكنك أنت تشغيله بنفسك في الطرفية لإعادة إنتاج خطأ. لا بروتوكول خفي، ولا مفتش خاص.
💡 قاعدة عامة: إذا كانت هناك CLI ناضجة للمهمة (git أو gh أو aws أو kubectl أو docker)، فدع الوكيل يستخدمها.
قدّم أحد مهندسي Google DeepMind أقوى نقطة مضادة: إذا كان وكيلك يعيش داخل تطبيق ملاحظات على الهاتف، فإن "استخدم CLI فقط" ليست خيارًا. وينطبق الأمر نفسه على تطبيقات الدردشة في المتصفح، والمساعدات المؤسسية المقيّدة، وأي بيئة معزولة بلا وصول إلى العمليات. معظم من يستخدمون الذكاء الاصطناعي يوميًا لا يجلسون أمام طرفية.
الصدفة أداة واسعة ومتساهلة. الوكيل الذي يملك طرفية يرث نظام الملفات ومتغيرات البيئة وكل جلسة مسجَّل دخولها على ذلك الجهاز. يمكنك تسييجه، لكن الوضع الافتراضي مفتوح على مصراعيه.
وبإنصاف، لا يمكن اعتبار أيٍّ من الطريقين آمنًا افتراضيًا. قد تحمل صفحة ويب أو بريد إلكتروني أو تذكرة تعليمات خفية موجهة إلى النموذج، ويوجد هذا الخطر سواء وصل النص عبر استدعاء أداة أو عبر مخرجات curl. البيئات المعزولة وبيانات الاعتماد للقراءة فقط والموافقة البشرية على الإجراءات الخطرة مهمة في العالمين. الفرق أن MCP يمنحك مكانًا طبيعيًا لفرض هذه الحدود، بينما تترك الصدفة الخام ذلك لك.
يستطيع خادم MCP أن يكشف الأدوات التي تختارها فقط. ويمكن للخادم البعيد أن يستخدم OAuth، فيتصرف كل شخص بهويته الخاصة، ويمكن لبوابة مركزية أن تسجل كل استدعاء. لفريق من خمسين شخصًا، هذا أفضل بكثير من خمسين حاسوبًا محمولًا يحمل كل منها توكنًا طويل الأمد في ملف إعدادات.
يستجيب البروتوكول للنقد نفسه الذي وجّهه المنتقدون، وبسرعة:
ملخص عملي للمزاج الحالي: استخدم CLI حين تملك طرفية، واستخدم خادم MCP منتقى حين تحتاج إلى بروتوكول، ولا تحوّل واجهة API كاملة تلقائيًا إلى عشرات الأدوات أبدًا.
| الموقف | الخيار الأفضل | السبب |
|---|---|---|
| وكيل برمجة محلي مع طرفية | CLI | أقل عبء، والنماذج تعرف الأدوات |
| الأداة لها CLI ممتازة بالفعل | CLI | الأنابيب تُبقي البيانات خارج السياق |
| تطبيق دردشة في المتصفح أو الهاتف | MCP | لا توجد صدفة متاحة |
| كثيرون يستخدمون أدوات مشتركة ويحتاجون تدقيقًا | MCP | OAuth وأدوات محددة النطاق وسجلات مركزية |
| منصة SaaS بلا CLI وبـOAuth فقط | MCP | تسجيل دخول قياسي ومخطط أدوات موحّد |
| سير عمل طويل ينقل ملفات كبيرة | تنفيذ الأكواد | البيانات تبقى خارج النموذج |
تنتهي معظم الفرق بالاعتماد على الاثنين. يتولى MCP الأنظمة القليلة التي تحتاج تسجيل دخول وحوكمة، وتتولى CLI كل ما يفعله المطورون أصلًا في الطرفية.
إليك كيف يبدو ذلك عمليًا. مطور منفرد يعمل مع وكيل في الطرفية سيلجأ طوال اليوم إلى git وgh وdocker، ويضيف خادم MCP أو اثنين لأشياء لا تملك CLI، مثل أداة تصميم أو متتبع تذاكر. وفريق دعم يستخدم مساعد دردشة في المتصفح لا يملك صدفة إطلاقًا، لذلك يصبح خادم MCP مستضافًا مع تسجيل دخول هو المسار الوحيد الممكن. أما فريق منصة يشغّل عشرات الوكلاء فيحتاج إلى سجلات مركزية وأدوات محددة النطاق، لذلك يضع بوابة أمام عدد قليل من الخوادم المنتقاة.
يعتمد أيٌّ من المسارين على نموذج يستدعي الأدوات بموثوقية. على PicassoIA يمكنك مقارنة عدة نماذج لغوية كبيرة في مكان واحد: Claude Sonnet 5 لأتمتة مهام البرمجة، وGPT 5.6 Sol لأعمال البرمجة المعقدة، وKimi K2.6 لبناء الوكلاء، وGemini 3.5 Flash للدردشة السريعة والبرمجة. أعطِ المهمة المتعلقة بالأدوات نفسها لاثنين منها، وراقب كيف يتعامل كل منهما مع استدعاء فاشل.
يُعد توليد الصور والفيديو بيئة اختبار جيدة لهذا النقاش. المخرجات كبيرة الحجم، والمهام تستغرق وقتًا، ويجب أن تُبلغ الأداة عن التقدم. يتيح PicassoIA النماذج الأربعة نفسها عبر موصل MCP وواجهة REST API: PicassoIA Image، وPicassoIA Image Editor Pro، وPicassoIA Video وSeedance 2.5 Lite للفيديو مع الصوت.
يمكن تشغيل خمس مهام كحد أقصى في الوقت نفسه لكل حساب، مشتركة بين كل الاتصالات.
لاحظ ما يفعله البروتوكول جيدًا هنا. لا يحتاج المساعد إلى معرفة عنوان URL أو ترويسة أو فترة استطلاع. أوصاف الأدوات تخبره كيف يبدأ المهمة وكيف يتابعها، ثم تعود النتيجة داخل الدردشة. هذه السهولة هي بالضبط ما يعد به MCP، وبالنسبة إلى مستخدم غير تقني في المتصفح، فهي الفرق بين "يعمل" و"غير ممكن".
النماذج نفسها متاحة عبر https://api.picassoia.com/v1، مع توكن حامل (bearer token) يبدأ بـpia_sk_. يتبع الشكل أسلوب Replicate: أنشئ تنبؤًا، واستطلعه، ثم احضر المخرجات.
curl -s https://api.picassoia.com/v1/models/picassoia/picassoia-image/predictions \
-H "Authorization: Bearer $PICASSOIA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"input": {"prompt": "A lighthouse at dawn, natural light, 16:9"}}'
تحمل الاستجابة معرّف التنبؤ. استطلع GET /v1/predictions/{id} حتى تصبح الحالة succeeded، ثم حمّل الملف. راجع صفحات API على picassoia.com للاطلاع على حقول الإدخال الدقيقة لكل نموذج.
💡 جرّب بنفسك: شغّل الأمر النصي نفسه مرة عبر موصل MCP ومرة عبر curl. قِس الوقت لكليهما، وعدّ الخطوات، وقرر أيهما يناسب سير عملك.
MCP ليس ميتًا، و CLI ليست موضة عابرة. هما أداتان بمهمتين مختلفتين، والخطوة الذكية هي أن تطابق كل واحدة مع المكان الذي يعيش فيه وكيلك فعلًا. افتح picassoia.com، واختر نموذجًا، واكتب أول أمر نصي لك، وشاهد المسارين يعملان بصورك أنت.
اختر لغتك
