ما هو MCP، ولماذا أصبحت كل أدوات الذكاء الاصطناعي تتحدثه فجأة؟
طوال معظم العقد الماضي، كان ربط نموذج ذكاء اصطناعي بأدوات الشركة يعني تكاملاً مخصصاً لكل زوج. Model Context Protocol، المعيار المفتوح الذي قدّمته Anthropic في نوفمبر 2024، استبدل ذلك بقابس واحد يناسب كل مكان — ومنذ ذلك الحين تبنّته OpenAI وGoogle وMicrosoft جميعاً. إليك كيف يعمل فعلياً، وقائمة تحقق حقيقية قبل أن تربط أحدها ببيانات فريقك.
افتح تطبيق Claude لسطح المكتب واطلب منه مراجعة طلبات السحب المفتوحة لفريقك، فيستطيع أن يفعل ذلك ببساطة. ليس لأن Anthropic بنت تكامل GitHub داخل Claude. بل لأن شخصاً ما، في مكان ما — فريق تقنية المعلومات لديكم، أو مورّداً، أو مطوراً على GitHub — كتب برنامجاً صغيراً يتحدث بروتوكولاً اسمه MCP، وClaude يعرف أصلاً كيف يتحدث إلى أي شيء يتحدثه. والأمر نفسه صار صحيحاً مع ChatGPT وGemini من Google وMicrosoft Copilot. هذا التقارب، أكثر من أي إطلاق لميزة واحدة، هو السبب في أن MCP أصبح الشيء الذي أنفق عليه كل مورّد ذكاء اصطناعي تقريباً العام الماضي في بناء الدعم.
ما هو MCP فعلياً
MCP اختصار لـ Model Context Protocol. صممته Anthropic، وفتحت مصدر المواصفة مع أول حزم SDK في 25 نوفمبر 2024. وصفت مواد الإطلاق الفكرة بتشبيه ثبت: فكّر في MCP كمنفذ USB-C لتطبيقات الذكاء الاصطناعي — معيار موصّل مادي واحد بدل كابل مختلف لكل ملحق. عند الإطلاق، سمّت Anthropic المتبنين الأوائل الذين كانوا يبنون دعم MCP في منتجاتهم، ومنهم شركتا برمجيات المؤسسات Block وApollo، وصنّاع أدوات المطورين Zed وReplit وCodeium وSourcegraph. وصدر تطبيق Claude لسطح المكتب، في اليوم نفسه، مع القدرة على تشغيل خوادم MCP محلياً على جهاز الشخص نفسه.
المشكلة التي يحلها: N أدوات في M مصادر بيانات
للمشكلة التي يحلها MCP اسم يستخدمه المهندسون ببساطة: مشكلة التكامل N في M. لنفترض أن شركة تستخدم خمس أدوات ذكاء اصطناعي تحتاج إلى العمل على بيانات الشركة — Claude وChatGPT وGitHub Copilot وCursor وروبوت دعم داخلي — وأن هذه البيانات تعيش في ثمانية أماكن: Slack وGitHub وقاعدة بيانات Postgres وSalesforce وNotion وGoogle Drive وJira وواجهة API داخلية. من دون بروتوكول مشترك، يحتاج وصل كل أداة بكل مصدر بطريقة مفيدة إلى ما يصل إلى أربعين تكاملاً منفصلاً — خمسة في ثمانية — لكل منها مخطط مصادقة خاص، ومعالجة أخطاء خاصة، وضريبة صيانة خاصة كلما تغيّر شكل إحدى تلك الواجهات. أضف أداة ذكاء اصطناعي سادسة فيقفز العدد إلى ثمانية وأربعين. في الممارسة، لم يبنِ أحد الأربعين كلها. بنى كل مورّد حفنة رأى أنها تستحق وقت الهندسة، وبقي الباقي يدوياً: انسخ، الصق، أعد الشرح، كرّر.
يحوّل MCP الضرب إلى جمع. الشركة التي تريد أن يقرأ Claude من قاعدة Postgres لا تبني موصّل Postgres خاصاً بـ Claude. تبني — أو تعيد استخدام واحد نشره شخص آخر — خادم MCP واحداً يعرض Postgres، ويعمل ذلك الخادم مع Claude أو ChatGPT أو Gemini أو أي وكيل آخر متوافق مع MCP من دون مزيد من الشيفرة. قائمة Anthropic نفسها، عند الإطلاق، سمّت خوادم جاهزة لـ Google Drive وSlack وGitHub وGit وPostgres وأداة أتمتة متصفح اسمها Puppeteer. لم يكن القصد قط أن تبني Anthropic كل ذلك. القصد أن أي أحد يستطيع، وقد نما فهرس الخوادم المتاحة بما يجاوز ما تستطيع شركة واحدة أن توظّف له فريقاً.
كيف يعمل البروتوكول فعلياً
إذا نزعت الإطار، فـ MCP بروتوكول عميل وخادم بسيط إلى حد كبير، غير لامع عن قصد. يعرّف ثلاثة أدوار. Host هو التطبيق الذي يفتحه الشخص فعلياً — Claude Desktop، أو بيئة تطوير مثل Cursor، أو تطبيق ChatGPT. يضم الـ Host عميلاً هو MCP Client، يفتح اتصالاً مباشراً ذا حالة إلى MCP Server — برنامج صغير يعرض نظاماً محدداً: قاعدة بيانات، أو أداة تذاكر، أو نظام ملفات، أو واجهة API داخلية. يتبادل العميل والخادم رسائل بصيغة JSON-RPC 2.0، وهي صيغة خفيفة لاستدعاء الإجراءات عن بعد شائعة أصلاً في البنية القائمة، عبر إحدى وسيلتي نقل: stdio حين يكون الخادم برنامجاً يعمل محلياً على الجهاز نفسه، أو Streamable HTTP حين يكون خدمة مستضافة تعمل في مكان آخر.
ما يستطيع الخادم عرضه يُختزل في ثلاث بدائيات. Tools دوال يستطيع النموذج استدعاءها ليتخذ إجراءً — create_task وrun_query وsend_message — والنموذج يقرر متى يستدعي إحداها بحسب المحادثة. Resources سياق للقراءة فقط يستطيع الـ Host جلبه وتسليمه إلى النموذج من دون أن يضطر النموذج إلى الطلب — محتوى ملف، أو مخطط قاعدة بيانات، أو تذكرة دعم. Prompts قوالب قابلة لإعادة الاستخدام يطلقها المستخدم — «لخّص هذا الخيط» أو «اصغ تحديث حالة» جاهزاً يستدعيه الشخص صراحة، لا شيئاً يقرره النموذج من تلقاء نفسه. الخادم المبني جيداً يصرّح بأي من الثلاثة يقدّمه لقدرة معينة، لأن هذا التمييز هو بالضبط ما يحدد إن كانت أداة الذكاء الاصطناعي المتصلة تستطيع أن تنظر إلى شيء أو أن تغيّره.
من تبنّاه أيضاً، ومتى
كانت الأشهر الأولى من MCP مشروعاً لـ Anthropic وحدها. تغيّر ذلك بسرعة، وبطريقة غير مألوفة حقاً في الذكاء الاصطناعي: تقارب منافسون مباشرون على بروتوكول شركة واحدة بدل أن يصدر كل منهم بروتوكوله. أضافت OpenAI دعم MCP إلى Agents SDK في مارس 2025، فصار بإمكان المطورين وصل تدفقات الوكلاء بأي خادم MCP بدل بناء تكاملات أدوات خاصة بـ OpenAI. في الشهر التالي، أكدت Google DeepMind أن Gemini وحزمة تطوير الوكلاء الخاصة بها ستدعمان MCP أيضاً — خطوة قرنتها Google ببروتوكولها المكمّل Agent2Agent، الهادف إلى أن ينسّق الوكلاء المستقلون بعضهم مع بعض لا مع الأدوات. وبحلول مايو 2025، كانت Microsoft قد جلبت دعم MCP الأصلي إلى Windows 11 عبر ما تسميه Windows AI Foundry، مع دعم وصل أيضاً إلى GitHub Copilot وCopilot Studio.
لا تتفق هذه الشركات الأربع على الكثير حين يتعلق الأمر ببنية النماذج أو التسعير أو استراتيجية المنصة. والأربع جميعاً تصدر الآن منتجات تتحدث البروتوكول نفسه لوصل وكيل بأداة. هذا نادر بما يكفي في هذه الصناعة ليكون القصة الفعلية — أكثر من أي ميزة مفردة يتيحها MCP.
لماذا هذه مسألة ثقة، لا مجرد تمديدات
هذا التقارب مفيد حقاً، وهو أيضاً السبب الذي يجعل MCP يستحق التدقيق لا الثقة العمياء. البروتوكول الذي يجعل وصل وكيل بأنظمة شركتك أمراً تافهاً هو نفسه الذي يجعل وصول اتصال مبني بسوء أو مهيأ بسوء إلى تلك الأنظمة نفسها أمراً تافهاً. MCP ذاته لا يمنع ذلك. المواصفة تعرّف كيف يتحدث العميل والخادم — ولا تقول شيئاً عمن يُسمح له بمنح الاتصال، أو ما يُسمح لذلك الاتصال أن يلمسه، أو إن كان أحد سيلاحظ إذا سار شيء على غير ما يرام. هذه الاختيارات تقع بالكامل على من بنى الخادم أو العميل المحدد أمامك أو هيّأه. بعض المورّدين يبنون كل ذلك بعناية. وبعضهم لا يبنيه أصلاً، والبروتوكول لن يوقفهم.
MCP بروتوكول سلك، لا نظام تحكم في الوصول. يوحّد كيف يطلب وكيل من أداة أن تفعل شيئاً. أما إن كان ذلك الطلب محدداً النطاق ومسجّلاً وقابلاً للإلغاء، فقرار اتخذه أحدهم — أو لم يتخذه — فوق البروتوكول.
قائمة تحقق قبل أن تربط أحدها
قبل أن يربط فريقك خادم MCP — سواء كان منتج مورّد، أو أداة مفتوحة المصدر وجدها أحدهم على GitHub، أو شيئاً بُني داخلياً — تفصل ستة أسئلة اتصالاً محكوماً عن باب مفتوح. لا يتطلب أي منها قراءة المواصفة. تتطلب فقط أن يسأل أحد قبل أن ينقر الموافقة، وأن يقرأ فعلاً الجواب الذي تعيده شاشة الاتصال.
| اسأل هذا | كيف يبدو الجيد | انتبه إلى |
|---|---|---|
| ما النطاقات أو Tools التي يطلبها؟ | مفصّل قائمة مسماة ومحددة تستطيع قراءتها قبل الموافقة — «إنشاء مهام، قراءة الرسائل في هذه القناة». | شامل «وصول كامل إلى الحساب» من دون قائمة مفصّلة بما يستطيع فعله فعلياً. |
| هل هو للقراءة فقط، أم يستطيع الكتابة والفعل؟ | منفصل وصول القراءة هو الافتراضي؛ أي إجراء يغيّر البيانات يحتاج منحاً ظاهراً خاصاً به. | مجمّع وصول الكتابة مضمّن تلقائياً، من دون طريقة لمعرفة أي قدرة تفعل ماذا. |
| هل هو لكل شخص أم مشترك على مستوى الفريق؟ | لكل شخص كل شخص يسجّل دخوله بحسابه؛ والوكيل لا يرى إلا ما يستطيع ذلك الشخص رؤيته. | مشترك مفتاح API واحد أو حساب خدمة يستخدمه الفريق كله، متجاوزاً الأذونات الفردية. |
| هل يوجد سجل تدقيق لما فعله؟ | مسجّل كل استدعاء لأداة مسجّل — من وصلها، وما لمسته، ومتى. | بلا سجل لا سجل سوى ما تختار أداة الذكاء الاصطناعي نفسها أن تخبرك بأنه حدث. |
| هل يمكن إلغاؤه فوراً؟ | فوري مفتاح واحد، يسري حالاً، من صفحة إعدادات تتحكم بها. | مؤجّل الإلغاء يتطلب تذكرة دعم، أو اتصالاً بالمورّد، أو أنه غير ممكن أصلاً. |
| هل يكسر إلغاؤه شيئاً آخر؟ | معزول محصور في ذلك الاتصال الواحد؛ إطفاؤه يؤثر فيه وحده. | متشابك يشارك بيانات اعتماد مع أدوات أخرى، فإلغاء واحد يكسر ثلاثة أخرى بهدوء. |
كيف يبدو اتصال مبني جيداً فعلياً
إعداد MCP الخاص بـ FabricLoop جواب ملموس عن تلك القائمة — لا لأنه استثنائي، بل لأن كل قطعة تطابق مباشرة أحد الأسئلة الستة أعلاه، ويستحق الأمر تسمية الآليات الفعلية لا نسخة التسويق منها. تعمل FabricLoop في الدورين معاً: هي خادم MCP تتصل به الأدوات الخارجية، فيستطيع Cursor أو Claude أو ChatGPT إنشاء مهمة أو إضافة تعليق أو قراءة ملاحظة باستخدام أذونات FabricLoop الخاصة بشخص محدد — وهي عميل MCP يتصل إلى الخارج، فيستطيع قناة أن تجلب تطبيق MCP لمورّد، مثل GitHub أو Linear، وأن تشير إليه بـ @mention كأنه زميل.
كل اتصال، في أي اتجاه، يبدأ بشخص لا بمساحة عمل. وصل عميل خارجي مثل Cursor يفتح شاشة موافقة OAuth على app.fabricloop.com/oauth/consent، حيث يختار ذلك الشخص مساحة عمل ويوافق على الأدوات المحددة التي يطلبها العميل — ثم لا يستطيع العميل أن يتصرف إلا بالنطاقات الممنوحة على تلك الشاشة، تحت أذونات ذلك الشخص وحده، لا عبر حساب خدمة مشترك أبداً. الاتجاه العكسي يسير بالطريقة نفسها: يستطيع مسؤول تمكين تطبيق MCP لمورّد للفريق كله، لكن كل شخص يكمل تسجيل دخوله الخاص قبل أن يعمل له، ويستطيع المسؤول ضبط ذلك التطبيق على وضع القراءة فقط أو حصره في قائمة سماح بأدوات محددة بدل كل ما يعرضه المورّد.
كل عميل متصل يظهر على شاشة إعدادات إلى جانب عنصر تحكم «إلغاء» يقطعه فوراً — صفحة الشخص نفسه، لا تذكرة دعم. وفي خطط Enterprise، تصل تلك النشاطات — بما فيها منح MCP وما فعله الوكيل المتصل فعلياً — إلى سجل تدقيق يستطيع فريق الأمن مراجعته عند الطلب، لا لقطات شاشة تُسحب من خيط دردشة بعد وقوع الأمر.
لا شيء من ذلك هندسة غريبة. إنها مجموعة صغيرة من القرارات، غير لامعة عن قصد، تُكرَّر باتساق: حدّد النطاق، اربطه بشخص، سجّله، اجعله قابلاً للإلغاء من دون ضرر جانبي. هذه الحجة نفسها التي يطرحها هذا الموقع عن Legibility بمعنى أوسع — وصول تستطيع تسميته وتسجيله وإلغاءه يتفوق على وصول لا يضطر أحد إلى التفكير فيه — وMCP لا يقدّم ذلك إلا حين يبنيه أحد بهذه الطريقة. البروتوكول يجعل التمديدات معياراً. وهو لا يجعل الحوكمة تلقائية.
القرار الذي يهم فعلياً
MCP لن يختفي، والاعتراض عليه في هذه المرحلة يشبه قليلاً الاعتراض على USB. كل مزوّد نماذج كبير يصدره الآن، وقائمة الخوادم المتاحة تستمر في النمو، والوكيل الذي لا يصل إلى أدواتك هو، لمعظم العمل الحقيقي، وكيل لا يستطيع أن يفعل الكثير. القرار المثير ليس إن كنت تسمح لأداة ذكاء اصطناعي بالاتصال بأنظمتك — فشيئاً فشيئاً، تُتخذ نسخة من ذلك القرار نيابة عنك، تكاملاً بعد تكامل، حين تضيف أدوات يستخدمها فريقك أصلاً دعم MCP بهدوء تحت ميزة نقرت عليها من دون قراءة الحروف الصغيرة. القرار الذي ما زال لك فعلياً هو ما تتحقق منه قبل أن تنقر الموافقة.
وحّد MCP كيف يطلب وكيل ذكاء اصطناعي من أداة أن تفعل شيئاً. ولم يفعل شيئاً لتوحيد إن كان منح ذلك الطلب آمناً — وهذا الجزء ما زال، وسيبقى، قرار الشخص الذي ينقر «موافقة».