Model Context Protocol (MCP) معيار مفتوح يوفّر طريقة موحدة لربط تطبيقات الذكاء الاصطناعي بالأدوات والبيانات والأنظمة الخارجية. فبدل أن يبني المطور تكاملًا مختلفًا لكل نموذج ولكل خدمة، يستطيع إنشاء MCP Server يعرّف قدراته بطريقة معيارية، لتتصل به التطبيقات الداعمة لـMCP فتكتشف هذه القدرات وتستخدمها.
ويمكن تشبيه الفكرة بمنفذ موحّد لتطبيقات الذكاء الاصطناعي:
التطبيق الذكي يعرف كيف يتحدث MCP، والخادم يعرف كيف يعرض الأدوات والبيانات عبر MCP، فيقل مقدار "Glue Code" المطلوب بين الطرفين.
ظهر MCP في نوفمبر 2024 حين قدمته Anthropic معيارًا مفتوحًا لربط أنظمة الذكاء الاصطناعي بمصادر البيانات والأدوات، ثم اتسع اعتماده بسرعة. وفي ديسمبر 2025 جرى التبرع بالمشروع إلى Agentic AI Foundation (AAIF) التابعة لـLinux Foundation، بهدف ترسيخ حوكمة محايدة ومفتوحة له. وبحلول 2026 أصبح MCP مستخدمًا في عدد كبير من منتجات الذكاء الاصطناعي ووكلائه وبيئات التطوير، وتبنته منصات متعددة خارج منظومة Anthropic.
المشكلة التي يحاول MCP حلها
لا يستطيع النموذج اللغوي وحده عادة الوصول مباشرة إلى قاعدة بيانات شركتك، ولا إلى ملفات جهازك، ولا إلى GitHub أو نظام CRM أو نظام الفوترة أو التقويم أو محرك البحث الداخلي أو خدمات SaaS أو أدوات تنفيذ الكود أو واجهات APIs الخاصة بالمؤسسة. ولكي يستخدم هذه الأنظمة، لا بد من طبقة ربط.
وقبل ظهور معيار مشترك، كان التكامل يُبنى بطريقة حِرفية: كل نموذج لغوي يحتاج تكاملًا خاصًا مع كل خدمة، مكتوبًا بلغة المشروع وافتراضات فريقه. فالنموذج A يتصل بخدمة الوثائق عبر موصّل كتبه فريقه، وبنظام الفوترة عبر موصّل آخر مختلف تمامًا في تصميمه، ثم يأتي النموذج B فيحتاج إعادة بناء الجسرين من جديد بواجهات ثالثة ورابعة. والنتيجة شبكة تكاملات متقاطعة يساوي حجمها حاصل ضرب عدد النماذج في عدد الخدمات، لكل خيط منها سجل إصدارات وثغرات أمنية ودورة صيانة مستقلة. ومع تزايد النماذج والأدوات تتضخم هذه الشبكة حتى تصبح إضافة خدمة واحدة مشروعًا مؤسسيًا قائمًا بذاته.
أما MCP فيقلب المعادلة عبر طبقة وسيطة موحدة: يتحدث كل تطبيق ذكاء اصطناعي إلى الخدمات الخارجية عبر MCP Client يدمجه المطور داخل التطبيق، ويعرض كل مزود بيانات أو أدوات إمكاناته عبر MCP Server يلتزم بالبروتوكول، ويجري الحوار بين الطرفين عبر بروتوكول MCP الذي يوحّد صيغة اكتشاف الإمكانات واستدعاء الأدوات وقراءة الموارد. وبهذا يتحول التعقيد من حاصل ضرب إلى حاصل جمع: يلتزم كل طرف بالمعيار مرة واحدة فقط، فتظهر الخدمات الجديدة للنماذج كلها دون تعديل، وتصل النماذج الجديدة إلى كل الخدمات القائمة دون بناء جسور خاصة.
وهذا لا يلغي APIs ولا قواعد البيانات، بل يضيف فوقها طبقة معيارية موجهة لتطبيقات الذكاء الاصطناعي ووكلائه.
MCP في مقابل ما يشبهه
يُخلط MCP كثيرًا بتقنيات تقع في طبقات مختلفة، والتمييز بينها شرط لفهم دوره الحقيقي.
هل MCP واجهة API جديدة؟
ليس بديلًا عن API بالمعنى التقليدي. فإذا كانت لديك REST API تقدم عمليات مثل جلب بيانات العميل 123 عبر GET /customers/123 أو إنشاء تذكرة عبر POST /tickets، فقد يستخدم MCP Server هذه الواجهة خلف الكواليس.
الفرق أن MCP يحدد طريقة موحدة يستطيع بها تطبيق الذكاء الاصطناعي اكتشاف ما هو متاح، وقراءة وصف الأدوات، ومعرفة مخطط (Schema) المدخلات، واستدعاء الأداة، واستلام النتيجة، والوصول إلى الموارد والسياق، واستخدام القوالب أو القدرات الإضافية التي يدعمها الخادم. فـREST/OpenAPI تصف واجهة خدمة أو نظام، بينما يصف MCP طريقة التواصل بين تطبيقات الذكاء الاصطناعي وخوادم تقدم لها أدوات وسياقًا، والاثنان قادران على العمل معًا.
MCP وFunction Calling
هذا من أكثر الأسئلة شيوعًا. فـFunction Calling قدرة داخل النموذج أو واجهته البرمجية تسمح له باختيار دالة من مجموعة دوال عُرّفت له، مثل get_weather(city) أو send_email(to, subject, body). لكن المطور يبقى مسؤولًا عادة عن تعريف الدوال، وتوصيلها بالخدمات، وإدارة الاتصال، وإعادة النتائج، وكتابة التكامل.
أما MCP فيوحّد جزءًا أكبر من هذه المنظومة: إذ يعرض الخادم مجموعة من الأدوات والموارد بطريقة معيارية، فيكتشفها أي Client متوافق ويتعامل معها. وباختصار:
Function Calling يحدد كيف يطلب النموذج استدعاء وظيفة، بينما MCP يحدد واجهة أوسع لاكتشاف وربط واستخدام قدرات خارجية بين تطبيق AI وخادم مستقل.
وهما ليسا متنافسين بالضرورة؛ فقد يستخدم تطبيق MCP آلية Tool Calling داخل النموذج ليقرر أي أداة من خادم MCP يجب استدعاؤها.
MCP وLangChain وLlamaIndex
هنا يقع الفرق في الطبقة المعمارية. فـLangChain إطار لبناء تطبيقات ووكلاء تعتمد على النماذج اللغوية، وقد يدير الوكلاء والأدوات وسير العمل واستدعاءات النماذج والاسترجاع والحالة. وLlamaIndex إطار يركز كثيرًا على ربط نماذج الذكاء الاصطناعي بالبيانات وبناء أنظمة Retrieval/RAG ووكلاء البيانات. أما MCP فليس إطارًا لبناء التطبيق كاملًا، بل Protocol / Standard يحدد طريقة التواصل بين التطبيق والخدمات الخارجية.
ولهذا يستطيع تطبيق مبني بـLangChain أو LlamaIndex أن يستخدم خوادم MCP، بدل أن يكون MCP بديلًا عنهما. فالإطاران يجيبان عن سؤال «كيف أبني التطبيق؟»، بينما يجيب MCP عن سؤال «كيف يتحدث التطبيق مع أدوات وبيانات خارجية بطريقة معيارية؟».
MCP وRAG
يسترجع RAG معلومات مرتبطة بالسؤال ويضعها في سياق النموذج. ففي مساره النموذجي يدخل السؤال إلى بحث اتجاهي في فضاء المتجهات، فتُسترجع الوثائق الأقرب معنى، وتُحقن في سياق النموذج اللغوي الذي يصوغ إجابته بناءً عليها. فالنمط كله يدور حول تعبئة السياق بمحتوى ملائم قبل التوليد، ولا يتجاوز ذلك.
أما MCP فمعيار اتصال عام: يمكن لخادم MCP أن يعرض أداة تجري بحث RAG، لكنه يستطيع أيضًا إنشاء Issue، أو تشغيل استعلام، أو إرسال رسالة، أو قراءة ملف، أو تشغيل سير عمل. فـRAG نمط أو تقنية، بينما MCP بروتوكول قادر على حمل قدرات تشمل RAG وغيره.
هل MCP إطار لبناء الوكلاء؟
لا. فـMCP لا يحدد وحده الخطة، ولا سياسة الذاكرة، ولا حلقة الاستدلال، ولا استراتيجية إعادة المحاولة، ولا تنسيق الوكلاء المتعددين، ولا تفكيك الأهداف؛ فهذه كلها مسؤولية إطار الوكلاء أو المضيف. ما يقدمه MCP للوكيل هو طريقة معيارية للوصول إلى العالم الخارجي.
معمارية MCP: ثلاثة أدوار
يُشرح MCP عادة عبر ثلاثة أدوار رئيسية.
المضيف (MCP Host)
هو التطبيق الذي يتفاعل معه المستخدم ويستخدم قدرات MCP، سواء كان مساعدًا ذكيًا، أو محرر أكواد، أو تطبيق سطح مكتب، أو منصة وكلاء، أو تطبيقًا مخصصًا داخل مؤسسة. والمضيف هو من يقرر كيف تُعرض الأدوات على النموذج، وكيف تُدار موافقة المستخدم، وما البيانات التي تدخل السياق.
العميل (MCP Client)
هو المكون الذي يتحدث بروتوكول MCP مع الخادم، فيتولى الاتصال، والتفاوض على نسخة البروتوكول، واكتشاف القدرات، وإرسال الطلبات، واستلام النتائج، وإدارة الأخطاء. وقد يكون العميل جزءًا داخليًا من المضيف لا يراه المستخدم مباشرة.
الخادم (MCP Server)
يعرض وظائف أو بيانات للتطبيق، وقد يلتف حول قاعدة بيانات، أو واجهة SaaS، أو نظام ملفات، أو مستودع Git، أو خدمة سحابية، أو خدمة داخلية، أو أداة تحليل، أو نظام أعمال. وهنا نقطة جوهرية:
MCP Server ليس النموذج اللغوي نفسه.
بل هو خدمة تتيح لتطبيق الذكاء الاصطناعي الوصول إلى قدرات خارجية بطريقة منظمة.
ماذا يعرض MCP Server؟
يقدم الخادم ثلاثة أنواع أساسية من القدرات، هي من أهم مفاهيم MCP.
الأدوات (Tools)
وظائف قابلة للاستدعاء لتنفيذ عملية، مثل إنشاء تذكرة (create_ticket)، أو البحث في مستودع (search_repository)، أو تشغيل استعلام (run_query)، أو إرسال رسالة (send_message)، أو توليد تقرير (generate_report). وتحتوي الأداة عادة على اسم، ووصف، ومخطط للمدخلات (Input schema)، وأحيانًا مخطط للمخرجات (Output schema)، ومنطق تنفيذ فعلي داخل الخادم. وفي مواصفة 2026 الأحدث أصبحت مخططات الأدوات تدعم نطاقًا أوسع من JSON Schema 2020-12، ما يمنح توصيف المدخلات والمخرجات مرونة أكبر.
الموارد (Resources)
بيانات أو محتوى يستطيع التطبيق الوصول إليه، كملف، أو وثائق، أو سجل، أو مخطط قاعدة بيانات، أو محتوى مشروع. ويمكن التفكير في الموارد بوصفها سياقًا قابلًا للقراءة، لا أفعالًا تنفيذية.
القوالب (Prompts)
قوالب أو تدفقات Prompt يوفرها الخادم ليعرضها العميل أو يستخدمها، وتفيد حين يريد الخادم تقديم سير عمل لغوي جاهز مرتبط بأدواته أو بياناته. لكن لا يجوز التعامل مع هذه القوالب كأنها تعليمات أمنية موثوقة تلقائيًا؛ فالمضيف هو المسؤول عن كيفية دمج أي تعليمات خارجية في سياق النموذج.
كيف يعمل استدعاء أداة عبر MCP؟
تمر العملية بتسلسل واضح: يتلقى التطبيق سؤال المستخدم، فيتعرف المضيف أو النموذج على الحاجة إلى قدرة خارجية، ويعرف العميل الأدوات المتاحة في خادم MCP، فيختار النموذج أو منطق التطبيق الأداة المناسبة. وقد يطلب المضيف موافقة المستخدم إذا كانت العملية حساسة، ثم يرسل العميل طلب استدعاء الأداة، فينفذ الخادم العملية ويعيد النتيجة، ويضيفها التطبيق إلى السياق، ليولّد النموذج استجابة نهائية أو يتابع خطوات أخرى.
خذ مثلًا مستخدمًا يطلب: «اعرض لي آخر ثلاث تذاكر دعم مفتوحة للعميل X». فبدل أن يخمّن النموذج، يسير الطلب في مسار منظم: يسأل المستخدم المضيف، فيختار المضيف الأداة المناسبة، search_support_tickets، ويستدعيها عبر عميل MCP، فيصل الطلب إلى الخادم الذي يترجمه إلى استدعاء لواجهة نظام الدعم. وتعود النتيجة بيانات مهيكلة تدخل سياق النموذج، فيصوغها إجابة مقروءة. وفي كل حلقة من هذه السلسلة تعمل واجهة محددة السلوك، لا تخمين حر.
فقيمة MCP هنا ليست أن النموذج "أصبح يعرف التذاكر"، بل أن الوصول إليها صار عبر واجهة منظمة قابلة لإعادة الاستخدام.
البروتوكول وطرق النقل
هل يستخدم MCP بروتوكول JSON-RPC؟
نعم، يستخدم MCP رسائل منظمة مبنية على JSON-RPC 2.0. لكن تفاصيل دورة الاتصال تطورت مع إصدارات البروتوكول، والمقالات التي وصفت MCP في مطلع 2025 قد تختلف تقنيًا عن المواصفة الحالية في 2026.
أحدث إصدار مهم في 2026
في 28 يوليو 2026 صدر إصدار المواصفة 2026-07-28، وهو من أكبر التحديثات منذ إطلاق البروتوكول. ومن أهم تغييراته انتقال نواة البروتوكول على HTTP نحو نموذج Stateless request/response بدرجة أكبر، وهو ما يسهّل وضع الخوادم خلف موازنات الحمل (Load Balancers)، ويقلل الاعتماد على الجلسات اللاصقة (Sticky Sessions)، ويحسن قابلية التوسع، ويجعل كل طلب أكثر استقلالًا، وييسّر التوجيه والتفويض في البنية التحتية.
كما أضاف الإصدار التوجيه القائم على الترويسات (Header-based routing)، وتحسينات في التفويض، وتلميحات تخزين مؤقت لقوائم الأدوات والقوالب والموارد، وإطارًا للامتدادات، وتغييرات في العمليات طويلة المدة والتفاعلات متعددة الجولات. وهذه نقطة بالغة الأهمية عند قراءة الدروس القديمة: MCP تطور بسرعة، لذلك يجب دائمًا التحقق من Protocol Version التي يستهدفها المثال.
النقل عبر stdio
يناسب هذا النقل خصوصًا الحالات التي يشغّل فيها المضيف خادم MCP محليًا عملية فرعية (Child Process)، ويجري التواصل عبر stdin وstdout. وهو شائع في الأدوات المحلية ومحررات الكود، ومن مزاياه البساطة محليًا، وعدم الحاجة إلى فتح منفذ شبكي. لكن الخادم يحصل على مستوى الوصول الذي يمنحه له نظام التشغيل والبيئة التي شُغّل فيها، ولذلك قد يكون تشغيل خادم غير موثوق محليًا خطرًا.
النقل عبر Streamable HTTP
هو المسار الحديث للخوادم البعيدة، ويسمح باستخدام بنية HTTP العادية مع دعم البث (Streaming) عند الحاجة، وقد أصبحت بنيته في مواصفة 2026-07-28 أكثر انعدامًا للحالة على مستوى البروتوكول.
ماذا عن HTTP + SSE؟
هذه نقطة تحتاج تحديثًا في كثير من الشروحات القديمة. فالنقل المبني على HTTP+SSE كان مستخدمًا في الإصدارات السابقة، لكنه أصبح في المواصفة الأحدث Legacy HTTP+SSE transport deprecated مع فترة انتقالية. ولذلك لا ينبغي عند بناء تكامل جديد في 2026 تقديم HTTP+SSE القديم على أنه الطريق الأساسي الحديث.
ما الذي تغيّر في MCP 2026 غير النقل؟
التوجيه القائم على الترويسات
تحمل طلبات Streamable HTTP الحديثة معلومات مثل الطريقة (Method) والاسم (Name) في ترويسات معيارية، ما يساعد البوابات وجدران حماية تطبيقات الويب (WAF) وموازنات الحمل وأنظمة تحديد المعدل وطبقات التفويض على اتخاذ قراراتها دون الحاجة إلى تحليل كامل لجسم الطلب في كل مرة.
القوائم القابلة للتخزين المؤقت
يمكن أن تتضمن نتائج عمليات مثل tools/list وprompts/list وresources/list وresources/read معلومات للتخزين المؤقت، فيقل جلب القوائم مجددًا دون داعٍ.
تشديد التفويض
أصبحت المواصفة أكثر صرامة في بعض تفاصيل OAuth، والتحقق من الجهة المُصدِرة (Issuer validation)، وعزل الاعتمادات بين خوادم التفويض.
الامتدادات
بات للبروتوكول إطار رسمي للامتدادات بدل إدخال كل ميزة جديدة في النواة، ومن أمثلته Tasks وMCP Apps وامتدادات موجهة للمؤسسات.
ميزات في مسار الإهمال
وُضعت في إصدار 2026 ميزات مثل Roots وSampling وLogging في مسار الإهمال (Deprecation) ضمن النواة، مع بدائل واتجاهات أحدث. ولا يعني ذلك اختفاءها فورًا، فهناك سياسة إهمال وفترة توافق، لكنه يعني أن المشاريع الجديدة يجب أن تقرأ المواصفة الحالية بدل الاعتماد على أمثلة قديمة.
الأمان: المعيارية ليست حماية
هل يجعل MCP نظام الذكاء الاصطناعي آمنًا تلقائيًا؟
لا، وهذه من أهم النقاط على الإطلاق. فـMCP يوحّد طريقة الاتصال، لكنه لا يحل تلقائيًا سوء تصميم الصلاحيات، ولا حقن التعليمات (Prompt Injection)، ولا إساءة استخدام الأدوات، ولا تسريب الأسرار، ولا تنفيذ الأوامر الخطرة، ولا الخوادم غير الموثوقة، ولا المخططات المضللة، ولا النتائج الخبيثة من الأدوات، ولا مشكلات Confused Deputy، ولا الصلاحيات المفرطة.
فإذا منحت أداة مثل delete_all_customer_data() صلاحيات كاملة، فلن يجعلها MCP آمنة لمجرد أنها مكشوفة عبر بروتوكول معياري. فالأمان مسؤولية مشتركة بين المضيف، والعميل، والخادم، ومزود الهوية، والأداة الخلفية، والمطور، والمستخدم أو المؤسسة.
أهم ممارسات أمان MCP
| الممارسة | ما تعنيه عمليًا |
|---|---|
| Least Privilege | امنح كل خادم وأداة أقل صلاحيات ممكنة؛ فأداة القراءة لا تحتاج صلاحية كتابة أو Admin أو وصولًا إلى كل Tenant، وأداة تقرأ التذاكر لا تحتاج صلاحية حذف الحسابات |
| افصل القراءة عن الكتابة | اجعل أدوات مثل get_customer وlist_invoices منفصلة عن refund_invoice وdelete_customer، ليطبق المضيف سياسات موافقة مختلفة |
| موافقة المستخدم للعمليات الحساسة | قبل إرسال بريد، أو نشر محتوى، أو حذف ملف، أو تحويل مال، أو إنشاء مستخدم، أو تعديل بيئة الإنتاج، يطلب المضيف تأكيدًا واضحًا |
| لا تثق بوصف الأداة وحده | الوصف يأتي من الخادم، وقد يكون مضللًا إن كان الخادم غير موثوق؛ فتعامل مع الخوادم كأي اعتمادية برمجية: تحقق من المصدر، وراجع الكود أو المزود، وثبّت الإصدارات عند الحاجة، وراقب التحديثات |
| تحقق من جميع المدخلات | أدوات MCP ليست معفاة من قواعد الأمن التقليدية؛ امنع SQL Injection وCommand Injection وPath Traversal وSSRF وUnsafe deserialization |
| افصل أسرار الاعتماد | لا تضع مفاتيح API داخل الـPrompt، واستخدم مديري الأسرار وOAuth ورموزًا محدودة النطاق وقصيرة العمر |
| سجّل العمليات ذات الأثر | سجل تدقيق يوضح من طلب الفعل، وبأي أداة، ومتى، وبأي معاملات، وما النتيجة، وهل وافق المستخدم، دون تخزين معلومات حساسة بلا داعٍ |
| ضع حدودًا للمعدل | النموذج قد يستدعي الأداة مرات عديدة؛ فاستخدم الحدود والحصص والميزانيات والمهل الزمنية وIdempotency حين يلزم |
| عامل مخرجات الأدوات كبيانات غير موثوقة | المحتوى المجلوب من الإنترنت أو من مستند خارجي قد يحمل Prompt Injection، فلا يجوز أن تتحول كل جملة فيه إلى تعليمات ذات سلطة أعلى |
| اعزل التنفيذ | الأدوات التي تنفذ كودًا أو أوامر نظام تحتاج حاويات، وبيئات معزولة، وقيودًا على نظام الملفات والشبكة والمعالج والذاكرة |
ومن أمثلة الممارسة الثالثة أن OpenAI تدعم، في تكامل MCP داخل Responses API، نمط موافقة لطلبات الأدوات الحساسة بدل السماح بكل الأدوات دون مراجعة. أما في الممارسة الأخيرة، فإن Sandboxing ليس شيئًا يفعله MCP تلقائيًا؛ بل يجب أن يوفر التطبيق والخادم هذه الحدود.
كيف تعمل المصادقة في MCP؟
في MCP البعيد عبر HTTP يمكن أن يدخل OAuth في عملية الوصول. والفكرة العامة أن خادم MCP يمثل خادم موارد (Resource Server)، فيكتشف العميل متطلبات التفويض، ويحصل المستخدم أو التطبيق على رمز (Token) من خادم تفويض مناسب، فيتحقق الخادم منه، وتُقيَّد الصلاحيات بالنطاقات (Scopes) والهوية. وقد عزز إصدار 2026 متطلبات التفويض، ومنها التحقق من الجهة المُصدِرة، ومنع إعادة استخدام الاعتمادات عبر خوادم التفويض بطريقة غير صحيحة. والمبدأ المهم للمطور:
Authentication تجيب "من أنت؟"، أما Authorization فتجيب "ما الذي يسمح لك بفعله؟".
فنجاح تسجيل الدخول لا يعني أن الأداة يجب أن تحصل على كل الصلاحيات.
منظومة التبني: من يستخدم MCP اليوم؟
هل MCP مخصص لـClaude فقط؟
لا. فرغم أن Anthropic قدمت MCP أصلًا عام 2024، أصبح البروتوكول معيارًا أوسع بكثير، خصوصًا بعد التبرع به في ديسمبر 2025 إلى Agentic AI Foundation تحت Linux Foundation. ومن أمثلة استخدامه الحالية Claude وClaude Desktop/Code، وOpenAI API ومنتجات تدعم MCP، وGoogle Antigravity، وVisual Studio Code ومحررات ووكلاء آخرون، وDify، وتطبيقات مؤسسية ومخصصة. ولهذا لا يصح وصف MCP اليوم بأنه "بروتوكول Claude".
كيف تستخدم OpenAI بروتوكول MCP؟
تدعم OpenAI استخدام MCP ضمن Responses API عبر أداة من النوع mcp. فيستطيع التطبيق ربط خادم MCP بعيد عبر عنوانه (Server URL)، كما توجد آليات للاتصال بخوادم خاصة أو خلف جدار حماية عبر Secure MCP Tunnel في المنتجات المدعومة. ويمكن تحديد الخادم، والأدوات المسموح بها، والتفويض، وسياسة الموافقة. وهذا مثال واضح على قيمة البروتوكول: الخادم نفسه يمكن أن تستهلكه بيئات ذكاء اصطناعي مختلفة ما دامت تدعم MCP، بدل بناء موصّل خاص لكل مزود.
كيف يستخدم Claude بروتوكول MCP؟
كان Claude Desktop من أوائل البيئات الداعمة لـMCP، ثم تطورت التجربة مع Desktop Extensions / MCP Bundles لتسهيل تثبيت الخوادم المحلية بدل مطالبة المستخدم بتعديل ملفات الإعداد يدويًا في كل مرة. كما يدعم نظام Anthropic وواجهتها البرمجية الاتصال بخوادم MCP في سيناريوهات مختلفة.
والقيمة هنا ليست "ذاكرة سحرية" داخل Claude، بل أن MCP يسمح بربطه بخدمات خارجية قد توفر الملفات والبحث وقواعد البيانات والأدوات ومخازن الذاكرة؛ فالذاكرة نفسها تأتي من النظام الخارجي، لا من MCP بوصفه قاعدة بيانات.
ماذا عن Google Antigravity؟
توثق Google دعم MCP Servers محلية وبعيدة داخل Antigravity، فيستطيع المطور ربط بيئة الوكيل بخوادم Google/Google Cloud أو خوادم أخرى، واستخدام MCP لتوفير أدوات وسياق خارجي. وهذا مثال أوضح من الادعاء بأن "MCP رفع دقة Antigravity بنسبة معينة"؛ فالدعم موثق، أما مقدار تحسن الدقة أو الإنتاجية فيحتاج دراسة قياس مستقلة.
ماذا عن Dify؟
أضافت Dify دعم MCP تدريجيًا، ثم قدمت دعمًا أصليًا في اتجاهين: استخدام خوادم MCP أدوات داخل الوكلاء وسير العمل، وعرض تطبيقات Dify أو سير عملها خادمَ MCP تستهلكه عملاء خارجيون. فتصبح Dify مثالًا جيدًا على عمل البروتوكول في الاتجاهين: مرة تكون Dify عميلًا يصل عبر MCP إلى خادم خارجي، ومرة يصل عميل خارجي عبر MCP إلى تطبيق أو سير عمل في Dify. لكن يجب دائمًا التحقق من Protocol Version التي يدعمها إصدار Dify المحدد، لأن MCP نفسه يتغير بسرعة.
متى تحتاج MCP فعلًا؟
| يكون MCP مفيدًا حين | قد يكون التكامل المباشر أبسط حين |
|---|---|
| تملك عدة أدوات ومصادر بيانات | تملك أداة واحدة فقط |
| تريد دعم أكثر من AI Host | يكون التطبيق صغيرًا وثابتًا |
| تريد فصل منطق التكامل عن التطبيق | لا تحتاج قابلية التشغيل البيني |
| تبني منظومة أدوات قابلة لإعادة الاستخدام | تملك الخدمة الخارجية SDK مباشرًا ممتازًا |
| تحتاج اكتشاف الأدوات | لا يوجد احتمال لإعادة استخدام الموصّل |
| تريد تبديل النموذج دون إعادة بناء كل موصّل | سيضيف MCP طبقة تشغيل بلا قيمة واضحة |
| تريد نشر خدمة ذكاء اصطناعي تستخدمها عدة عملاء |
فالمعيار الجيد لا يعني وجوب استخدامه في كل مشروع.
ومشروع تطبيق دليل الطالب الجامعي الرقمي مثال على العمود الأيسر: فمساعده الافتراضي يستدعي Google Gemini مباشرة لمطابقة السؤال مع قاعدة أسئلة شائعة ثابتة، أي مصدر بيانات واحد لا يحتاج طبقة MCP. وفي تنفيذنا الفعلي لهذا التطبيق كان الربط المباشر بالنموذج كافيًا لهذا النطاق المحدود؛ فقيمة MCP تظهر حين تتعدد الأدوات ومصادر البيانات التي يجب أن يصل إليها المساعد.
مثال معماري لمشروع داخل شركة
لنفترض أن مؤسسة تريد مساعدًا يستطيع البحث في الوثائق، وقراءة نظام CRM، وإنشاء تذكرة دعم، وتشغيل تقرير مبيعات.
يمكن بناء هذا المساعد بمعمارية MCP متعددة الخوادم: يضم المساعد بين مكوناته MCP Client واحدًا أو أكثر، ويتصل كل عميل بـMCP Server مخصص لجزء واحد من المنظومة: خادم للوثائق يتيح البحث والقراءة، وآخر للـCRM يعرض بيانات العملاء، وثالث لنظام الدعم يتيح فتح التذاكر، ورابع للتحليلات يشغّل تقارير المبيعات. وحين يطلب المستخدم «افتح تذكرة للعميل فلان وضع تقرير مبيعاته»، يكتشف المساعد عبر البروتوكول أي خادم يملك الأدوات اللازمة، فيستدعي أداة التذاكر من خادم الدعم وأداة التقارير من خادم التحليلات، ويجمع النتائج في إجابة واحدة.
وتظهر القيمة الحقيقية لهذا الفصل في الحوكمة: إذ يمكن لكل خادم أن يملك آلية Authentication تناسب حساسية خدمته، وScopes مضبوطة تمنح أقل صلاحية ممكنة، وLogging مستقلًا يسهّل تتبع من فعل ماذا ومتى، وRate Limits تحمي الأنظمة الخلفية من الاستخدام الجائر، إضافة إلى فريق مسؤول واضح عن تشغيله وتطويره.
وهذا التنظيم أفضل هندسيًا من منح نموذج واحد اعتمادات موحدة تصل مباشرة إلى جميع الأنظمة، لأن أي اختراق أو خطأ يبقى محصورًا في نطاق خادم واحد بدل أن يمتد إلى المنظومة كلها.
كيف تصمم أداة MCP جيدة؟
محددة
الأداة get_invoice(invoice_id) أفضل من do_accounting_task(text)؛ فكلما كانت الوظيفة أوضح، أصبح التحقق منها وضبط صلاحياتها أسهل.
ذات مخطط دقيق
حدد الأنواع، والحقول المطلوبة، والقيم المعدودة (Enum) حين يمكن، وحدود القيم، وبنية المخرجات.
بوصف واضح وغير تسويقي
يجب أن يعرف النموذج من الوصف ماذا تفعل الأداة، وماذا لا تفعل، ومتى تُستخدم، وما آثارها الجانبية.
متكررة الأثر (Idempotent) حين يمكن
إعادة قراءة ملف آمنة عادة، أما عملية مثل "Send Payment" فتحتاج تصميمًا أكثر حذرًا لمنع التكرار غير المقصود.
تفصل المعاينة عن التنفيذ
في العمليات الحساسة، قد يكون الفصل بين أداة للمعاينة مثل preview_refund() وأخرى للتنفيذ مثل execute_refund() أفضل من أداة واحدة تنفذ مباشرة.
أخطاء تصميم MCP الشائعة
| الخطأ | لماذا هو خطر |
|---|---|
| خادم واحد بكل الصلاحيات | يتحول إلى نقطة خطر كبيرة |
أداة عامة جدًا مثل run_any_sql(query) دون قيود |
الأفضل في كثير من الأنظمة عرض عمليات أضيق أو طبقة استعلام للقراءة فقط |
| تمرير الأسرار داخل السياق | النموذج لا يحتاج رؤية مفتاح API كي يستخدم الأداة |
| الثقة في بيانات الأدوات الخارجية | المحتوى الخارجي قد يكون خبيثًا |
| غياب الموافقة | خصوصًا في العمليات التي تغيّر العالم الخارجي |
| الخلط بين أمن البروتوكول وأمن التطبيق | وجود OAuth لا يحميك من أداة منطقها سيئ |
| الاعتماد على درس تعليمي قديم | MCP تطور بسرعة، خصوصًا في النقل ودورة البروتوكول في 2026 |
ما الذي يجب مراقبته في الفترة المقبلة؟
تشير خارطة الطريق المنشورة في أغسطس 2026 إلى استمرار التركيز على قابلية التوسع، والجاهزية المؤسسية (Enterprise readiness)، والتواصل بين الوكلاء، والحوكمة، والامتدادات، وتحسينات التفويض، والتشغيل الأنضج على البنية التحتية المؤسسية. ولذلك يجب اعتبار أي مقال تقني عن MCP محتوى يحتاج تحديثًا دوريًا؛ فالبروتوكول ما يزال يتطور بسرعة تفوق تقنيات شبكية ناضجة مثل HTTP أو SMTP.
الخلاصة
لا يجعل Model Context Protocol النموذج أذكى بحد ذاته، ولا يستبدل واجهات APIs، ولا يبني وكيلًا كاملًا. فقيمته الأساسية توحيد طريقة ربط تطبيقات الذكاء الاصطناعي بالأدوات والبيانات الخارجية.
ويمكن فهم المنظومة من توزيع الأدوار فيها: النموذج اللغوي يفهم السياق ويولّد الإجابة ويقرر متى تحتاج مهمته قدرة خارجية؛ وبروتوكول MCP يوفر لغة الاتصال المعيارية التي يصل بها النموذج إلى تلك القدرة؛ وMCP Server يعرّف القدرات الخارجية وينفذها فعليًا خلف واجهة موحدة؛ بينما يتولى المضيف تنسيق المشهد كله، من إدارة النموذج والصلاحيات إلى تجربة المستخدم والسياق المشترك. ويولّد النموذج اللغوي طلب استدعاء الأداة خطوة بخطوة اعتمادًا على آلية التنبؤ بالرمز التالي في النماذج اللغوية.
وأهم ما تغير في 2026 أن MCP لم يعد تجربة ناشئة من شركة واحدة، بل معيارًا واسع التبني انتقل إلى حوكمة مستقلة، وتطورت مواصفته نحو Streamable HTTP أكثر قابلية للتوسع ونواة عديمة الحالة على مستوى البروتوكول، مع تحسينات كبيرة في التفويض والامتدادات.
لكن المعيارية ليست مرادفًا للأمان. فنجاح MCP في بيئة إنتاجية يعتمد على أقل الصلاحيات، والمصادقة والتفويض، والموافقات البشرية، والتحقق من المدخلات، والعزل، وقابلية التدقيق، والثقة في الخوادم، وإدارة الإصدارات، وعدم منح النموذج أكثر مما يحتاج إليه.
المصادر والمراجع
Anthropic — Introducing the Model Context Protocol, Nov 25, 2024
https://www.anthropic.com/news/model-context-protocolAnthropic — Donating MCP to the Agentic AI Foundation, Dec 9, 2025
https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundationModel Context Protocol — 2026-07-28 Specification release
https://blog.modelcontextprotocol.io/posts/2026-07-28/Model Context Protocol — 2026 Roadmap update, Aug 22, 2026
https://blog.modelcontextprotocol.io/posts/mcp-roadmap/MCP TypeScript SDK v2 — current 2026 specification implementation
https://ts.sdk.modelcontextprotocol.io/v2/OpenAI — MCP servers with the Responses API
https://developers.openai.com/api/docs/guides/tools-connectors-mcpOpenAI — Secure MCP Tunnel
https://developers.openai.com/api/docs/guides/secure-mcp-tunnelsGoogle Cloud — Configure MCP in an AI application
https://docs.cloud.google.com/mcp/configure-mcp-ai-applicationGoogle Developers — Developer Knowledge MCP server / Antigravity integration
https://developers.google.com/knowledge/mcpGoogle Codelabs — Antigravity MCP Servers
https://codelabs.developers.google.com/getting-started-google-antigravityAnthropic — Claude Desktop Extensions / MCP Bundles
https://www.anthropic.com/engineering/desktop-extensionsDify — Built-in two-way MCP support
https://dify.ai/blog/v1-6-0-built-in-two-way-mcp-support
وثائق رسمية ومعايير إضافية
الأسئلة الشائعة حول المقال
ما هو MCP باختصار؟
MCP هو معيار مفتوح يسمح لتطبيقات الذكاء الاصطناعي بالاتصال بخوادم تعرض أدوات وبيانات وموارد بطريقة موحدة بدل كتابة تكامل مخصص لكل نظام.
هل MCP خاص بـClaude؟
لا. Anthropic أطلقته في 2024، لكنه أصبح معيارًا مفتوحًا متعدد الشركات وتم التبرع به إلى Agentic AI Foundation تحت Linux Foundation في 2025.
هل MCP بديل عن REST API؟
لا. غالبًا يستخدم MCP Server الـREST API نفسها خلف الكواليس. MCP يوفر واجهة معيارية موجهة إلى تطبيقات AI فوق الخدمات الموجودة.
ما الفرق بين MCP وFunction Calling؟
Function Calling تسمح للنموذج بطلب استدعاء دالة، بينما MCP ينظم اكتشاف وربط واستخدام أدوات وموارد خارجية من Server مستقل. ويمكن استخدام الاثنين معًا.
ما الفرق بين MCP وRAG؟
RAG تقنية لاسترجاع معلومات وإضافتها إلى سياق النموذج. MCP بروتوكول اتصال يمكن أن يعرض أداة RAG أو أدوات تنفيذية وأنواعًا أخرى من الموارد.
ما هي طرق النقل الحديثة في MCP؟
يستخدم MCP stdio للخوادم المحلية وStreamable HTTP للخوادم الشبكية. النقل القديم HTTP+SSE أصبح Deprecated في مواصفة 2026.
هل MCP آمن تلقائيًا؟
لا. يجب تطبيق Least Privilege والمصادقة والتفويض والموافقات والتحقق من المدخلات وعزل التنفيذ وحماية الأسرار. البروتوكول وحده لا يمنع Prompt Injection أو Tool misuse.
هل OpenAI يدعم MCP؟
نعم. تدعم OpenAI خوادم MCP ضمن Responses API، مع خيارات للاتصال بالخوادم البعيدة، وتحديد الأدوات، وAuthorization وسياسات Approval، إضافة إلى Secure MCP Tunnel لبعض سيناريوهات الخوادم الخاصة.
هل Google يدعم MCP؟
نعم. توثق Google استخدام MCP Servers مع Antigravity وخدمات Google Cloud، بما في ذلك خوادم محلية وبعيدة.
هل يجب استخدام MCP في كل مشروع AI؟
لا. إذا كان لديك تكامل واحد بسيط وثابت فقد تكون API مباشرة أبسط. MCP يصبح أكثر قيمة عندما تحتاج عدة أدوات، أو عدة AI Hosts، أو قابلية إعادة استخدام وتوسع.
النقاش الهندسي والملاحظات (0)
سجّل الدخول للمشاركة في النقاش والرد على التعليقات والإعجاب بها.
