ما هو MCP؟ كيف يتصل وكلاء الذكاء الاصطناعي ببياناتك (تحديث مواصفات 2026)

إن MCP، أو Model Context Protocol، هو معيار مفتوح يتيح لعميل الذكاء الاصطناعي الوصول إلى الأدوات ومصادر البيانات عبر واجهة مشتركة واحدة. وبدلاً من إجراء تكامل مخصص لكل تطبيق، يتحدث العميل بروتوكولاً واحداً ويمكن لأي خادم متوافق الاستجابة له. تمت إعادة كتابة المواصفات في 28 يوليو 2026، وهذا التغيير كبير ومؤثر.
يغطي هذا الدليل وظائف البروتوكول والتغييرات التي طرأت في إصدار 2026-07-28. كما يتطرق إلى الميزات التي أصبحت مهجورة الآن، وكيف يختلف هذا عن التكامل العادي عبر واجهة برمجة التطبيقات (API)، ومتى لا تحتاج إليه. الحقائق الواردة هنا محدثة حتى تاريخ 5 أغسطس 2026.
ما هو MCP؟
تخيل الأمر كشكل قابس مشترك. قبل وجود معيار موحد، كان توصيل المساعد بقاعدة بياناتك، ونظام التذاكر لديك، وملفاتك يعني إجراء ثلاثة تكاملات مخصصة. وكان لكل منها نظام مصادقة خاص به، ومعالجة أخطاء خاصة به، وعبء صيانة مستقل.
يحدد MCP هذا الاتصال مرة واحدة فقط. يمثل العميل جانب الوكيل. بينما يقوم الخادم بتغليف مصدر البيانات أو الأداة ويعرض ما يمكنه القيام به. يسأل العميل الخادم عما هو متاح، ثم يستدعيه.
عادةً ما تعرض الخوادم ثلاثة أنواع من العناصر. الأدوات هي إجراءات يمكن للوكيل استدعاؤها. والموارد هي محتوى قابل للقراءة. والمطالبات هي قوالب قابلة لإعادة الاستخدام. يكتشف العميل هذه العناصر الثلاثة في وقت التشغيل بدلاً من كتابتها برمجياً بشكل ثابت.
يُستخدم الاسم أحياناً بشكل فضفاض، لذا يفيدنا توضيح أمر واحد. البروتوكول ليس نموذجاً، ولا وكيلاً، وليس منتجاً. بل هو صيغة نقل البيانات السلكية بينها.
هناك كلمتان تفسران معظم اللبس المحيط به. الاستكشاف ويعني معرفة العميل بما يقدمه الخادم في وقت التشغيل. وإعادة الاستخدام وتعني أن الخادم نفسه يجيب على أي عميل متوافق.
لم يعد الاعتماد على البروتوكول مجرد أمر نظري. يفيد مطورو البروتوكول بتسجيل ما يقرب من نصف مليار عملية تنزيل شهرياً عبر حزم SDK من الفئة الأولى (Tier 1). وتجاوزت كل من حزم SDK لـ TypeScript و Python المليار عملية تنزيل إجمالاً.
ما الذي تغير في مواصفات 2026-07-28
يعد هذا الإصدار أكبر مراجعة شهدها البروتوكول على الإطلاق. والعنوان الأبرز هو أن النواة أصبحت الآن عديمة الحالة (stateless).
| التغيير | ماذا يعني ذلك |
|---|---|
| نواة عديمة الحالة | اختفت الجلسات والمصافحات. يحمل كل طلب الآن إصدار البروتوكول الخاص به وهوية العميل |
| طلبات متعددة المراحل | تستبدل الطلبات التي يبدأها الخادم والتي كانت تتطلب تدفقاً مفتوحاً. يمكن للأداة الآن أن تطلب مدخلات من المستخدم في منتصف الاستدعاء |
| التوجيه المستند إلى الترويسات | تنتقل أسماء الطرق والأدوات في ترويسات Mcp-Method و Mcp-Name، بحيث تقوم البوابات بالتوجيه والمصادقة بناءً على الترويسات |
| نتائج القوائم القابلة للتخزين المؤقت | تحمل قوائم الأدوات والمطالبات والموارد الآن ttlMs و cacheScope |
| تحصين المصادقة | التحقق من جهة الإصدار وفقاً لمعيار RFC 9207، والانتقال من Dynamic Client Registration إلى Client ID Metadata Documents، واعتماد بيانات اعتماد مرتبطة بجهة الإصدار |
| إطار عمل الامتدادات | انتقال المهام من النواة التجريبية إلى امتداد رسمي، إلى جانب التطبيقات و Enterprise Managed Authorization |
اقرأ هذه القائمة كقرار واحد تكرر ست مرات. يزيل كل تغيير افتراضاً كان يجعل تشغيل الخوادم البعيدة أمراً معقداً. ولا يغير أي من هذا ما يمكن للأداة فعله.
يحتوي منشور مواصفات 2026-07-28 الرسمي على قائمة التغييرات الكاملة. وتدعم حزم SDK لـ TypeScript و Python و Go و C# هذا الإصدار بالفعل، بينما تتوفر نسخة Rust في المرحلة التجريبية.
لماذا تهم النواة عديمة الحالة إذا كنت تدير خادماً
افترض التصميم القديم وجود اتصال مستمر وثنائي الاتجاه. وكان هذا الافتراض الفردي هو السبب وراء معظم صعوبات التشغيل.
كان الخادم البعيد يحتاج سابقاً إلى جلسات مستمرة (sticky sessions) لضمان وصول العميل دائماً إلى نفس المثيل. وكان يحتاج إلى مساحة تخزين مشتركة للجلسات حتى تظل الحالة قائمة بعد إعادة التشغيل. وغالباً ما كان يتعين على البوابات فحص حمولات البيانات لمعرفة ما يفعله الطلب.
لم يعد أي من ذلك مطلوباً الآن. يمكن للخادم أن يعمل خلف موازن تحميل عادي بنظام التناوب الدائري. ويتم التوجيه بناءً على الترويسة. ويقوم العملاء بتخزين قائمة الأدوات مؤقتاً للمدة التي تسمح بها النافذة المحددة للخادم. لقد تحول البروتوكول من شيء تنشره بحذر شديد إلى شيء تنشره بشكل طبيعي تماماً.
هناك تكلفة مرتبطة بعملية الانتقال. فالخوادم التي تم بناؤها بناءً على النواة القديمة تحتاج إلى تعديل، ويجب أن تنتقل مكتبات العملاء معها أيضاً.
كما يقلل هذا التغيير من تكلفة تجربة البروتوكول. فقد كان إنشاء خادم في السابق قراراً يتعلق بالبنية التحتية، أما الآن فقد أصبح أقرب إلى نشر أي خدمة ويب صغيرة.
بالنسبة لأي شخص يقيم خادم MCP الخاص بمورد ما، فإن السؤال العملي الذي يجب طرحه هو: ما هو إصدار المواصفات الذي يستهدفه، ومتى سينتقل إلى الإصدار الجديد؟
ما هي الميزات المهجورة، وكم من الوقت لديك
هناك ثلاث قدرات في طريقها للإلغاء: Roots وSampling وLogging. كما تم إيقاف دعم بروتوكول النقل القديم HTTP+SSE أيضاً.
التزم المطورون بفترة سماح لا تقل عن 12 شهراً قبل الإزالة النهائية. هذه مهلة سخية، ولكنها تمثل موعداً نهائياً أيضاً. إذا قمت بالبناء على أي من هذه العناصر الأربعة، فضع خطة الانتقال ضمن خريطة الطريق بدلاً من تركها في قائمة المهام المؤجلة.
تحقق من العميل الخاص بك أيضاً، وليس الخادم فقط. فالعميل المرتبط ببروتوكول النقل القديم سيستمر في العمل خلال فترة السماح ثم سيتوقف بعد ذلك.
تم إيقاف دعم Dynamic Client Registration رسمياً لصالح Client ID Metadata Documents. وتمنع الآن بيانات الاعتماد المرتبطة بجهة الإصدار إعادة استخدام رمز مميز تم إصداره لخادم معين ضد خادم آخر.
مقارنة بين MCP والتكامل العادي عبر واجهة برمجة التطبيقات (API)
| التكامل المخصص عبر API | خادم MCP | |
|---|---|---|
| العمل المطلوب لكل مصدر | مصادقة ومخطط ومعالجة أخطاء جديدة في كل مرة | بروتوكول واحد، يُعاد استخدامه |
| الاستكشاف | تكتب ما هو موجود برمجياً بشكل ثابت | يسأل العميل في وقت التشغيل |
| من يمكنه استخدامه | التطبيق الذي قمت بدمجه فيه | أي عميل متوافق |
| الصيانة | يتعطل عندما تتغير واجهة برمجة تطبيقات المورد | يمتص الخادم التغيير |
| الأفضل لـ | مسار واحد عميق وعالي الكثافة | مصادر متعددة يصل إليها وكيل واحد |
هناك اعتبار آخر وهو من يقوم بصيانة الموصل. فالخادم الذي ينشره المورد يتطور مع منتج المورد نفسه، وهو عمل لم تعد مضطراً للقيام به بنفسك.
بكل صراحة، لا يعد MCP أسرع أو أرخص لتكامل فردي واحد. بل تظهر قوته عندما يزداد عدد المصادر، أو عندما تريد أن يصل أكثر من وكيل إلى نفس المصدر دون الحاجة لإعادة البناء.
ما يمكنك إنتاجه بمجرد توصيل مصدر البيانات
التوصيل هو مجرد البنية التحتية الأساسية. والسبب الحقيقي لاهتمام أي شخص هو المنتج النهائي الذي يحصل عليه.
عند ربط مصدر البيانات، يمكن للوكيل سحب الأرقام الحالية وإجراء التحليل. وما تحصل عليه في النهاية يكون جاهزاً: مخطط بياني، أو ملخص مكتوب، أو مجموعة شرائح عرض تقديمية. تكمن القيمة في إلغاء خطوة التصدير، وليس في البروتوكول نفسه. كما أن المنتج النهائي هو ما يجعل هذا الإعداد جديراً بالدفاع عنه داخلياً؛ فالاتصال الذي لا يحوله أحد إلى تقرير يتم إيقافه بهدوء.
يقدم Powerdrill Bloom خادماً يعتمد على هذا النمط. ووفقاً لتوثيقه الخاص، فإنه يقوم بالمصادقة باستخدام معرف المستخدم (User ID) ومفتاح واجهة برمجة تطبيقات المشروع (Project API Key). يمكن للعميل بعد ذلك تصفح مجموعات البيانات في حسابك، وسحب التفاصيل حول أي منها، وتشغيل المهام عن طريق طرح الأسئلة بلغة طبيعية. وهو يعمل مع Claude Desktop وغيره من العملاء المتوافقين. يغطي إعلان خادم MCP طريقة الإعداد، بينما تسرد صفحة موصلات البيانات أنواع المصادر الأخرى.
متى لا تحتاج إلى MCP على الإطلاق
يتم تخطي هذا الجزء في معظم الشروحات، لذا يجدر بنا توضيحه بصراحة.
إذا كانت بياناتك تصل في شكل ملف، فلن تحتاج إلى بروتوكول. بل تحتاج إلى عملية رفع ملف فقط. إن التصدير الربع سنوي، أو ملف CSV أرسله شخص ما إليك عبر البريد الإلكتروني، أو كشف حساب بصيغة PDF — لا شيء من هذا يبرر إنشاء خادم. ما عليك سوى سحب الملف وإسقاطه وطرح سؤالك.
اطرح سؤالاً واحداً قبل البدء في البناء: هل ستكون هناك حاجة لنفس هذا التصدير مرة أخرى في الشهر المقبل من قِبل شخص آخر غيرك؟
يستحق MCP عناء الإعداد عندما يكون المصدر مباشراً ومتكرراً. مثل قاعدة بيانات تتغير كل ساعة، أو طابور تذاكر الدعم، أو جدول مستودع بيانات يغذي تقريراً أسبوعياً. الاختبار الحقيقي هو ما إذا كنت ستضطر لتصدير الشيء نفسه مرة أخرى في الأسبوع المقبل لولا وجوده.
هناك أيضاً بعد أمني؛ فالمصدر المتصل يمثل منحاً دائماً للصلاحية، وليس مشاركة لمرة واحدة. وتغييرات المصادقة التي طرأت في 28-07-2026 جاءت لأن هذا الاختلاف جوهري.
باختصار
إن MCP هو قابس قياسي بين الوكلاء ومصادر البيانات. جعل إصدار 2026-07-28 النواة عديمة الحالة، ونقل التوجيه إلى الترويسات، وجعل نتائج القوائم قابلة للتخزين المؤقت، وعزز المصادقة. وتم إيقاف دعم Roots وSampling وLogging وبروتوكول النقل القديم HTTP+SSE مع منح فترة سماح مدتها 12 شهراً.
بالنسبة للملفات التي تستخدم لمرة واحدة، تخطى كل هذا. جرب Powerdrill Bloom مجاناً — ارفع الملف، واطرح سؤالك بلغة طبيعية، ثم قم بتصدير المخطط البياني أو العرض التقديمي. وإذا كنت تقارن بين خيارات الخوادم، فراجع أفضل منصات MCP.
الأسئلة الشائعة
ماذا يعني اختصار MCP؟
Model Context Protocol. وهو معيار مفتوح لتوصيل عملاء الذكاء الاصطناعي بالأدوات ومصادر البيانات عبر واجهة واحدة، مما يغني عن إجراء تكامل مخصص لكل مصدر جديد.
ما الذي تغير في مواصفات MCP بتاريخ 2026-07-28؟
أصبحت النواة عديمة الحالة (stateless)، مع التخلي عن الجلسات والمصافحات. وحلت الطلبات متعددة المراحل (Multi Round-Trip Requests) محل الطلبات التي يبدأها الخادم عبر التدفقات المفتوحة، وانتقل التوجيه إلى ترويسات Mcp-Method و Mcp-Name. كما أصبحت نتائج القوائم قابلة للتخزين المؤقت، وتم تحصين المصادقة من خلال التحقق من جهة الإصدار وبيانات الاعتماد المرتبطة بجهة الإصدار.
هل MCP هو نفسه واجهة برمجة التطبيقات (API)؟
لا. واجهة برمجة التطبيقات (API) هي واجهة خاصة بمورد معين لنظام واحد. أما البروتوكول فهو غلاف مشترك يمكن للعديد من الأنظمة تنفيذه، بحيث يمكن لأي عميل متوافق استكشافها واستدعاؤها دون الحصول على كود مخصص لكل مصدر.
ما هي الميزات التي تم إيقاف دعمها في مواصفات MCP الجديدة؟
تم إيقاف دعم Roots وSampling وLogging، بالإضافة إلى بروتوكول النقل القديم HTTP+SSE. وحل مستند Client ID Metadata Documents محل Dynamic Client Registration. وحدد المطورون فترة سماح لا تقل عن 12 شهراً قبل الإزالة النهائية.
هل أحتاج إلى MCP لتحليل جدول بيانات باستخدام الذكاء الاصطناعي؟
لا. بالنسبة لملف لديك بالفعل، فإن رفعه يعد أسهل وأسرع. يستحق البروتوكول الإعداد عندما يكون المصدر مباشراً ومحدثاً باستمرار، وتكون مضطراً لولا ذلك لإعادة تصدير البيانات نفسها بشكل دوري.