MCP مقابل CLI للوكلاء الذكيين: استهلاك التوكنات وأيهما أفضل

لم يكتب وكيلك بعد كلمةً واحدة من إجابته، وقد استهلك بالفعل آلاف التوكنات. هذا هو الجوهر الحقيقي وراء MCP مقابل CLI للوكلاء الذكيين: ليس أيُّ البروتوكولين أنظم، بل أيُّهما يترك مساحة أكبر في نافذة السياق للعمل الفعلي. قاس أحد الاختبارات 1,365 توكنًا لبحث على GitHub نُفّذ عبر سطر الأوامر، و44,026 توكنًا للبحث نفسه عبر MCP. ووجد اختبار آخر مبنيّ على Playwright فارقًا يكاد يكون معدومًا. النتيجتان حقيقيتان، والفرق بينهما يقول أكثر مما يقوله أي رقم منفردًا. فيما يلي سترى أين تذهب التوكنات، وما تُظهره القياسات، ومتى يظل MCP يستحق تكلفته، وكيف تختار دون تخمين.

ما المقصود بـ MCP وCLI بالنسبة للوكلاء

يمنح كلا الأسلوبين النموذجَ القدرة على التصرف عبر الأدوات. ويختلفان في الطريقة التي يكتشف بها النموذج ما تستطيع هذه الأدوات فعله، ومتى يدفع ثمن تلك المعرفة.

كيف يقدّم MCP الأدوات

بروتوكول سياق النموذج (Model Context Protocol) معيار مبنيّ على JSON-RPC. عند بدء الجلسة، يسأل العميل كل خادم متصل عن الأدوات التي يقدمها. تصل كل أداة كـاسم ووصف ومخطط مدخلات (input schema)، وكل ذلك يبقى في سياق النموذج ليقرر ما يستدعيه. ثم تنتقل كل استدعاءة وكل نتيجة على شكل JSON منظّم.

الميزة حقيقية: مدخلات مُحدَّدة الأنواع، ومصادقة تُدار على جانب الخادم، وأدوات يستطيع أي عميل متوافق اكتشافها بنفسه. أما العيب فهو أن الكتالوج كله يُدفع ثمنه مقدمًا، سواء احتاجت المهمة إلى أداة واحدة أو إلى لا شيء.

كيف يقدّم CLI الأدوات

في أسلوب CLI، يكتب الوكيل أمرًا في الصدفة (shell)، وتُنفّذه بيئة التشغيل، ويعود الإخراج القياسي كنص عادي. لا يوجد كتالوج ولا مصافحة أولية. النموذج يعرف أصلًا git وgrep وcurl وjq من بيانات تدريبه، وإذا نسي خيارًا شغّل --help وقرأ صفحة قصيرة.

لا تظهر التكلفة إلا للأوامر المستخدمة فعلًا. هذا الفرق التصميمي وحده يفسّر معظم ما يلي.

💡 تعريف سريع: التوكن قطعة نص يقرأها النموذج أو يكتبها. تعريفات الأدوات والأوامر والنتائج تشغل كلها نافذة السياق، وتُحسب جميعها كمدخلات في الدورة التالية.

أين تذهب التوكنات فعلًا

تأتي تكلفة التوكنات في حلقة الوكيل من ثلاثة مصادر: ما يُخبَر به النموذج عن أدواته، وما يرسله، وما يعود إليه. ويختلف MCP وCLI أساسًا في الأول والثالث.

تكلفة المخطط قبل أي عمل

يحقن خادم MCP النموذجي تعريف كل أداة في المحادثة قبل طرح أول سؤال. يعرض خادم GitHub الرسمي 43 أداة بحسب اختبار Scalekit، لذا حتى الاستعلام البسيط يحمل 43 مخططًا. وقاس Checkly تعريفات خادم Playwright وحدها فوجدها 5.9 ألف توكن. وتصف Anthropic المشكلة بوضوح في مقالها الهندسي عن تنفيذ الشيفرة مع MCP: تعريفات الأدوات تُثقل نافذة السياق.

نتائج تعود عبر السياق

التكلفة الثانية أصعب في الملاحظة. مع استدعاءات MCP الافتراضية، تمرّ كل نتيجة وسيطة عبر النموذج. مثال Anthropic هو نص اجتماع يُجلب من خدمة ثم يُكتب في خدمة أخرى: ينتقل النص عبر السياق مرتين، وقد يضيف أكثر من 50,000 توكن لتسجيل طويل. أما خط أنابيب الصدفة فيستطيع التصفية أو العد أو الاقتطاع لتلك البيانات قبل أن يراها النموذج أصلًا.

ما تُظهره الاختبارات

يقدم اختباران عامّان أوضح صورة، وهما يشيران إلى اتجاهين مختلفين.

اختبار Scalekit على GitHub

شغّلت Scalekit خمس مهام قراءة فقط على GitHub باستخدام Claude Sonnet 4، بواقع 25 تشغيلًا لكل أسلوب، مقابل خادم GitHub الرسمي عبر MCP. قارنوا بين CLI عادي، وCLI مع ملفات تعليمات قصيرة تُسمى skills، وMCP، أي 75 تشغيلًا في المجموع. التوكنات لكل مهمة:

بالمتوسط عبر المهام الخمس، يبلغ ذلك نحو 5,200 توكن مع CLI مقابل نحو 46,000 توكن مع MCP، أي نحو 9 أضعاف. وقدّرت Scalekit تكلفة 10,000 عملية شهريًا بنحو 3.20 دولارات لـ CLI مقابل 55.20 دولارًا لـ MCP المباشر، بفارق 17 ضعفًا. وسارت الموثوقية في الاتجاه نفسه: أنهى CLI 25 تشغيلًا من أصل 25، وأنهى MCP 18 من أصل 25 (72%)، وكانت الإخفاقات السبعة كلها مهلات على مستوى TCP.

انظر إلى عمود skills أيضًا. في المهمة الأخيرة استخدمت نسخة skills توكنات أقل من CLI العادي (6,860 مقابل 8,750)، ربما لأن ملف التعليمات القصير وفّر على الوكيل التجربة والخطأ. أما في الاستعلامات البسيطة فقد كلّف أكثر، لأن التعليمات تُحمَّل في كل مرة.

⚠️ اقرأ حدود الاختبار: نموذج واحد، وخدمة واحدة، ومهام قراءة فقط. المهلات مشكلات اتصال وليست أخطاء في الاستدلال، لذا فإن فجوة الموثوقية تخبرنا عن إعداد ذلك الخادم أكثر مما تخبرنا عن البروتوكول نفسه.

Playwright: الفجوة التي انغلقت

أجرت Checkly اختبارًا مختلفًا: فتح متجر تجريبي، والبحث عن منتج، والنقر عبره، وإضافة عناصر إلى السلة، والتحقق من محتوياتها. استهلكت جلسة MCP من 48 ألفًا إلى 50 ألف توكن من السياق. أما جلسة CLI، مع تثبيت skills، فاستهلكت من 45 ألفًا إلى 48 ألفًا. وبعد ثلاثة تشغيلات صار الفرق ضئيلًا، والتفسير بسيط: يشترك Playwright CLI وخادم MCP في الخلفية نفسها، ويكتبان ملفات اللقطات نفسها على القرص.

وتعترف Checkly أيضًا بأن النقد الموجَّه إلى MCP في 2025 كان في محله. وكان سببان وراءه: الخوادم كانت تحمّل كل التعريفات مقدمًا، وكل إجراء كان يعيد لقطة كاملة للصفحة ضمن الرد. وقد خُففت الحالتان منذ ذلك الحين، لأن أطر عمل الوكلاء الحديثة تؤجل تحميل أدوات MCP حتى تُحتاج، ولأن الخوادم تستطيع حفظ اللقطات على القرص. وتحذيرها يستحق التكرار: نصائح الذكاء الاصطناعي لها تاريخ انتهاء يُقاس بالأشهر.

الدرس ليس أن أحد الطرفين كان مخطئًا. رقم 32x يصف تنفيذًا واحدًا حُمّلت فيه كل المخططات. والتعادل القريب يصف تنفيذًا آخر يتجنب هذه التكلفة الإضافية. تكلفة التوكنات خاصية في طريقة بناء الخادم، لا في تسمية البروتوكول.

لماذا يفوز CLI غالبًا في التكلفة

حين يعمل الخياران بالإعدادات الافتراضية، يفوز CLI في أغلب الأحيان. ويقوم ذلك على سببين رئيسيين.

النماذج تتحدث الصدفة أصلًا

عقود من سكربتات الصدفة وملفات README وإجابات المنتديات موجودة في بيانات تدريب كل نموذج لغوي كبير. لا يحتاج الوكيل إلى مخطط ليستخدم git log أو grep -r، والأمر المكوّن من سطر واحد يحل محل استدعاء JSON يحمل اسمًا وكائن وسائط وغلافًا يحيط به. وحين يكون غير متأكد، يكلّفه --help صفحة قصيرة واحدة، لا كتالوجًا كاملًا في بداية كل جلسة.

الأنابيب تقلّم المخرجات أولًا

الميزة الأقل تقديرًا في CLI هي التركيب. إليك طريقة لعرض عناوين طلبات السحب المدمجة مؤخرًا:

gh pr list --state merged --limit 10 --json title --jq '.[].title'

نسخ الأمر النصي

يرى النموذج عشرة أسطر من العناوين. أما استدعاء MCP الافتراضي لأداة طلبات السحب فيعيد غالبًا الحمولة الكاملة لكل عنصر: المؤلفون والوسوم والروابط والطوابع الزمنية وحالة المراجعة. معظمها يُتجاهل، لكنه يُقرأ كله، ويُحاسَب كله.

كما أن جلسة CLI أسهل في تصحيح الأخطاء. يمكنك لصق الأمر نفسه في طرفيتك وترى بالضبط ما رآه الوكيل.

أين يستحق MCP تكلفته الإضافية

عدد التوكنات الخام محور واحد. وبعض المهام تحتاج ما لا يمنحه إلا بروتوكول.

المصادقة والصلاحيات

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

الجلسات الطويلة ومهام الوسائط

الأدوات ذات الحالة (stateful) تفضّل MCP. فجلسة متصفح يجب أن تستمر عبر عشرات الدورات، أو اتصال بقاعدة بيانات مع معاملة مفتوحة، يصعب إعادة بنائهما من أوامر صدفة منفصلة.

توليد الوسائط مثال جيد. تعمل نماذج الصور والفيديو كمهام غير متزامنة: تُرسل طلبًا، وتحصل على معرّف مهمة، وتستعلم بشكل متكرر حتى تكون النتيجة جاهزة. يغلّف موصل PicassoIA هذا المسار في تسع أدوات وقت كتابة هذا المقال: توليد الصور، وتحرير الصور، ومولّدا فيديو، والاستعلام عن الحالة، والإلغاء، وقائمة المهام السابقة، وقائمة النماذج، وفحص الحساب. وتعيد أدوات التوليد معرّف المهمة مع مدة انتظار مقترحة قبل الاستعلام التالي، فيعرف الوكيل متى يتحقق من جديد بدلًا من التكرار بلا هدى. ومن النماذج التي يقوم عليها PicassoIA Image وPicassoIA Image Editor Pro وPicassoIA Video وSeedance 2.5 Lite، مع تشغيل ما يصل إلى خمسة تنبؤات في الوقت نفسه لكل حساب.

يمكنك الوصول إلى النماذج نفسها عبر REST API على https://api.picassoia.com/v1 باستخدام curl عادية. وهذا يعمل جيدًا، لكن على الوكيل أن يتذكر نقطة النهاية، ويرفق بيانات الاعتماد، ويكتب حلقة الاستعلام الخاصة به. أما أدوات MCP فتغلّف هذه الخطوات. ولاحظ أيضًا أهمية حجم الكتالوج: تسع أدوات صغيرة أخف بكثير من 43 أداة في GitHub، ولهذا يُثقل الخادم الرشيق السياق أقل من الخادم المتضخم.

كيف تخفض تكلفة توكنات MCP

إذا كان MCP هو الخيار المناسب، فلست مضطرًا إلى قبول الفاتورة الافتراضية.

حمّل الأدوات عند الطلب

تسمي Anthropic هذا الكشف المتدرج (progressive disclosure): دع النموذج يقرأ تعريفات الأدوات حين يحتاجها، لا كلها دفعة واحدة. هناك شكلان يعملان. الأول هيكل ملفات تكون فيه كل أداة ملفًا صغيرًا يفتحه الوكيل عند الحاجة. والثاني دالة بحث تعثر على التعريفات المناسبة فقط وتحمّلها. وأيًّا كان الاسم الذي تستخدمه أطرك، تحقق من تفعيل التحميل المؤجل، وصِل فقط الخوادم التي يحتاجها المشروع الحالي.

اكتب الشيفرة فوق الأدوات

الخطوة الأكبر عند Anthropic هي تقديم أدوات MCP ككود يستطيع الوكيل استدعاءه من بيئة معزولة (sandbox). يكتب الوكيل سكربتًا قصيرًا، ويتواصل السكربت مع الخوادم، ولا يعود إلى النموذج إلا ملخص. وفي مثالهم عن نقل البيانات من Google Drive إلى Salesforce، انخفض استهلاك التوكنات من 150,000 إلى 2,000، أي توفير بنسبة 98.7%.

انظر إلى ما يعنيه ذلك فعلًا: سلوك على طريقة CLI، حيث تُصفّى البيانات قبل أن يراها النموذج، مضافًا إليه مصادقة MCP وواجهاته المُحدَّدة الأنواع. ينتهي الفريقان إلى الاقتراض من بعضهما.

مكاسب سريعة يمكنك تطبيقها اليوم:

• افصل الخوادم الخاملة. كل أداة متصلة تكلّف توكنات، سواء استُخدمت أم لا.
• فضّل خوادم صغيرة ومركزة على خادم واحد فيه عشرات الأدوات.
• حدّد النتائج. استخدم معاملات الحد واختيار الحقول أينما وفّرتها الأداة.
• اكتب المخرجات الضخمة على القرص وأعد المسار، كما يفعل Playwright الآن مع اللقطات.
• قِس. راجع أرقام الاستخدام لدى مزوّدك قبل كل تغيير وبعده.

أيهما أفضل لك

من حيث تكلفة التوكنات الخام بالإعدادات الافتراضية، يفوز CLI في معظم الأحيان، بفارق يتراوح من 4 أضعاف إلى 32 ضعفًا في أفضل اختبار موثّق. أما في التحكم بالوصول والحالة طويلة الأمد والخدمات المستضافة، فيفوز MCP. وحين تُحمَّل أدوات MCP عند الطلب وتبقى النتائج الكبيرة خارج السياق، يمكن أن ينكمش الفارق إلى ما يكاد يكون لا شيء، كما أظهر اختبار Playwright.

اختر CLI حين تكون الأداة موجودة أصلًا كأمر، ويعمل الوكيل على جهاز تتحكم فيه، وكل توكن له ثمن.

اختر MCP حين تحتاج إلى صلاحيات لكل مستخدم، أو حالة مستمرة، أو خدمة مستضافة لا توجد لها أداة سطر أوامر جيدة.

اجمع بينهما عند الشك. معظم الإعدادات الحقيقية تفعل ذلك: الصدفة للعمل المحلي، وMCP لبضع خدمات مستضافة، ويُقلَّم كل منهما إلى ما تحتاجه المهمة.

جرّبه على PicassoIA

استخدم Claude Sonnet 5 على PicassoIA

يمكنك اختبار هذه المفاضلات على إعدادك الخاص باستخدام Claude Sonnet 5، وهو نموذج مبني للبرمجة متعددة الخطوات واستخدام الأدوات. إليك سير عمل سريع للتدقيق:

1. افتح صفحة النموذج وابحث عن حقل Prompt.
2. الصق أسماء أدوات خوادم MCP التي لديك وأوصافها، ثم اسأل أيّها لن تستدعيه مهمة برمجة معتادة أبدًا.
3. اضبط Effort. low يوقف التفكير ويجيب بأسرع وقت، وهذا كافٍ للفرز الأولي. انتقل إلى high حين تريد مفاضلات مُبرّرة عبر عدة خوادم.
4. اترك Max Tokens على 8192 للمقارنات الطويلة، أو خفّضه حين تريد حكمًا موجزًا.
5. أضف System Prompt مثل "أنت مراجع تكاليف. أجب بجدول وسطر واحد من النصيحة" لإبقاء الردود قصيرة.
6. اطلب مكافئًا على الصدفة لأكثر أدواتك استدعاءً. قارن بين الاثنين باستخدام wc -c لتقدير تقريبي للحجم، واستخدم أرقام الاستخدام لدى مزوّدك للحصول على أعداد التوكنات الدقيقة.

💡 نصيحة: أجرِ التدقيق نفسه باستخدام Kimi K2.6 أو GPT 5.6 Sol وقارن الأدوات التي سيقلّمها كل نموذج.

ثم أنشئ صورك بنفسك

تتبع كل صورة في هذا المقال نمطًا بسيطًا: موضوع واضح واحد، ومصدر ضوء واحد، واختيار واحد للكاميرا والعدسة. جرّب الوصفة نفسها بنفسك. صِف طاولة عمل في التاسعة صباحًا، أو متنزهًا عند مفترق طريق، أو نسختك الخاصة من مكتب مليء بالأدوات، وشغّلها عبر PicassoIA Image. حسّن النتيجة باستخدام PicassoIA Image Editor Pro، وحين تستحق الصورة الثابتة حركة، أرسلها إلى PicassoIA Video. اختر أمرًا نصيًا من مشروعك القادم وانظر ماذا سيعود.