الدرس 01: ما هو MCP ولماذا ظهر؟ مشكلة N×M ومنفذ USB-C للذكاء الاصطناعي

الدرس 01 من دورة MCP بالعربي. هذا هو الدرس الأول، فلا يوجد درس سابق، وكل ما تحتاجه هو فضول المتعلم وكوب من القهوة.

يتبع هذا الدرس إصدار المواصفة 2026-07-28، وهو أحدث إصدار منشور على الموقع الرسمي modelcontextprotocol.io وقت كتابة الدرس.

ماذا ستتعلم في هذا الدرس

• ما هو بروتوكول سياق النموذج (Model Context Protocol) أو MCP اختصارًا، وما المشكلة التي جاء ليحلها.
• لماذا يسمى الربط بين النماذج والأدوات "مشكلة N×M"، وكيف يحولها MCP إلى "N+M".
• معنى التشبيه الرسمي: "MCP منفذ USB-C لتطبيقات الذكاء الاصطناعي".
• لمحة أولى عن الأطراف الثلاثة: المضيف (Host) والعميل (Client) والخادم (Server)، وعما يقدمه الخادم.
• كيف تشاهد خادم MCP حقيقيًا يعمل على جهازك في دقائق، دون أن تكتب سطرًا واحدًا من الكود.

ما هو MCP بكلمات بسيطة؟

تقول الوثائق الرسمية إن MCP معيار مفتوح المصدر لربط تطبيقات الذكاء الاصطناعي بالأنظمة الخارجية. بهذا المعيار تستطيع تطبيقات مثل Claude أو ChatGPT أن تتصل بمصادر البيانات (ملفاتك المحلية، قواعد البيانات)، وبالأدوات (محركات البحث، الآلات الحاسبة)، وبسير العمل (قوالب تعليمات جاهزة)، فتصل إلى المعلومة التي تحتاجها وتنفذ مهام حقيقية.

لنفهم ذلك من زاوية النموذج نفسه. النموذج اللغوي الكبير (LLM) ذكي في الاستنتاج والكتابة، لكنه وحده محبوس داخل ما تعلمه أثناء التدريب. لا يعرف ما في بريدك هذا الصباح، ولا يرى جدول المبيعات في قاعدة بيانات شركتك، ولا يستطيع أن يفتح تذكرة في نظام الدعم الفني. يحتاج إلى "أيدٍ" و"عيون" تمتد إلى العالم الخارجي.

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

كلمة "السياق" (Context) في اسم البروتوكول مقصودة. السياق هو كل ما يوضع أمام النموذج ليفهم المهمة: محتوى ملف، نتيجة استعلام، وصف أداة يمكنه استدعاؤها. وMCP يحدد طريقة موحدة لإيصال هذا السياق إلى التطبيق، دون أن يفرض على التطبيق كيف يستخدمه أو أي نموذج يشغله. تقول الوثائق صراحة إن MCP يركز فقط على بروتوكول تبادل السياق، ولا يحدد كيف تستخدم التطبيقات النماذج اللغوية أو كيف تدير السياق المقدم لها.

لماذا ظهر MCP؟ ما هي مشكلة N×M؟

في 25 نوفمبر 2024 أعلنت Anthropic فتح مصدر MCP، وشرحت المشكلة في إعلانها بوضوح: حتى أذكى النماذج مقيدة بعزلتها عن البيانات، محبوسة خلف "جزر معلومات" وأنظمة قديمة، وكل مصدر بيانات جديد يحتاج إلى تكامل مخصص خاص به، وهذا يجعل بناء أنظمة متصلة فعلًا أمرًا صعب التوسع.

تخيل الآن أن لديك ثلاثة تطبيقات ذكاء اصطناعي (مساعد محادثة، محرر أكواد، روبوت دعم داخلي)، وأربعة أنظمة تريد ربطها بها (GitHub، قاعدة بيانات Postgres، Google Drive، Slack). بدون معيار مشترك، كل تطبيق يحتاج إلى كود ربط خاص بكل نظام:

بدون MCP        │ GitHub   │ Postgres │ Drive    │ Slack
────────────────┼──────────┼──────────┼──────────┼─────────
مساعد المحادثة  │ ربط خاص  │ ربط خاص  │ ربط خاص  │ ربط خاص
محرر الأكواد    │ ربط خاص  │ ربط خاص  │ ربط خاص  │ ربط خاص
روبوت الدعم     │ ربط خاص  │ ربط خاص  │ ربط خاص  │ ربط خاص

هذه 3 × 4 = 12 عملية ربط مختلفة، كل واحدة منها تحتاج إلى كتابة وصيانة واختبار. إذا كان عدد التطبيقات N وعدد الأنظمة M، فعدد عمليات الربط هو N×M. أضف تطبيقًا خامسًا، وستكتب أربع عمليات ربط جديدة. أضف نظامًا جديدًا، وستكتب ربطًا له في كل تطبيق. وعندما يغير أحد الأنظمة واجهته البرمجية، تنكسر عدة عمليات ربط في أماكن متفرقة.

مع MCP يتغير الحساب. كل تطبيق يتعلم "لغة MCP" مرة واحدة، فيصبح عميلًا (Client). وكل نظام يقدم نفسه بلغة MCP مرة واحدة عبر خادم (Server). بعدها يستطيع أي تطبيق يتحدث MCP أن يتصل بأي خادم MCP:

بدون MCP: كل تطبيق مربوط بكل نظام (N × M)

  مساعد المحادثة ──┬── GitHub
                   ├── Postgres
                   ├── Drive
                   └── Slack
  محرر الأكواد ────┬── GitHub
                   ├── ... (وهكذا لكل تطبيق)

مع MCP: كل طرف يتعلم البروتوكول مرة واحدة (N + M)

  مساعد المحادثة ─┐                  ┌─ خادم GitHub
  محرر الأكواد ────┼──── بروتوكول MCP ─┼─ خادم Postgres
  روبوت الدعم ─────┘                  ├─ خادم Drive
                                      └─ خادم Slack

في مثالنا تصبح العملية 3 + 4 = 7 تطبيقات للبروتوكول بدل 12 ربطًا مخصصًا. الفرق يبدو صغيرًا هنا، لكن تخيل 20 تطبيقًا و200 نظام: 4000 ربط مقابل 220. هذا هو جوهر الفكرة. تقول Anthropic في إعلانها إن MCP يقدم معيارًا عالميًا مفتوحًا "يستبدل التكاملات المجزأة ببروتوكول واحد"، وإن المطورين بدل صيانة موصلات منفصلة لكل مصدر بيانات صار بإمكانهم البناء على بروتوكول قياسي.

هل هذه الفكرة جديدة؟

ليست جديدة تمامًا، وهذا مطمئن. تذكر المواصفة الرسمية أن MCP استلهم جزءًا من فكرته من بروتوكول خادم اللغة (Language Server Protocol) أو LSP. قبل LSP كان كل محرر أكواد يكتب دعمًا خاصًا لكل لغة برمجة. بعده صار يكفي أن تكتب "خادم لغة" واحدًا للغة Python مثلًا، فتستفيد منه كل المحررات التي تدعم LSP. MCP يطبق الفكرة نفسها على عالم تطبيقات الذكاء الاصطناعي: بدل توحيد دعم لغات البرمجة، يوحد طريقة إضافة السياق والأدوات.

ما معنى أن MCP "منفذ USB-C للذكاء الاصطناعي"؟

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

تذكر الدرج الذي كان في كل بيت، مليئًا بالشواحن: شاحن للهاتف القديم، وآخر للكاميرا، وثالث لسماعة الأذن، وكل جهاز له منفذ مختلف. إذا سافرت ونسيت شاحنًا واحدًا، تعطل جهاز كامل. ثم جاء منفذ موحد، فصار شاحن واحد يشحن الهاتف والحاسوب والسماعة، وصار بإمكان أي شركة أن تصنع ملحقًا جديدًا وهي مطمئنة أنه سيعمل مع آلاف الأجهزة التي لم ترها.

طبق هذه الصورة على عالمنا:

• الحاسوب أو الهاتف يقابله تطبيق الذكاء الاصطناعي، أي المضيف (Host).
• المنفذ داخل الجهاز يقابله العميل (Client) الذي يدير اتصالًا واحدًا.
• الملحق (قرص خارجي، شاشة، لوحة مفاتيح) يقابله خادم MCP الذي يقدم أدوات وبيانات.
• معيار USB-C نفسه تقابله مواصفة MCP.

وللتشبيه حدود يحسن أن تعرفها من البداية: منفذ USB-C ينقل الكهرباء والبيانات فقط، أما خادم MCP فقد ينفذ أفعالًا حقيقية، مثل حذف ملف أو إرسال رسالة. لذلك تضع المواصفة مبادئ أمان واضحة، منها أن الأدوات تمثل تنفيذًا لكود عشوائي ويجب التعامل معها بحذر مناسب، وأن على المضيف أن يحصل على موافقة صريحة من المستخدم قبل استدعاء أي أداة. سنخصص لهذا درسًا كاملًا لاحقًا (الدرس 17)، لكن ضع هذه القاعدة في ذهنك منذ اليوم: لا تربط خادمًا لا تثق بمصدره.

من هم أطراف MCP؟ نظرة أولى سريعة

سنتعمق في البنية في الدرس القادم، لكن تحتاج الآن إلى الصورة العامة. تحدد المواصفة ثلاثة أطراف:

• المضيف (Host): تطبيق الذكاء الاصطناعي الذي تستخدمه، مثل Claude Desktop أو Claude Code أو Visual Studio Code. هو الذي يدير كل شيء، ويقرر ما يصل إلى النموذج.
• العميل (Client): مكون داخل المضيف، يدير اتصالًا مخصصًا بخادم واحد. إذا اتصل المضيف بثلاثة خوادم، أنشأ ثلاثة عملاء، واحدًا لكل خادم.
• الخادم (Server): برنامج يقدم السياق والقدرات. قد يعمل على جهازك (ويسمى عادة خادمًا محليًا)، أو على الإنترنت (ويسمى خادمًا بعيدًا).

مثال من الوثائق الرسمية: عندما يتصل Visual Studio Code بخادم Sentry، ينشئ كائن عميل يحافظ على هذا الاتصال. وعندما يتصل بعد ذلك بخادم نظام الملفات المحلي، ينشئ كائن عميل إضافيًا لهذا الاتصال الجديد.

┌────────────────────────── المضيف (Host) ──────────────────────────┐
│   مثل: Claude Desktop أو VS Code                                    │
│                                                                    │
│   ┌──────────┐        ┌──────────┐        ┌──────────┐             │
│   │ عميل 1   │        │ عميل 2   │        │ عميل 3   │             │
│   └────┬─────┘        └────┬─────┘        └────┬─────┘             │
└────────┼───────────────────┼───────────────────┼───────────────────┘
         │                   │                   │
   خادم الملفات          خادم Git           خادم بعيد على الإنترنت
   (على جهازك)          (على جهازك)          (عبر HTTP)

ماذا يقدم الخادم؟

يقدم الخادم واحدًا أو أكثر من ثلاثة أنواع أساسية تسمى "البدائيات" (Primitives):

1. الأدوات (Tools): دوال ينفذها النموذج، مثل "ابحث في الملفات" أو "أنشئ تذكرة" أو "استعلم من قاعدة البيانات".
2. الموارد (Resources): بيانات وسياق للقراءة، مثل محتوى ملف أو مخطط جداول قاعدة بيانات.
3. القوالب (Prompts): رسائل وتعليمات جاهزة يختارها المستخدم، مثل قالب "راجع هذا الكود".

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

كيف يبدو MCP "من الداخل"؟ لمحة لا أكثر

تحت الغطاء، يتبادل العميل والخادم رسائل بصيغة JSON-RPC 2.0، وهي صيغة نصية بسيطة لطلب تنفيذ عملية واستلام نتيجتها. لا تقلق من التفاصيل الآن، فهي موضوع الدرس الخامس، لكن من المفيد أن ترى شكل رسالة حقيقية مرة واحدة حتى لا يبقى البروتوكول شيئًا غامضًا.

هذا طلب من العميل يسأل الخادم: "ما الأدوات التي لديك؟" (مأخوذ من مثال الوثائق الرسمية للإصدار 2026-07-28):

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

لاحظ ثلاثة أشياء فقط:

• method هو اسم العملية المطلوبة: هنا tools/list أي "اعرض قائمة الأدوات".
• id رقم يربط الطلب بالرد، حتى يعرف العميل أي رد يخص أي طلب.
• _meta يحمل نسخة البروتوكول وهوية العميل وقدراته. في الإصدار 2026-07-28 يحمل كل طلب هذه المعلومات معه، لذلك يستطيع الخادم أن يعالج كل طلب بمفرده.

ويرد الخادم بقائمة أدواته، ولكل أداة اسم ووصف ومخطط للمدخلات. هذا مقتطف مختصر من الرد:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": { "type": "string" }
          },
          "required": ["location"]
        }
      }
    ]
  }
}

الآن تخيل ما يفعله المضيف بهذه القائمة: يجمع أدوات كل الخوادم المتصلة ويعرضها على النموذج. عندما يقرر النموذج أن يعرف حالة الطقس، يرسل المضيف عبر العميل طلب tools/call إلى الخادم المناسب، ثم يعيد النتيجة إلى النموذج ليكمل إجابته. هذه هي الدورة كلها باختصار، وكل ما سيأتي في الدورة هو تفاصيل هذه الدورة.

ملاحظة للقادمين من مقالات قديمة: إذا قرأت شروحات عن MCP كتبت في 2024 أو 2025، فستجد فيها حديثًا عن خطوة initialize في بداية الاتصال. الإصدار 2026-07-28 غير هذا الجانب: صار البروتوكول عديم الحالة (Stateless)، وصار كل طلب يحمل معلوماته في _meta، وأضيف طلب server/discover الذي يستطيع العميل إرساله ليعرف الإصدارات والقدرات التي يدعمها الخادم. سنشرح هذا التحول بهدوء في الدرس الخامس.

من يستخدم MCP اليوم؟

هذا ليس مشروعًا تجريبيًا صغيرًا. تذكر الوثائق الرسمية أن MCP بروتوكول مفتوح يدعمه عدد كبير من العملاء والخوادم: مساعدات مثل Claude وChatGPT، وأدوات تطوير مثل Visual Studio Code وCursor وغيرها. ومن الأمثلة التي تضربها الوثائق على ما يتيحه MCP:

• وكلاء يصلون إلى Google Calendar وNotion، فيصبحون مساعدين شخصيين أكثر فائدة.
• Claude Code ينشئ تطبيق ويب كاملًا انطلاقًا من تصميم في Figma.
• روبوتات محادثة في الشركات تتصل بعدة قواعد بيانات، فيحلل الموظفون البيانات بالمحادثة.

وفي 9 ديسمبر 2025 أعلنت Anthropic التبرع بـ MCP إلى مؤسسة الذكاء الاصطناعي الوكيلي (Agentic AI Foundation) أو AAIF، وهي صندوق موجه تحت مظلة مؤسسة لينكس (Linux Foundation)، شاركت في تأسيسها Anthropic وBlock وOpenAI. الهدف المعلن هو ضمان حياد البروتوكول واستقلاله على المدى الطويل، تحت الرعاية المحايدة نفسها التي تدعم مشاريع مثل Kubernetes وNode.js. وبحسب المدونة الرسمية لـ MCP، يبقى القرار التقني في يد مشرفي البروتوكول (Maintainers) عبر عملية مقترحات التحسين المعروفة باسم SEP.

ماذا يعني هذا لك كمتعلم؟ يعني أن ما تتعلمه هنا ليس مرتبطًا بشركة واحدة. خادم MCP تكتبه اليوم يمكن أن يعمل مع تطبيقات مختلفة من شركات مختلفة.

ما الفرق بين MCP و"استدعاء الأدوات" (Tool Calling) الموجود في النماذج؟

سؤال يطرحه كثيرون في البداية. معظم النماذج الحديثة تدعم ميزة تسمى استدعاء الأدوات أو استدعاء الدوال (Function Calling): تعطي النموذج وصفًا لأداة، فيقرر متى يستدعيها وبأي مدخلات. فما الذي يضيفه MCP؟

الفرق في المستوى الذي يعمل عليه كل منهما:

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

بعبارة أخرى: استدعاء الأدوات هو "قدرة النموذج على استخدام يده"، وMCP هو "المعيار الذي يجعل الأدوات قابلة للتركيب في أي يد". الاثنان يعملان معًا: المضيف يأخذ الأدوات التي اكتشفها عبر MCP ويقدمها للنموذج عبر آلية استدعاء الأدوات.

جرّب بنفسك: شاهد خادم MCP حقيقيًا من الداخل

في هذا التمرين لن تكتب كودًا. ستشغل خادمًا مرجعيًا رسميًا اسمه Everything، صمم خصيصًا لعرض ميزات البروتوكول، وستفحصه بأداة رسمية اسمها MCP Inspector (أداة الفحص).

المتطلبات: أن يكون Node.js مثبتًا على جهازك (يتضمن الأمر npx). تحقق بكتابة node --version في الطرفية.

الخطوة 1: افتح الطرفية (Terminal) واكتب الأمر التالي:

npx @modelcontextprotocol/inspector npx -y @modelcontextprotocol/server-everything

هذا الأمر يشغل أداة الفحص، ويطلب منها أن تشغل خادم Everything كعملية فرعية تتحدث معها عبر الإدخال والإخراج القياسيين (stdio).

الخطوة 2: انتظر حتى تطبع الطرفية عنوانًا محليًا يبدأ بـ http://localhost، وافتحه في المتصفح إن لم يفتح تلقائيًا.

الخطوة 3: في واجهة أداة الفحص، اضغط زر الاتصال (Connect).

الخطوة 4: انتقل إلى تبويب الأدوات (Tools) واطلب عرض القائمة.

الخطوة 5: اختر أداة بسيطة من القائمة، مثل أداة تعيد الرسالة التي ترسلها، واكتب مدخلًا، ثم شغلها.

الخطوة 6: تجول أيضًا في تبويبي الموارد (Resources) والقوالب (Prompts).

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

لماذا لا يحدث شيء إذا شغلت الخادم وحده؟ إذا جربت تشغيل npx -y @modelcontextprotocol/server-everything مباشرة، فقد يبدو أنه "علق". هذا طبيعي، كما يوضح مستودع الخوادم الرسمي: خادم stdio لا يفتح منفذ شبكة، بل ينتظر رسائل من عميل على مدخله القياسي. لهذا نستخدم أداة الفحص لتلعب دور العميل.

الخوادم في مستودع الخوادم الرسمي هي تطبيقات مرجعية للتعليم، والمستودع نفسه ينبه إلى أنها ليست حلولًا جاهزة للإنتاج. استخدمها للتعلم والتجربة.

تمرين ورقي إضافي (5 دقائق): اكتب قائمة بتطبيقات الذكاء الاصطناعي التي تستخدمها (N)، وقائمة بالأنظمة التي تتمنى أن تصل إليها (M). احسب N×M ثم N+M. أي الرقمين تفضل أن تكتب وتصون؟

أخطاء شائعة

• الظن أن MCP نموذج ذكاء اصطناعي أو مكتبة لنموذج معين. MCP بروتوكول، أي اتفاق على شكل الرسائل. لا يحتوي على نموذج، ولا يحدد أي نموذج تستخدم.
• الظن أن MCP خاص بـ Claude وحده. صحيح أن Anthropic أنشأته، لكنه معيار مفتوح تدعمه تطبيقات كثيرة، وهو اليوم مشروع ضمن مؤسسة AAIF تحت مظلة مؤسسة لينكس.
• الخلط بين الخادم بمعناه الشائع وخادم MCP. خادم MCP قد يكون برنامجًا صغيرًا يعمل على حاسوبك نفسه ويتحدث عبر stdio، ولا يحتاج إلى استضافة أو إنترنت.
• الاعتماد على شروحات قديمة دون التحقق من الإصدار. البروتوكول يتطور بسرعة. انظر دائمًا إلى إصدار المواصفة الذي يتبعه أي شرح تقرؤه.
• ربط أي خادم تجده على الإنترنت دون تفكير. الخادم قد ينفذ أفعالًا حقيقية على بياناتك. اقرأ ما يفعله، وتأكد من مصدره، وانتبه لطلبات الموافقة التي يعرضها عليك المضيف.

اختبر فهمك

حاول الإجابة قبل أن تنظر إلى قسم "إجابات الاختبار" في نهاية الدرس.

1. ما المشكلة الأساسية التي جاء MCP ليحلها؟

• أ) بطء النماذج اللغوية في توليد النصوص.
• ب) الحاجة إلى كتابة ربط مخصص بين كل تطبيق ذكاء اصطناعي وكل نظام خارجي.
• ج) ارتفاع تكلفة تدريب النماذج.
• د) صعوبة ترجمة النصوص بين اللغات.

2. لديك 5 تطبيقات ذكاء اصطناعي و10 أنظمة. كم عملية ربط تحتاج بدون معيار مشترك، وكم تطبيقًا للبروتوكول مع MCP؟

• أ) 15 بدون معيار، و50 مع MCP.
• ب) 50 بدون معيار، و15 مع MCP.
• ج) 10 في الحالتين.
• د) 50 في الحالتين.

3. أي من هذه العبارات يصف العميل (Client) في MCP بدقة؟

• أ) هو المستخدم البشري الذي يكتب الأسئلة.
• ب) هو النموذج اللغوي نفسه.
• ج) مكون داخل المضيف يدير اتصالًا مخصصًا بخادم واحد.
• د) برنامج على الإنترنت يقدم الأدوات.

4. ما الصيغة التي يستخدمها MCP لتبادل الرسائل؟

• أ) XML
• ب) JSON-RPC 2.0
• ج) GraphQL
• د) ملفات CSV

5. من أي بروتوكول سابق استلهم MCP فكرته بحسب المواصفة؟

• أ) بروتوكول نقل الملفات FTP
• ب) بروتوكول خادم اللغة LSP
• ج) بروتوكول البريد SMTP
• د) بروتوكول أسماء النطاقات DNS

تحدٍّ إضافي

للقراء المتقدمين: افتح صفحة المعمارية في الوثائق الرسمية (الرابط في قسم المصادر)، واقرأ المثال الكامل لطلب tools/call ورده. ثم أجب كتابة عن هذين السؤالين:

1. لماذا يحمل كل طلب في الإصدار 2026-07-28 نسخة البروتوكول وقدرات العميل داخل _meta، بدل أن تُرسل مرة واحدة في بداية الاتصال؟ فكر في الخوادم البعيدة التي تخدم آلاف العملاء خلف موزع أحمال (Load Balancer).
2. في أداة الفحص، شغل أداة من خادم Everything وراقب الرسائل المتبادلة إن كانت الأداة تعرضها. هل تستطيع التعرف على حقول method وid وresult؟

لا توجد إجابة واحدة "رسمية" هنا، والمهم أن تكوّن تصورك قبل الدرس الخامس.

الخلاصة

• MCP معيار مفتوح المصدر لربط تطبيقات الذكاء الاصطناعي بالبيانات والأدوات وسير العمل.
• يحول مشكلة الربط من N×M تكاملًا مخصصًا إلى N+M تطبيقًا لبروتوكول واحد.
• تشبهه الوثائق الرسمية بمنفذ USB-C: منفذ موحد يعمل مع ملحقات لم تُصنع بعد.
• أطرافه ثلاثة: المضيف (Host) والعميل (Client) والخادم (Server)، والخادم يقدم أدوات وموارد وقوالب.
• الرسائل بصيغة JSON-RPC 2.0، والإصدار 2026-07-28 يجعل كل طلب مكتفيًا بذاته.
• MCP اليوم مشروع محايد ضمن مؤسسة AAIF تحت مظلة مؤسسة لينكس، ويدعمه عدد كبير من التطبيقات.
• الأمان جزء من الفكرة منذ البداية: لا تربط خادمًا لا تثق به.

في الدرس القادم

في الدرس الثاني سنفتح الصندوق ونتعرف على البنية بالتفصيل: المضيف (Host) والعميل (Client) والخادم (Server)، ومن يفعل ماذا. سنرى لماذا ينشئ المضيف عميلًا لكل خادم، وما الفرق بين الخادم المحلي والبعيد، وما طبقتا البروتوكول: طبقة البيانات وطبقة النقل.

إجابات الاختبار

1. ب. قبل MCP كان كل مصدر بيانات يحتاج إلى تكامل مخصص مع كل تطبيق، وهذا ما ذكرته Anthropic في إعلانها عن البروتوكول.
2. ب. بدون معيار: 5 × 10 = 50 ربطًا. مع MCP: 5 + 10 = 15، لأن كل طرف يطبق البروتوكول مرة واحدة.
3. ج. العميل مكون داخل المضيف، وينشئ المضيف عميلًا مستقلًا لكل خادم يتصل به.
4. ب. تنص المواصفة على أن البروتوكول يستخدم رسائل JSON-RPC 2.0 للتواصل بين الأطراف.
5. ب. تذكر المواصفة أن MCP استلهم من بروتوكول خادم اللغة LSP الذي وحّد دعم لغات البرمجة في المحررات.

مصادر

• What is the Model Context Protocol (MCP)? (الوثائق الرسمية)
• Specification 2026-07-28 (المواصفة الرسمية)
• Architecture overview (نظرة على المعمارية)
• Introducing the Model Context Protocol (إعلان Anthropic، نوفمبر 2024)
• MCP joins the Agentic AI Foundation (مدونة MCP، ديسمبر 2025)
• Donating the Model Context Protocol and establishing the Agentic AI Foundation (Anthropic)
• Model Context Protocol servers (مستودع الخوادم المرجعية)
• Official MCP Registry (السجل الرسمي للخوادم)