بروتوكول MCP: ما هو وكيف يعمل ومتى تحتاجه فعلاً؟

تفتح إعدادات كلود كود أو محرر Cursor أو GitHub Copilot فتصادف قسماً اسمه «خوادم MCP»، وتقف أمام سؤال لا يجيب عنه التوثيق مباشرة: مكتبة أثبّتها؟ نموذج جديد؟ وهل يُفترض بي أن أبني واحداً بنفسي؟ بروتوكول MCP، أو بروتوكول سياق النموذج، ليس أياً من ذلك. والجواب أن MCP لا يصل إلى النموذج إطلاقاً: المضيف هو من يسأل الخادم عبر tools/list، ثم يترجم الجواب إلى تعريفات أدوات داخل طلبه، والنموذج نفسه لا يعرف أن MCP موجود. ومن هنا يتضح الباقي، حتى اقتطاع كل خادم تفعّله جزءاً من نافذتك قبل أن ينفعك.

مشكلة N×M التي وُلد لحلّها

قبل نوفمبر 2024 كان كل تكامل يُبنى يدوياً: N نموذج × M أداة. ثلاثة مضيفين وأربع خدمات تعني 12 موصّلاً مخصصاً تُكتب وتُصان واحداً واحداً. ثم أعلنت أنثروبيك MCP في 25 نوفمبر 2024 معياراً مفتوحاً يربط المساعدين بمصادر البيانات والأدوات، فصارت أربعة خوادم تخدم المضيفين الثلاثة جميعاً.

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

البنية من الداخل: مضيف وعميل وخادم

الأطراف ثلاثة. المضيف هو تطبيق النموذج نفسه — كلود كود أو محرر Cursor — وداخله يعمل العميل، وهو موصّل مخصص لكل خادم على حدة، لا موصّل واحد مشترك.

أما الخادم فيقدّم ثلاث قدرات يفرزها سؤال واحد: من يقرّر متى تُستعمل؟ الأدوات يقرّرها النموذج، والموارد يقرّرها التطبيق المضيف وهي للقراءة فقط، والقوالب الموجِّهة يقرّرها المستخدم بنقرة. والخانة الخطأ تُسكِت قدرتك: عملية كتابة عرّفتها مورداً لن يستدعيها النموذج أبداً. الأدوات وحدها أساس مدعوم عند كل المضيفين تقريباً، ودعم الموارد والقوالب متفاوت، فراجع توثيق مضيفك قبل أن تبني عليها.

على مستوى النقل: stdio للخوادم المحلية، وStreamable HTTP للبعيدة، وقد حلّ محل HTTP+SSE منذ مراجعة 2025-03-26 التي أضافت أيضاً تفويض OAuth 2.1.

نهاية المصافحة: ماذا غيّرت مراجعة 2026-07-28

المراجعة الجارية وقت تحديث هذا المقال هي 2026-07-28، وقبلها 2025-11-25 و2025-06-18 و2025-03-26 و2024-11-05. والمواصفة نفسها صارت تفرز التنفيذات إلى ثلاث خانات: حديثة من 2026-07-28 فما بعد، وقديمة عند 2025-11-25 فما قبل، ومزدوجة تدعم الاثنتين. وما تغيّر:

• حُذفت المصافحة: لا initialize ولا notifications/initialized، وكل طلب صار يحمل نسخة البروتوكول وقدرات العميل في _meta.
• حُذفت الجلسات ورأس Mcp-Session-Id. البروتوكول عديم الحالة.
• طريقة إلزامية على كل خادم: server/discover تعيد النسخ المدعومة والقدرات والهوية في نداء واحد.
• حُذفت طريقتا ping وlogging/setLevel.
• صارت Roots وأخذ العينات والتسجيل مهجورة، ومعها مسارات هجرة مقترحة: المسارات وسائطُ أدوات أو معرّفات موارد، والتكامل مباشرة عبر واجهة مزوّد النموذج، والسجلات على stderr أو OpenTelemetry.

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

وأسماء tools/list وtools/call بقيت، لكن لا تقرأها توافقاً: شكل النتيجة تغيّر وصار حقل resultType إلزامياً. ومصفوفة التوافق أقسى مما تبدو: عميل حديث مع خادم قديم يفشل، وعميل قديم مع خادم حديث يفشل، ولا ينجح إلا من نفّذ العصرين معاً. فإن كان لديك خادم يعمل، فالهجرة مسألة وقت.

من يملك البروتوكول بعد خروجه من أنثروبيك

اصطفّ منافسو أنثروبيك خلف بروتوكولها: OpenAI في 26 مارس 2025 داخل Agents SDK ثم في ChatGPT وواجهتها البرمجية، وقوقل ديب مايند في 9 أبريل 2025 لنماذج Gemini، ثم مايكروسوفت في مؤتمر Build يوم 19 مايو 2025 بإعلان دعم أصيل قادم في ويندوز 11 ومعاينة للمطورين وسجل خوادم يشترط توقيع الكود، وأخيراً GitHub Copilot في 13 أغسطس 2025 في JetBrains وEclipse وXcode.

وبقي تحفّظ وجيه: كيف تبني بنيتك على معيار تملكه شركة منافسة؟ زال من أصله في 9 ديسمبر 2025 حين انتقلت ملكية البروتوكول إلى مؤسسة Agentic AI Foundation تحت مظلة Linux Foundation، ومؤسسوها أنثروبيك وBlock وOpenAI، ووراءهم قوقل ومايكروسوفت وAWS وCloudflare وBloomberg. وأثر ذلك عندك أن الخادم الذي تكتبه أصل قابل للنقل لا التزام تجاه مزوّد، فيتبدّل المضيف — وهو أكثر ما يتبدّل هنا كما يظهر في أفضل أدوات البرمجة بالذكاء الاصطناعي 2026 ومتى تختار كلاً منها — دون أن تعيد كتابة تكاملاتك.

من الأمر الأول إلى أول أداة تعمل

أسرع طريق: تركيب خادم جاهز في كلود كود.

claude mcp add --transport http notion https://mcp.notion.com/mcp

claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

الفاصل -- يفصل خيارات كلود كود عن أمر الخادم؛ بدونه تُفسَّر أعلام الخادم كأعلام لكلود فيفشل الأمر بلا سبب واضح. وللتركيب ثلاثة نطاقات: local الافتراضي في ~/.claude.json لمشروعك وحدك، وproject في .mcp.json بجذر المشروع فيُشارَك مع فريقك عبر إدارة الإصدارات، وuser في كل مشاريعك. وعند تكرار الاسم يفوز الأعلى أسبقية بإدخاله كاملاً، ولا تُدمج الحقول.

شكل الملف المشترك:

{
  "mcpServers": {
    "shared-server": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

إدخال فيه url بلا type يُقرأ كخادم stdio ويُتخطى. وانتبه لفخ النسخ واللصق: VS Code يستعمل المفتاح servers في .vscode/mcp.json لا mcpServers، ونقل الكتلة كما هي بين المحررين عطل متكرر.

وإذا أردت خادمك أنت، فهذا أصغره بحزمة بايثون الرسمية:

from mcp.server import MCPServer

mcp = MCPServer("Demo")


@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b


if __name__ == "__main__":
    mcp.run(transport="stdio")

المزخرف يتكفّل بثلاثة: اسم الدالة يصير اسم الأداة، والوصف النصي داخل الدالة يصير ما يقرؤه النموذج ليقرر متى يستدعيها، وتلميحات النوع تتحول تلقائياً إلى مخطط JSON للمدخلات، فلا مخطط يدوي ولا تحقق يدوي. ولاحظ تغيير التسمية: في الإصدار الثاني من حزمة بايثون صار الصنف MCPServer بعد أن كان FastMCP. ولتجربته قبل ربطه بأي مضيف، شغّل MCP Inspector عبر npx @modelcontextprotocol/inspector.

stdio أم HTTP؟ الفرق ليس في الأداء وحده

المحور	stdio	Streamable HTTP
كيف يبدأ	عملية فرعية يشغّلها العميل	خدمة مستقلة تخدم عملاء كثيرين
المصادقة	أسرار تُمرَّر عبر مفتاح env	رؤوس قياسية وتفويض OAuth
تعدد المستخدمين	عميل واحد عادةً	متعدد بطبيعته
السجلات	stderr والتقاطه خيار المضيف	لا يلتقطه أحد، فيلزمك تجميع سجلات
إعادة الاتصال في كلود كود	لا إعادة وصل تلقائية	تراجع أُسّي حتى 5 محاولات
الخطر الأمني الخاص	تنفيذ محلي بصلاحيات المستخدم	إعادة ربط DNS

وإذا اخترت HTTP فشرطان لا تتنازل عنهما: تحقّق من رأس Origin في كل اتصال وارد وردّ بـ403 عند قيمة غير صالحة، واربط الخادم محلياً بـ127.0.0.1 لا 0.0.0.0 — وإلا خاطب موقعٌ بعيد يزوره المستخدم خادمَك المحلي عبر إعادة ربط DNS.

الأمان: تثبيت خادم يعني تشغيل كود بصلاحياتك

المواصفة صريحة: الأمان غير مفروض على مستوى البروتوكول، والموافقة على استدعاء الأدوات مسؤولية المضيف والمستخدم. والخطر ليس نظرياً. في أبريل 2025 وثّقت Invariant Labs تسميم الأدوات: تعليمات خبيثة تُخفى داخل وصف الأداة، يقرؤها النموذج ولا يراها المستخدم، وهي اليوم في قائمة OWASP MCP Top 10. وفي يوليو 2025 كشفت الثغرة الحرجة CVE-2025-6514 في حزمة mcp-remote إمكانية تنفيذ كود عن بُعد بمجرد الاتصال بخادم غير موثوق. ثم جاء postmark-mcp في سبتمبر 2025، أول خادم MCP خبيث موثّق على npm: الإصدار 1.0.16 أضاف سطراً يرسل نسخة خفية من كل بريد إلى المهاجم.

تثبيت خادم عشوائي يعادل تشغيل كود غريب بصلاحياتك الكاملة، فالتزم الخوادم الرسمية مثل Filesystem وGit وFetch وMemory أو راجع الكود بنفسك قبل التشغيل. والفارق عن حقن التعليمات المعتاد أن هذه لا تصلك في محتوى عابر، بل تُثبَّت في وصف أداة يُقرأ كلما احتاجها الوكيل. وبقية أسطح التعرّض في البرمجة بوكلاء الذكاء الاصطناعي.

ولا تُغفل كلفة السياق: التعريفات تُحمَّل قبل أن يستدعي النموذج أداة واحدة، فمئة أداة مفعّلة تدفع ثمنها في كل رسالة. في مثال هندسي نشرته أنثروبيك في 4 نوفمبر 2025 انخفض الاستهلاك من 150,000 رمز إلى 2,000 مع تحميل الأدوات عند الطلب. ومن يلصق الملفات يدوياً في كل جلسة يعالج مشكلة أخرى غير هذه، وهو ما فصّلناه في كتابة أوامر فعّالة لنماذج الذكاء الاصطناعي مثل كلود.

أعطال تلتهم ساعتك الأولى

1. print في بايثون أو console.log في جافاسكربت داخل خادم stdio يكسره، لأن stdout مخصص لرسائل MCP وحدها ولا يجوز أن يتخلل الرسالةَ سطر جديد. اكتب سجلاتك على stderr.
2. مسار نسبي في الإعداد: دليل عمل الخادم المُشغَّل من المضيف قد يكون غير معرَّف، فاستخدم مسارات مطلقة.
3. افتراض أن الخادم يرث بيئة صدفتك: خوادم stdio ترث مجموعة محدودة تختلف بحسب المنصة، فمرّر ما يلزم عبر env. وcommand خارج PATH يظهر كخطأ ENOENT.
4. تصادم أسماء الأدوات: التفرّد مقصور على الخادم الواحد، فخادمان يعرضان search يتصادمان. كلود كود يفضّه ببادئة تجمع اسم الخادم مع الأداة، ولا تعتمد على serverInfo لأن اسمه غير مضمون التفرّد.
5. وصف أداة متضخّم: كلود كود يقتطع وصف الأداة وتعليمات الخادم عند 2KB لكلٍّ منهما، والحرج يوضع أولاً.

ابنِ، أم ثبّت جاهزاً، أم لا تفعل شيئاً؟

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

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