ما هو خادم MCP، وما ليس هو

ربط نموذج لغوي بنظام مؤسسي ليس مسألة نموذج. بل مسألة تكامل. ووُجد Model Context Protocol (MCP) ليوحّد تلك الطبقة بالذات. وتتعامل هذه الملاحظة مع MCP بوصفه بروتوكولاً لا منتجاً: ما الذي يحدده، وما الذي يمتنع عن تحديده عمداً، وأي صندوق يشغله في معمارية مؤسسية. وكل ادعاء تقني أدناه مستند إلى المواصفة الرسمية. وتستخدم مراجعات المواصفة معرّفاً بصيغة YYYY-MM-DD ولا تُزاد إلا حين يقع تغيير كاسر للتوافق مع السابق. وتستند هذه الملاحظة إلى مراجعة 2025-11-25. أما مراجعة 2026-07-28، المقررة في 28 يوليو 2026، فتجعل البروتوكول عديم الحالة، وتزيل مصافحة initialize ومعرّف الجلسة، وتنقل Tasks خارج النواة إلى امتداد منفصل، وتضع Roots وSampling وLogging في عداد المهجور بنافذة إزالة مدتها اثنا عشر شهراً. وتفاصيل الجلسة والبدائيات أدناه تتغير في تلك المراجعة.

قبل البروتوكول: جسر لكل ثنائي

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

أُعلن MCP وفُتح مصدره من Anthropic في 25 نوفمبر 2024، وأنشأه David Soria Parra وJustin Spahr-Summers. وصدر الإطلاق الأول في ثلاثة أجزاء: المواصفة وحزم SDK، ودعم خوادم MCP المحلية في تطبيقات Claude Desktop، ومستودع مفتوح المصدر لخوادم جاهزة لأنظمة مثل Google Drive وSlack وGitHub وPostgres وPuppeteer.

وفي 9 ديسمبر 2025، تبرّعت Anthropic بـ MCP إلى Agentic AI Foundation (AAIF)، وهو صندوق موجّه تحت Linux Foundation. وشارك في تأسيسه Anthropic وBlock وOpenAI، بدعم من Google وMicrosoft وAWS وCloudflare وBloomberg. وMCP مشروع مؤسِّس إلى جانب goose وAGENTS.md. وانتقلت بنية الصيانة كما هي: يتولى مجلس الحوكمة الميزانية والعضوية واعتماد المشاريع الجديدة، بينما تحتفظ المشاريع الفردية باستقلال تام في التوجيه التقني. ولذلك فوصف MCP اليوم بأنه ببساطة بروتوكول Anthropic وصف ناقص. والصياغة الدقيقة: نشأ وفُتح مصدره من Anthropic، ومنذ ديسمبر 2025 يُحكَم ضمن AAIF داخل Linux Foundation. وتُدرج الوثائق الرسمية Claude وChatGPT وVisual Studio Code وCursor وMCPJam بين العملاء الذين يدعمونه.

المعمارية: مضيف، وعميل، وخادم

يتبع MCP معمارية عميل-خادم ويعرّف ثلاثة أدوار متمايزة. فمضيف MCP هو تطبيق الذكاء الاصطناعي الذي ينسّق عميلاً واحداً أو أكثر من عملاء MCP — مثل Claude Code أو VS Code. وعميل MCP هو المكوّن الذي يُبقي اتصالاً بخادم واحد ويحصل على السياق نيابة عن المضيف. وخادم MCP برنامج يوفّر السياق لعملاء MCP. والتفصيل المهم تشغيلياً: يُنشئ المضيف كائن عميل منفصلاً لكل خادم، ويحمل كل عميل اتصالاً مخصصاً بخادمه هو. والخوادم لا يرى بعضها بعضاً.

ولا يقول مصطلح خادم MCP شيئاً عن مكان تشغيل الكود؛ فقد يكون محلياً أو بعيداً. وعملياً، تخدم الخوادم المحلية عبر stdio عميلاً واحداً عادةً، بينما تخدم الخوادم البعيدة عبر Streamable HTTP عملاء كثيرين. وينقسم البروتوكول إلى طبقتين: طبقة بيانات (مراسلة JSON-RPC 2.0، ودورة الحياة، والبدائيات، والإشعارات) وطبقة نقل (إقامة الاتصال، وتأطير الرسائل، والتخويل). وMCP بروتوكول ذو حالة. وتُفتح الجلسة بـ initialize، حيث تُتفاوض القدرات، ويجب أن يتفق العميل والخادم على إصدار واحد من البروتوكول.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": { "name": "example-host", "version": "1.0.0" }
  }
}

تعرّف المواصفة وسيلتَي نقل قياسيتين: stdio وStreamable HTTP. وينبغي للعملاء دعم stdio كلما أمكن، ووسائل النقل المخصصة مسموحة ما دامت تحفظ صيغة رسائل JSON-RPC ومتطلبات دورة الحياة. ويعرض Streamable HTTP مسار نقطة MCP واحدة يدعم POST وGET معاً؛ وللخادم أن يبثّ الاستجابات اختيارياً عبر SSE. أما وسيلة النقل الأقدم HTTP+SSE من مراجعة 2024-11-05 فحلّ محلها Streamable HTTP وصارت مهجورة. وعبر HTTP، يجب أن يرسل العملاء ترويسة MCP-Protocol-Version في كل الطلبات التالية لـ initialize، وينبغي أن تكون القيمة المرسلة هي الإصدار المتفاوَض عليه أثناء initialize؛ والخادم الذي لا يستقبل ترويسة يفترض 2025-03-26. وللخادم أن يصدر MCP-Session-Id عند التهيئة ويتوقعه في الطلبات اللاحقة.

تنص المواصفة صراحة على أن MCP يستلهم شيئاً من Language Server Protocol. والتشبيه يصمد: فـ LSP وحّد الحدّ بين المحرّر واللغة؛ وMCP يوحّد الحدّ بين تطبيق الذكاء الاصطناعي والنظام الخارجي.

ما الذي يعرضه الخادم فعلاً

تعرض الخوادم قدرتها عبر ثلاث بدائيات أساسية. وما يفصل بينها ليس ما تفعله، بل من يتحكم بها:

• Tools — دوال يستطيع النموذج استدعاءها لاتخاذ إجراء: الكتابة في قاعدة بيانات، أو استدعاء واجهة خارجية، أو تعديل الملفات. يتحكم بها النموذج. والطرق: tools/list وtools/call.
• Resources — مصادر بيانات ساكنة للقراءة فقط تزوّد بالسياق: محتويات الملفات، ومخططات قواعد البيانات، واستجابات الواجهات. يتحكم بها التطبيق. والطرق: resources/list وresources/templates/list وresources/read وresources/subscribe.
• Prompts — قوالب تفاعل قابلة لإعادة الاستخدام وذات معاملات. يتحكم بها المستخدم؛ وتتوقع المواصفة استدعاءها صراحة. والطرق: prompts/list وprompts/get.

وتُعلَن مدخلات الأدوات بـ JSON Schema. وهذا يتيح لكاتب الخادم أن يثق بالمخطط بدل النموذج: فالاستدعاء الوارد يُتحقَّق منه أمام المخطط قبل أن يبلغ أي منطق أعمال.

{
  "name": "get_order_status",
  "title": "Get order status",
  "description": "Returns the current status of a given order number.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderNumber": { "type": "string", "pattern": "^[A-Z]{2}-[0-9]{6}$" },
      "verbose": { "type": "boolean", "default": false }
    },
    "required": ["orderNumber"]
  }
}

وعلى جانب الموارد، يحمل كل مورد عنوان URI فريداً ويعلن نوع MIME. وإلى جانب عناوين URI الثابتة، تستطيع الخوادم نشر Resource Templates ذات معاملات — قالب يأخذ مدينة وتاريخاً مثلاً. والتدفّق ليس أحادي الاتجاه: فالعملاء يعرضون بدائيات للخوادم أيضاً. فـ Sampling يتيح للخادم طلب إكمال من نموذج المضيف (sampling/createMessage). وElicitation يتيح للخادم سؤال المستخدم مدخلاً إضافياً أو تأكيداً (elicitation/create). وRoots يتيح للخادم الاستعلام عن حدّ نظام الملفات الممنوح له. وLogging يكمل الصورة. أما بدائية Tasks للعمليات طويلة الأمد فموسومة بأنها تجريبية في المراجعة الحالية، ولذلك لا ينبغي التعامل معها كمسلّمة ثابتة في خطة نشر. وتستطيع الخوادم التي تتغير قدراتها إصدار إشعارات مثل notifications/tools/list_changed — لكن فقط إن أعلنت listChanged أثناء initialize.

أين يقع التخويل فعلاً

هذا هو الجزء الذي يحتاج أكبر قدر من التوضيح. ففي MCP، يُعرَّف التخويل على مستوى النقل وهو اختياري. وينبغي لوسائل النقل القائمة على HTTP أن تتوافق مع مواصفة التخويل؛ أما وسائل نقل STDIO فلا ينبغي أن تتبعها، بل تجلب بيانات الاعتماد من البيئة بدلاً من ذلك. والبحث عن مسار OAuth داخل خادم stdio محلي بحث في غير طبقته.

وعبر HTTP تكون الأدوار قاطعة. فخادم MCP المحمي يعمل بوصفه resource server وفق OAuth 2.1. وعميل MCP يعمل بوصفه عميل OAuth 2.1. وخادم التخويل طرف منفصل — قد يُستضاف بجوار خادم الموارد أو يعمل مستقلاً تماماً. وذلك الفصل هو ما يؤسس القول بأن خادم MCP حدّ تخويل: فالخادم لا يصكّ الرموز، بل يتحقق منها ويقيّد الوصول تبعاً لذلك. والمعايير التي يذكر هذا القسم التوافق معها هي مسودة OAuth 2.1، وRFC 8414، وRFC 7591، وRFC 9728، ومسودة OAuth Client ID Metadata Documents. وبشكل منفصل، تشترط الوثيقة نفسها RFC 8707 لمعامل resource.

والمتطلبات التي تترجم مباشرة إلى قرارات نشر:

• يجب على خوادم MCP تنفيذ RFC 9728 (Protected Resource Metadata)، ويجب على العملاء استخدامه لاكتشاف خادم التخويل.
• يجب على العملاء تنفيذ PKCE واستخدام طريقة التحدي S256 متى أمكن تقنياً؛ وإن تعذّر التحقق من دعم PKCE من حقل code_challenge_methods_supported في بيانات خادم التخويل، وجب على العميل الامتناع عن المتابعة.
• يجب على الخوادم التحقق من أن رموز الوصول صدرت لها هي تحديداً بوصفها الجمهور المقصود، ويجب أن ترفض الرموز التي لا تسمّيها.
• وعند استدعاء واجهة أعلى المسار، يعمل خادم MCP بوصفه عميل OAuth قائماً بذاته ويجب ألا يمرّر الرمز الذي استلمه من عميل MCP. فتمرير الرمز نمط ممنوع صراحة.
• يجب ألا تظهر الرموز في سلسلة استعلام URI؛ فكل طلب HTTP يحمل ترويسة Authorization: Bearer، حتى داخل الجلسة المنطقية نفسها.
• ومعرّفات الجلسة ليست آلية توثيق: يجب ألا تستخدم الخوادم الجلسات للتوثيق.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="orders:read orders:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="Write permission required"

ورموز الحالة محددة كذلك: 401 عند لزوم التخويل أو عند رمز غير صالح، و403 عند نطاق غير كافٍ، و400 عند طلب معطوب البنية. وعند 403 يعلن الخادم النطاقات اللازمة في ترويسة WWW-Authenticate، ويستطيع العميل تشغيل مسار تخويل تصعيدي. وتقليص النطاق موصى به رسمياً، وأسماء النطاقات الجامعة مثل * أو all أو full-access مدرجة ضمن المآخذ الشائعة في التنفيذ.

ما ليس MCP

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

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

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

وMCP لا يحلّ محل بوابة الواجهات. فخادم MCP ليس ممرّاً شفافاً أمام الواجهات أعلى المسار. ورمز الوصول المستخدم أعلى المسار رمز منفصل يصدره خادم التخويل هناك، ويجب على الخادم ألا يمرّر الرمز الذي استلمه. فالخادم يحمل هويته الخاصة وحدّ تخويله الخاص. أما تحديد المعدل، والحصص، وترجمة البروتوكولات، والتوجيه عند الحافة فتبقى شؤون البوابة.

والتشبيه الرسمي جيد: تصوّروا MCP منفذ USB-C لتطبيقات الذكاء الاصطناعي. فالمنفذ لا يحدد ما في الطرف الآخر من الكابل، ولا ما يفعله الجهاز الموصول بالاتصال.

أين يقع الخادم في نشر داخل مقر الشركة

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

ومتطلبات الأمان في المواصفة تجعل الاستضافة داخل المقر خياراً طبيعياً. فالخوادم العاملة محلياً ينبغي أن ترتبط بـ 127.0.0.1 وحده لا بكل الواجهات. والخوادم التي تستخدم Streamable HTTP يجب أن تتحقق من ترويسة Origin وتعيد 403 عند قيمة غير صالحة، وهو الدفاع أمام إعادة ربط DNS. والتوثيق موصى به لكل الاتصالات. والخادم المحلي عملية تنفّذ كوداً على الجهاز المضيف: وتوصي المواصفة بأن يشغّل العميل تلك العملية في صندوق رملي بأدنى صلاحيات افتراضية، وبأن يقصر الخادم العامل محلياً الوصول على stdio أو قناة IPC مقيّدة مثل unix domain socket. وعملاء MCP الذين يجلبون عناوين اكتشاف OAuth ينبغي أن يحجبوا الطلبات إلى نطاقات IP الخاصة والمحجوزة، وعمليات نشر عميل MCP على جانب الخادم ينبغي أن تنظر في وسيط خروج — وهو الجزء الذي يغطي تزوير الطلب من جانب الخادم، حيث يوجّه خادمٌ عميلاً إلى عناوين شبكة داخلية. والخوادم الوسيطة التي تستخدم معرّفات عميل ثابتة يجب أن تحصل على موافقة المستخدم لكل عميل مسجّل ديناميكياً — وهي القاعدة التي تغلق حالة النائب المُضلَّل. وعزل جمهور الرمز يقول الشيء نفسه بمفردات أخرى: الخادم هو الحدّ.

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

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

المصادر

• Model Context Protocol — specification, 2025-11-25 revision
• MCP specification — Authorization section (OAuth 2.1 roles, RFC 9728, error codes)
• MCP specification — Versioning and feature lifecycle
• MCP Blog — The 2026-07-28 MCP Specification Release Candidate
• MCP Blog — MCP joins the Agentic AI Foundation (9 December 2025)
• Anthropic — Introducing the Model Context Protocol (25 November 2024)