داخل بروتوكول سياق النموذج (MCP): البنية، الدافع والاستخدام الداخلي

مقدمة

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

نظرة عامة على بروتوكول سياق النموذج (MCP)

في جوهره، يتبع بروتوكول سياق النموذج (MCP) بنية عميل-خادم قائمة على JSON-RPC، حيث يمكن لتطبيق مضيف الاتصال بخوادم متعددة:

• مضيفو بروتوكول سياق النموذج (MCP) هي تطبيقات مدعومة بنماذج اللغة الكبيرة (LLM) مثل Claude Desktop، أو بيئات التطوير المتكاملة (IDEs)، أو أدوات الذكاء الاصطناعي التي ترغب في الوصول إلى البيانات عبر بروتوكول سياق النموذج (MCP).
• عملاء بروتوكول سياق النموذج (MCP) تنفذ بروتوكول سياق النموذج (MCP) من جانب العميل بلغات برمجة مختلفة. إنها الجسر الذي من خلاله يتصل مضيفو بروتوكول سياق النموذج (MCP) بخوادم بروتوكول سياق النموذج (MCP).
• خوادم بروتوكول سياق النموذج (MCP) تكشف عن بيانات وقدرات محددة عبر بروتوكول سياق النموذج (MCP). يمكنها توفير ثلاثة أنواع رئيسية من القدرات:
  • الموارد هي بيانات توفرها خوادم بروتوكول سياق النموذج (MCP) للتطبيقات لقراءتها. يمكن أن تتضمن محتويات الملفات، واستجابات واجهات برمجة التطبيقات (API)، وما إلى ذلك. يتم التحكم في الموارد بواسطة التطبيق؛ حيث تقرر التطبيقات كيفية تضمينها في تدفق المستخدم.
  • الأدوات هي قدرات وبيانات تكشف عنها خوادم بروتوكول سياق النموذج (MCP). على سبيل المثال، يمكن لخادم Kubernetes MCP أن يكشف عن أدوات للحصول على جميع الحاويات (pods) وحذف حاوية. يتم التحكم في الأدوات بواسطة النموذج. تقرر نماذج اللغة الكبيرة (LLMs) استدعاءها بناءً على السياق المعطى.
  • المطالبات هي تفاعلات مستخدم أو سير عمل قابلة للقوالب تكشف عنها خوادم بروتوكول سياق النموذج (MCP). يتم التحكم فيها بواسطة المستخدم. تقرر تطبيقات نماذج اللغة الكبيرة (LLM) كيفية كشفها حتى يتمكن المستخدم من تحديد المطالبة المناسبة.

النقل

تحدد وسائل النقل كيفية تواصل عميل وخادم بروتوكول سياق النموذج (MCP) مع بعضهما البعض.

STDIO

في هذا الإعداد، يكون عميل MCP داخل مضيف MCP مسؤولاً عن تشغيل خادم MCP على نفس الجهاز. يتم الاتصال بين عميل MCP وخادم MCP عبر STDIN و STDOUT. هنا، يتصل خادم MCP واحد فقط بعميل MCP واحد.

يبدو التكوين النموذجي كالتالي:

مثال: يمكنك تشغيل خادم MCP الخاص بـ GitHub محليًا باستخدام Docker ورمز وصول شخصي (PAT)

GitHub - github/github-mcp-server: خادم MCP الرسمي لـ GitHub  

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

التفويض

عادةً، يمكن أن يتم التفويض بطريقتين

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

القيود

• يجب أن يقوم جهاز المستخدم، الذي يشغل التطبيق المدعوم بنماذج اللغة الكبيرة (LLM)، بتثبيت Docker أو Node/Python. على الرغم من أن هذا ليس مشكلة للمطور، فإنه يقلل بشكل كبير من عدد الأشخاص الذين يمكنهم استخدام خادم MCP.
• نظرًا لوجود خادم MCP وتشغيله على جهاز المستخدم، تصبح الترقيات مرهقة، ويتأثر التكرار السريع.
• تطبيقات الويب التي تعمل على المتصفح لا يمكنها استخدام هذا.
• بدون تدفق جهاز OAuth2، يجب على المستخدمين تكوين رموزهم لكل خادم MCP. غالبًا ما لا يتم تخزين الرموز بأمان على الجهاز، وتدويرها مرهق.

نظرًا لهذه القيود، فإن نقل STDIO غير مناسب لإنشاء خوادم MCP مخصصة فوق خدمة الشركة ومصدر البيانات أو اشتراكات SaaS مثل GitHub أو Slack. ومع ذلك، سيكون مفيدًا لحالات استخدام أدوات المطورين في بيئات التطوير المتكاملة (IDEs).

HTTP قابل للتدفق

يتيح HTTP القابل للتدفق لخوادم MCP التعامل مع عملاء MCP متعددين يتصلون ويتواصلون باستخدام بروتوكول HTTP. هذا يزيل الكثير من قيود نقل STDIO. بشكل رئيسي:

1. لم نعد بحاجة إلى استضافة خادم MCP على جهاز المستخدم؛ يمكن استضافته في أي مكان.
2. تصبح الإمكانيات الجديدة المضافة إلى خادم MCP متاحة على الفور لجميع المستخدمين.
3. تطبيقات الويب التي تعمل على المتصفح يمكنها استخدام هذا.

التفويض

التفويض في هذا النقل قيد التطوير النشط. يذكر أحدث مواصفات صدرت بتاريخ 2025-03-26 ما يلي:

1. يجب أن يتبع تنفيذ مصادقة MCP معيار OAuth 2.1.
2. ينبغي أن يتبع تنفيذ مصادقة MCP تسجيل العميل الديناميكي.

سير عمل مصادقة نموذجي سيبدو كالتالي:

في سير العمل المذكور أعلاه، يعمل خادم MCP الذي يصدر الرموز المميزة كمورد وخادم تفويض. هذا غير عملي لخوادم MCP الخاصة بـ Slack و GitHub وما إلى ذلك، حيث يقوم المزود بالفعل بتنفيذ خادم تفويض OAuth2 الخاص به. تعاني الخدمات المستضافة داخليًا للشركة خلف خوادم التفويض التي يوفرها موفر الهوية (IDP) من نفس المشكلة (على سبيل المثال، تثبيت ArgoCD خلف خادم تفويض مقدم من Okta).

تسمح المواصفات بتفويض ذلك إلى خادم تفويض تابع لجهة خارجية، ولكن يجب على خادم MCP إصدار رمزه المميز وإدارة العلاقة مع الرمز المميز للجهة الخارجية. هذا يلغي جميع فوائد خادم التفويض التابع لجهة خارجية، حيث يحتاج خادم MCP إلى تنفيذ إدارة آمنة للرموز المميزة ومسارات OAuth2.

قيود

• تتطلب خوادم MCP المزودة بمصادقة بنية تحتية مثل قاعدة بيانات لتخزين وإدارة دورة حياة رموزها المميزة بشكل آمن. سيصبح كل خادم MCP، في الواقع، خادم تفويض خاصًا به، وهو أمر زائد عن الحاجة ويستحيل الحفاظ عليه داخل الشركة. يعمل المجتمع بنشاط على تعديل مواصفات التفويض لتحسين هذا الأمر.
• المزودون مثل Atlassian و Sentry و Slack و Github وما إلى ذلك، لا يدعمون تسجيل العميل الديناميكي (DCR) أو حتى يدعمون عميل OAuth2 العام. يصبح بناء خوادم MCP فوق هؤلاء المزودين أكثر صعوبة للمجتمع والمزيد من العمل للمزود. نشرت Atlassian مؤخرًا خادم MCP الخاص بها، لكن تنفيذ DCR الخاص بها يسمح فقط بـ localhost وعدد قليل ومحدد من عناوين URL لإعادة التوجيه، مثل Claude، وما إلى ذلك.

نهج TrueFoundry

في TrueFoundry، نريد أن يتمكن زملاؤنا بنشاط من ربط حساباتهم في Atlassian و Sentry و Slack و GitHub وما إلى ذلك بنماذج اللغة الكبيرة (LLM) كسياق إضافي. نريد أيضًا التأكد من أن كل موظف يمكنه فقط الوصول إلى الموارد أو اتخاذ إجراءات بشأنها عبر نماذج اللغة الكبيرة (LLM) التي يُصرح له بها. يبدو أن MCP + OAuth2 هو الطريقة المثلى لتحقيق ذلك.

• نريد التركيز على كتابة خوادم MCP عالية الجودة لعرض البيانات والقدرات بشكل أكثر كفاءة لنماذج اللغة الكبيرة (LLMs). نريد القيام بذلك بشكل آمن، مع الالتزام بحدود التحكم في الوصول المستند إلى الدور (RBAC) المحددة داخل المزود.
• لا نريد صيانة خوادم تفويض إضافية لخوادم MCP المختلفة. نريد إعادة استخدام إمكانيات OAuth2 للمزودين.
• عادةً ما تدعم الجهات المزودة عملاء OAuth2 السريين فقط. ولا يُعد DCR والعميل العام خيارًا مطروحًا.
• لا تزال مواصفات ترخيص MCP تتغير وتُطوّر بنشاط. لا يمكننا الانتظار حتى تستقر قبل البدء في العمل على هذا.

بناءً على ما سبق، توصلنا إلى البنية التالية.

توجد هنا بعض المكونات.

خوادم MCP

لقد قمنا بتطوير خوادم HTTP MCP لجهات مزودة مثل Slack وSentry وAtlassian وGithub وغيرها، باتباع نقل HTTP القابل للتدفق.

تعمل خوادم MCP هذه كوكيل بين نموذج اللغة الكبير (LLM) وواجهات برمجة تطبيقات HTTP الخاصة بالجهة المزودة. لاحظ أن هذا ليس ترجمة حرفية. تحتوي واجهات برمجة تطبيقات HTTP لهذه الجهات المزودة على الكثير من المحتوى غير الضروري الذي يمكن أن يشتت نموذج اللغة الكبير بسهولة ويملأ نافذة السياق. على سبيل المثال، ستتضمن أداة سرد الحاويات (pods) على خادم Kubernetes MCP الكثير من المحتوى المكرر حيث تتكرر مواصفات الحاوية عبر حاويات متعددة. الحقول الكبيرة، مثل managedFields، لن تكون مطلوبة لمعظم طلبات المستخدمين. سيكون لدى مزودي SaaS الآخرين كيانات أصلية متداخلة، وحقول غير وظيفية، مثل عنوان URL للصورة الرمزية (Avatar URL)، وما إلى ذلك. هذا هو المكان الذي نريد أن نقضي فيه معظم وقت تطويرنا. في النهاية، نحتاج إلى نظام في MCP يمكنه مساعدة نماذج اللغة الكبيرة (LLMs) على اكتشاف نموذج بيانات النظام ثم الاستعلام ديناميكيًا عن حقول محددة للموارد.

تتوقع خوادم MCP هذه رأس ترخيص HTTP وتمرره مباشرة إلى واجهة برمجة تطبيقات HTTP الخاصة بالجهة المزودة.

تسجيل خوادم MCP على TrueFoundry

بعد نشر خوادم MCP، نقوم بإنشاء تطبيقات OAuth2 أو عملاء سريين لكل جهة مزودة. هذا هو شكلها بالنسبة لـ Slack.

أعلاه، يمكنك أيضًا ملاحظة أن عنوان URI لإعادة توجيه المفوّض قد تم تكوينه. عادةً ما يبدو كالتالي https://base-url/mcp-integrations/oauth2/callback.

ثم نقوم بدمج خادم MCP مع عنوان URL.

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

اختيار خادم MCP على بوابة TrueFoundry والترخيص

بمجرد التكامل، يمكننا اختيار خادم MCP على ساحة لعب البوابة (Gateway Playground).

إذا لم يكن المستخدم مرخصًا، نستخدم معلومات عميل OAuth2 في التكامل ونوجه المستخدم خلال تدفق رمز ترخيص OAuth2. في نهاية العملية، يقوم TrueFoundry بحفظ رموز الوصول والتحديث (Access and Refresh Tokens) بشكل آمن (إذا كانت مدعومة وممكنة).

يمكننا إزالة بيانات الاعتماد الخاصة بنا من TrueFoundry أو حتى إلغاؤها مباشرةً من المزوّد.

ابدأ باستخدامه!

بمجرد التفويض، يمكنك استخدام السياق من خوادم MCP مباشرةً على منصة الاختبار الخاصة بنا.

تجدر الإشارة إلى أننا لا نمرر أي بيانات اعتماد OAuth2 إلى الواجهة الأمامية. الواجهة الأمامية تستدعي واجهة برمجة تطبيقات (API):

curl -X POST "https://base-url/api/llm/agent/responses" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-main/gpt-4o-mini",
    "messages": [
      {
        "role": "user",
        "content": "what are the issues in my app"
      }
    ],
    "tools": [
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:sentry",
        "tools": ["list_projects", "list_issues"]
      },
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:slack"
      }
    ]
  }'

‍

تنفذ بوابة LLM الحلقة "الوكيلة"، حيث ترسل الرسائل الأولية وأوصاف أدوات خادم MCP إلى LLM. يمكن للمستخدم أيضًا تصفية الأدوات المعروضة على LLM. بناءً على استجابة LLM، يمكن لبوابة LLM التواصل مع خوادم MCP وتمرير بيانات اعتماد المتصلين. نقوم بتحديث أي بيانات اعتماد قصيرة الأجل تلقائيًا. يتم إرسال التحديثات إلى الواجهة الأمامية باستخدام SSE.

الخلاصة

سمح تدفق MCP + OAuth2 هذا لزملائنا بدمج البيانات بأمان من مزودين مثل Slack وGitHub وSentry وما إلى ذلك، في سير عملهم المرتكز على LLM.

بعض حالات الاستخدام،

• يمكن لـ LLMs الوصول إلى Sentry عبر MCP لجلب تفاصيل الأخطاء وربطها بتغييرات التعليمات البرمجية ذات الصلة من GitHub لتسريع عملية تصحيح الأخطاء.
• تقوم LLMs بإنشاء وتحديث والاستعلام عن تذاكر Jira عبر MCP، مما يبسط سير عمل المطورين.
• يمكن لـ LLMs الوصول إلى محادثات Slack عبر MCP لتحليل وتلخيص سلاسل المناقشات الطويلة، مما يساعد الفرق على فهم القرارات وبنود العمل بسرعة دون الحاجة لقراءة سجلات الدردشة بأكملها.