كذبة «المهارات».. لماذا يخطئ الجميع في حق بروتوكول MCP؟

ربما أقضي وقتاً أطول من اللازم على منصة (X)، لكن السردية المنتشرة مؤخراً بدأت تصيبني بالصداع: «بروتوكول MCP مات، والمهارات (Skills) هي المعيار الجديد». الجميع يحتفل برمي ملف SKILL.md في مستودعاتهم البرمجية وكأنهم اكتشفوا العجلة. بصراحة؟ أنا لا أحب المهارات.

أنا مستخدم شره للذكاء الاصطناعي، أعتمد على Claude Code وGemini في البرمجة، وأدير ملاحظاتي في Notion وقواعد بيانات DEVONthink عبر ChatGPT وPerplexity يومياً. ومن واقع هذه التجربة، أرى أن الاندفاع نحو «المهارات» كحل شامل هو تراجع تقني للخلف. بروتوكول سياق النموذج (MCP) هو من أصاب كبد الحقيقة في التصميم الهندسي، لا المهارات التي تعيدنا لعصر كتيبات التشغيل اليدوية.

جوهر الفلسفة في MCP بسيط للغاية: إنه تجريد للواجهة البرمجية (API). النموذج لا يحتاج لفهم «كيف» يتم الأمر، بل يحتاج فقط لمعرفة «ماذا» سيفعل. إذا أراد النموذج التعامل مع تطبيق معين، فإنه يستدعي دالة برمجية محددة، ويتولى خادم MCP الباقي. هذا الفصل بين المهام يمنحنا ميزات لا يمكن هزيمتها، مثل الاستخدام عن بُعد دون تثبيت أي شيء محلياً، وتحديثات سلسة فورية للعملاء بمجرد تحديث الخادم. والأهم من ذلك، هو نظام المصادقة (Auth)؛ فبدلاً من إجبار المستخدم على إدارة مفاتيح API في نصوص برمجية مكشوفة، يتم التعامل مع الأمر عبر OAuth بشكل احترافي.

المشكلة الكبرى في «المهارات» تظهر عندما تتطلب واجهة سطر أوامر (CLI) لتعمل. لنتوقف هنا قليلاً. أغلب بيئات الذكاء الاصطناعي الحالية -مثل النسخة الويب من Claude أو Perplexity- لا يمكنها تشغيل CLI أصلاً. هذا يعني أن أي «مهارة» تعتمد على سطر أوامر هي ميتة إكلينيكياً خارج بيئة المطور المحلية.

هناك فوضى في النشر، وكابوس في إدارة الأسرار البرمجية. أين تضع توكنات الـ API؟ في ملف .env؟ ماذا لو كانت البيئة مؤقتة وتمسح نفسها؟ ثم يأتي «انتفاخ السياق»؛ استخدام المهارة غالباً ما يجبرك على تحميل ملف SKILL.md كاملاً في نافذة السياق، بدلاً من مجرد تمرير توقيع الأداة التي يحتاجها النموذج فعلياً. الأمر يشبه إجبار شخص على قراءة دليل مالك السيارة بالكامل لمجرد أنه يريد تشغيل المحرك.

بالطبع، ليست كل المهارات سيئة. المهارات المعرفية البحتة -تلك التي تعلم النموذج كيفية صياغة رسائل التزام الكود (Commit messages) أو شرح مصطلحات الشركة الداخلية- تعمل بشكل رائع. شركة Anthropic نفسها تستخدم هذا الأسلوب في «مهارة PDF» لشرح كيفية التعامل مع الملفات باستخدام بايثون. هذا منطقي. لكن عندما يتعلق الأمر بربط خدمة مثل Google Calendar، هل يعقل أن نطلب من النموذج تثبيت CLI وإدارة التوكنات يدوياً؟ شركة Notion فعلت الصواب تماماً بتوفير خادم MCP عن بُعد، مما يجعل الاتصال أصيلاً وبروتوكولياً.

بنيت أدوات مثل MCP Nest و microfn لأنني أؤمن بالموصلات (Connectors) لا بالكتيبات. المهارة يجب أن تكون مجرد «ورقة غش» (Cheat Sheet) تخبر النموذج ببعض الخفايا، مثل تنسيق تاريخ معين يفضله خادم الـ MCP، وليست بديلاً عن الربط البرمجي المتين.

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