سجل MCP وبوابة الذكاء الاصطناعي: البنية وحالات الاستخدام المؤسسية

بين عامي 2020 و 2023، أثبتت النماذج التأسيسية مثل GPT-3 و GPT-4 أثبتت أن نماذج اللغة الكبيرة يمكنها توليد نصوص شبيهة بالبشر، وكتابة التعليمات البرمجية، وتلخيص المستندات، والإجابة على الأسئلة المعقدة. لكن هذه النماذج كانت عديمة الحالة و معزولة، فلم تتمكن من الوصول إلى الأنظمة الداخلية أو قواعد البيانات أو التطبيقات — ولم يكن لديها أي وسيلة لاتخاذ إجراءات حقيقية في العالم الواقعي.

يمكنك أن تسأل نموذجًا:

“اكتب استعلام MongoDB لسرد جميع المجموعات في قاعدة بيانات الامتثال.”

كان سيولد مخرجات تبدو كاستعلام MongoDB صالح — لكن:

• لم يكن لديه أي فكرة عما إذا كانت الـ قاعدة البيانات موجودة
• لم يكن يعرف ما هي المجموعات الموجودة في قاعدة البيانات
• لم يتمكن من تحديد ما إذا كان الاستعلام سيعمل من الأساس
• لم تكن هناك طريقة لـ فحص المخططات، التحقق من النتائج، أو تشغيل إجراءات المتابعة مثل التلخيص أو إخطار نظام آخر

كان الأمر كله تخمينًا — مع عدم وجود حلقة تغذية راجعة.

لإصلاح ذلك، بدأ المطورون في بناء طبقات حول نماذج اللغات الكبيرة (LLMs):

• تسلسل الأوامر
  
• أغلفة مخصصة في بايثون
  
• حقن استدعاء واجهة برمجة تطبيقات REST عبر قوالب السلاسل النصية
  
• حشو السياق اليدوي
  ("باستخدام المخطط التالي، اكتب الاستعلام")

كانت هذه حلولاً ذكية ولكن أصعب في الصيانة.

أطر عمل مثل LangChain، LlamaIndex، و Semantic Kernel ظهرت لتنظيم سير العمل هذه. ساعدت هذه الأدوات في تنظيم الأمور، لكن المشاكل لم تختفِ. كانت النماذج لا تزال تختلق حقولاً، وتقع فريسة لحقن الأوامر، وتتخطى التحقق من الصحة، ولم يكن لديها طريقة قياسية لتشغيل الوظائف الفعلية المحددة. كل حالة استخدام جديدة كانت لا تزال تبدو وكأنها إعادة اختراع للعجلة.

جاءت نقطة التحول الحقيقية عندما أدرك المطورون:

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

في منتصف عام 2023 تقريبًا، قدمت OpenAI استدعاء الدالة، مما يمكّن النماذج من إرجاع مخرجات منظمة JSON تتطابق مباشرة مع استدعاءات الدوال الحقيقية.

لقد أعاد تعريف ما هو ممكن مع تكامل النماذج

• أصبحت نماذج اللغات الكبيرة (LLMs) الآن قادرة على التفاعل مع الأدوات باستخدام مدخلات ومخرجات محددة بوضوح
  
• تصرّفت النماذج كـ عملاء API، بدلاً من مولدات تعتمد على التخمين
  
• أصبحت المهام الآن قابلة لـ الأتمتة بخطوات متعددة وتفاعلات مع الأنظمة

مع استدعاء الدوال، برزت الأدوات و الوكلاء — نماذج يمكنها ربط الإجراءات، واتباع سير العمل، والتفاعل مع الأنظمة الحقيقية

ولكن...
1. كان كل تنفيذ خاصًا بالمورد.
2. لم يكن هناك أي شيء مشترك تنسيق قياسي  لكيفية وصف الأدوات أو استدعائها.

هنا يأتي دور MCP (بروتوكول سياق النموذج) — مقترحًا كـ بروتوكول عام ومفتوح للتواصل المنظم بين النماذج والأدوات الخارجية. فبدلاً من تضمين واجهات برمجة تطبيقات الأدوات (APIs) بشكل ثابت في كل تطبيق LLM، يقدم MCP شاحنًا عالميًا لربط أدوات الذكاء الاصطناعي  — مثل OpenAPI، Anthropic وغيرها، ولكن لنموذج اللغة الكبير (LLMs) عند استدعاء الأدوات. وهو يستند إلى JSON-RPC 2.0، وهي مواصفات مستخدمة على نطاق واسع تدعم استدعاءات الإجراءات عن بُعد (RPCs) باستخدام JSON.

ما يحدده MCP

• كيف يمكن للنموذج استدعاء طريقة أداة (مثل، runAggregation)
  
• كيفية تمرير المعلمات والحصول على استجابات منظمة
  
• كيف تصف الأدوات أساليبها المتاحة (عبر المخططات أو البيانات الوصفية)
  
• معيار خفيف الوزن لدمج الأدوات عبر أي نظام خلفي (قاعدة بيانات، واجهة سطر الأوامر، واجهة برمجة تطبيقات سحابية)

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

بروتوكول سياق النموذج

‍MCP (بروتوكول سياق النموذج) هو بروتوكول خفيف الوزن مصمم خصيصًا للتواصل المنظم بين نماذج الذكاء الاصطناعي و الأدوات الخارجية.

في جوهره، يستخدم MCP بروتوكول JSON-RPC 2.0، وهو بروتوكول أثبت كفاءته لاستدعاء الإجراءات عن بُعد بمدخلات ومخرجات منظمة — مثالي لتحويل مخرجات نماذج اللغة الكبيرة (LLM) إلى استدعاءات أدوات حقيقية.

إذًا لماذا ابتكار بروتوكول آخر؟

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

• التطبيق المضيف: ينظم استدعاءات الأدوات، ويتعامل مع مخرجات نماذج اللغة الكبيرة (LLM)، ويربط الاستجابات — على سبيل المثال، وكيل GRC يستعلم Mongo، ويلخص النتائج، ويرسل التنبيهات.
• خادم MCP: ينفذ منطقًا خاصًا بالمجال مثل listCollections، runAggregation، أو sendMessageToSlack.
• عميل MCP: مكتبة بسيطة تتعامل مع تنسيق الطلبات، والمصادقة، وإعادة المحاولة، وتربط المضيف بخادم MCP المناسب.

تعرض الخوادم عادةً:

• الأدوات: أوامر قابلة للتنفيذ مثل listCollections، runAggregation، أو sendSlackMessage.
• الموارد: بيانات وصفية مثل تعريفات المخطط، بيانات تعريف المجموعة، أو هيكل قاعدة البيانات.

اختياريًا، يمكن للخوادم أيضًا عرض:

• المطالبات: قوالب/مطالبات الوكيل الموحدة
• عناصر بدائية من جانب العميل: تلميحات التخزين المؤقت أو التجميع
• إشعارات: تدفقات الأحداث في الوقت الفعلي (عبر SSE)

خيارات النقل: STDIO مقابل HTTP/SSE

MCP مستقل عن وسيلة النقل ويدعم وضعين:

تتبع كلتا وسيلتي النقل نفس تنسيق JSON-RPC، مما يتيح لك التبديل بين وسيلتي النقل دون إعادة كتابة المنطق.

هذه هي الفكرة الرئيسية وراء MCP — طريقة بسيطة ونظيفة للنماذج لاستدعاء الأدوات دون الحاجة إلى آليات ربط مطالبات هشة. لا توجد أوامر وهمية. لا يوجد حشو يدوي للسياق. فقط مدخلات ومخرجات واضحة. ولكن كيف يعمل هذا فعليًا في تطبيق حقيقي؟ دعنا نستعرض مثالاً باستخدام مساعد امتثال مدعوم بـ MongoDB.

أتمتة سير عمل الحوكمة والمخاطر والامتثال (GRC) باستخدام Mongo-MCP

تخيل أنك تقوم ببناء مساعد للحوكمة والمخاطر والامتثال (GRC).

يحتاج هذا المساعد إلى:

• جلب المجموعات وسجلات التدقيق من قاعدة بيانات MongoDB
• تلخيص النتائج لمسؤول الامتثال
• إخطار الفرق المعنية على Slack
• اختياريًا، فتح مشكلة متابعة على GitHub

في الإعداد التقليدي، كنت ستقوم بتضمين هذا المنطق بشكل مباشر باستخدام استدعاءات REST أو نصوص Python البرمجية، وتضمين المخططات وبيانات الاعتماد في قوالب المطالبات. كل عملية تكامل ستكون مخصصة — وهشة.

مع MCP، تصبح كل أداة من هذه الأدوات — MongoDB، Slack، GitHub — مزود وظائف أساسي، مقدمة طرقًا محددة بوضوح مثل:

• listCollections
• runAggregation
• إرسال رسالة
• إنشاء مشكلة

يقوم وكيل GRC (تطبيقنا المضيف) ببساطة باستدعاء هذه الأدوات باستخدام مخطط JSON-RPC الخاص بـ MCP

السيناريو: اكتشاف انتهاكات السياسة والإبلاغ عنها تعليمات المستخدم: "تحقق من قاعدة بيانات الامتثال بحثًا عن أي انتهاكات للسياسة اليوم وأبلغ الفريق على Slack."

1. إدخال المستخدم ← التطبيق المضيف ← LLM يرسل وكيل GRC (التطبيق المضيف) رسالة المستخدم إلى النموذج. النموذج مدرك للأدوات ويستجيب بـ:

{
  "tool_calls": [
    {
      "name": "listCollections",
      "arguments": {
        "database": "compliance"
      }
    }
  ]
}

2. يستدعي التطبيق المضيف Mongo-MCP عبر عميل MCP يتم تحويل استدعاء الأداة هذا إلى طلب JSON-RPC:

{
  "jsonrpc": "2.0",
  "method": "listCollections",
  "params": {
    "database": "compliance"
  },
  "id": "req-001"
}

3. ينفذ Mongo-MCP الوظيفة يقوم Mongo-MCP بربط هذا الاستدعاء بـ:

def listCollections(database: str) -> List[str]:
    return mongo_client[database].list_collection_names()

يقوم بتشغيل الوظيفة، ويحصل على النتيجة، ويستجيب:

{
  "jsonrpc": "2.0",
  "result": [
    "audit_logs",
    "policy_violations",
    "user_sessions"
  ],
  "id": "req-001"
}

4. يربط الوكيل الاستدعاء التالي: runAggregation يقوم النموذج الآن بإنشاء استدعاء متابعة بناءً على المجموعات المتاحة:

{
  "tool_calls": [
    {
      "name": "runAggregation",
      "arguments": {
        "database": "compliance",
        "collection": "policy_violations",
        "pipeline": [
          { "$match": { "timestamp": { "$gte": "2025-08-05" } } },
          { "$group": { "_id": "$severity", "count": { "$sum": 1 } } }
        ]
      }
    }
  ]
}

ينتج عن ذلك استدعاء JSON-RPC آخر إلى Mongo-MCP، ويعيد الخادم:

{
  "jsonrpc": "2.0",
  "result": [
    { "_id": "high", "count": 5 },
    { "_id": "medium", "count": 12 }
  ],
  "id": "req-002"
}

يمرر الوكيل هذه النتيجة مرة أخرى إلى النموذج مع مطالبة مثل:

"لخص بيانات انتهاك السياسة هذه بلغة إنجليزية واضحة."

يرد النموذج:

"اليوم، كان هناك 5 انتهاكات للسياسة عالية الخطورة و 12 انتهاكًا متوسط الخطورة في قاعدة بيانات الامتثال.”

5. يستدعي النموذج Slack-MCP لإخطار الفريق. الآن يصدر الوكيل استدعاء أداة منظمًا نهائيًا:

{
  "tool_calls": [
    {
      "name": "sendMessage",
      "arguments": {
        "channel": "#compliance-alerts",
        "message": "5 high and 12 medium policy violations detected today. Please review."
      }
    }
  ]
}

يرسل خادم Slack-MCP الرسالة، ويكتمل سير العمل. حدث كل هذا من خلال استدعاءات JSON منظمة، وليس من خلال معالجة السلاسل النصية أو هندسة الأوامر.

Governing Enterprise AI at Scale: The MCP Gateway Blueprint

$2 Million

The

Wake-Up Call

Your integration architecture determines whether AI becomes a competitive advantage or unmanageable risk.

A Fortune 500 Spent $2M Fixing Ungoverned AI

Don't let this be you, get the complete Al governance blueprint.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

لماذا تحتاج إلى سجل خادم MCP في بوابة MCP؟

يبدو عرض Mongo-MCP نظيفًا. أجرى النموذج استدعاءات أدوات منظمة. عملت كل وظيفة كما هو متوقع. لا توجد هلوسات. لا توجد قوالب سلاسل نصية هشة. لكن هذا هو المسار المثالي — والأنظمة الحقيقية لا تتعلق فقط بالعمل... بل تتعلق بالعمل بأمان وموثوقية وقابلية للمراقبة على نطاق واسع.

في بيئة الإنتاج، يقصر MCP الخام في بعض المجالات الرئيسية:

1. لا يوجد تحكم في الوصول (RBAC) لا يمتلك MCP الخام طريقة مدمجة لتقييد من يمكنه استدعاء ماذا.

• ماذا لو أردت السماح بتشغيل التجميع (Aggregation) ولكن حظر حذف المجموعة (deleteCollection)؟
• ماذا لو كان النموذج يجب أن يستعلم فقط عن مجموعات بيانات معينة (على سبيل المثال، لا يمكن للمالية الوصول إلى الموارد البشرية)؟

في المؤسسات الحقيقية، التحكم في الوصول المستند إلى الأدوار (RBAC) غير قابل للتفاوض — خاصة عندما تكون النماذج متصلة بأدوات حساسة.

2. لا يوجد توثيق أو مفاتيح API لا يتعامل MCP الخام مع

• التحقق من أي وكيل أو نموذج يقوم بالاستدعاء
• تحديد نطاق بيانات الاعتماد لكل فريق أو بيئة أو مشروع
• انتهاء صلاحية الرمز المميز أو إبطاله

هذا يعني أن أي شخص لديه وصول إلى خادم MCP يمكنه استدعاء أي أداة — ولا يوجد سجل تدقيق.

3. لا توجد قابلية للمراقبة لا يمكنك إصلاح ما لا تراه.

• ما هو زمن استجابة كل استدعاء أداة؟
• ما هو معدل الفشل أو عدد مرات إعادة المحاولة؟
• ما هي الأدوات التي تُستخدم بشكل مفرط أو تتجاوز المهلة؟

مع بروتوكول MCP الخام، لا تتوفر لديك لوحات معلومات أو سجلات أو تتبعات. أنت تعمل بشكل أعمى.

4. لا توجد حواجز حماية. نماذج اللغة الكبيرة إبداعية — وأحيانًا أكثر من اللازم.

بروتوكول MCP الخام يفتقر إلى:

• لا توجد حدود للرموز (مثل منع التجميعات الضخمة)
• لا توجد حدود لحجم النتائج (مثل إرجاع 5 ميجابايت من Mongo)
• لا توجد قواطع دائرة أو مطالبات إيقاف مؤقت (مثل "هل أنت متأكد أنك تريد إرسال تنبيه Slack هذا؟")

بدون حواجز حماية، يمكن أن يؤدي خطأ واحد في المطالبة إلى آلاف رسائل Slack أو مسح البيانات عن طريق الخطأ.

5. لا توجد إعادة محاولة أو تقييد أو حصص في بيئة الإنتاج

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

• تتجاوز حدود المعدل
  
• تثقل كاهل الخدمات بإعادة المحاولات
  
• تعرض الأدوات الحساسة لسوء الاستخدام
  

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

• المصادقة + الوصول المستند إلى الرموز المميزة
• التحكم في الوصول المستند إلى الدور (RBAC) لكل نموذج ومستخدم ومؤسسة وأداة
• المراقبة والتتبع
• الحصص والحدود واستراتيجيات إعادة المحاولة
• سير عمل الموافقات للإجراءات الحساسة

هذا بالضبط ما توفره بوابة TrueFoundry.

من العروض التوضيحية بخادم واحد إلى سير عمل الوكلاء على مستوى المؤسسات

في الـ النصف الأول من هذه المقالة تعلمنا ما هو بروتوكول النموذج والسياق (Model-Context-Protocol) واستخدمنا خادم Mongo mcp لأتمتة منصة GRC قديمة. هذا المثال البسيط رائع ليوم عمل مكثف، لكنه سرعان ما يواجه عقبات واقعية:

بوابة TrueFoundry بوابة الذكاء الاصطناعي تجمع البنية التحتية المفقودة—سجل MCP، ومصادقة مركزية، والتحكم في الوصول المستند إلى الأدوار (RBAC)، وضوابط الحماية، والمراقبة الشاملة—حتى تتمكن الفرق من الانتقال من "وكيل مرحبًا بالعالم" إلى الإنتاج بأمان وبشكل متكرر.

ما تضيفه البوابة بالإضافة إلى MCP الخام

تضع TrueFoundry واحدة من أفضل بوابات MCP كلوحة تحكم تتوسط بين وكلائك (أو واجهة مستخدم الدردشة) وكل خادم MCP ومزود LLM مسجل.

تشمل القدرات الرئيسية:

1. سجل MCP المركزي – أضف الخوادم العامة أو المستضافة ذاتيًا مرة واحدة؛ واكتشفها في كل مكان 
2. بيانات اعتماد موحدة – أنشئ رمزًا واحدًا لرمز وصول شخصي (PAT) أو رمز حساب افتراضي (VAT) مخصص للجهاز يتم استبداله تلقائيًا برموز OAuth/الرأس الخاصة بكل خادم في الخلفية 
3. تحكم دقيق في الوصول المستند إلى الدور (RBAC) – يقيد أي المستخدمين أو التطبيقات أو البيئات يمكنهم رؤية أو تنفيذ أي أدوات 
4. بيئة اختبار الوكيل وعميل MCP المدمج – نماذج أولية سريعة دون كتابة سطر واحد من التعليمات البرمجية 
5. قابلية المراقبة وحواجز الحماية – زمن الاستجابة، التكلفة، التتبع، سير عمل الموافقات، حدود المعدل، والتخزين المؤقت مدمجة 

اعتبره بمثابة بوابة API + شبكة الخدمات + مخزن الأسرار لبيئة MCP الناشئة. "كما ورد في دليل مصادقة خادم MCP، تتولى البوابة (Gateway) تخزين بيانات الاعتماد ودورة حياة الرمز المميز تلقائيًا."

تطبيق عملي: تسجيل خادم MCP الأول الخاص بك

الخطوة الأولى في واجهة المستخدم هي إنشاء مجموعة—على سبيل المثال، dev-mcps أو prod-mcps. تتيح لك المجموعات ربط قواعد RBAC وسير عمل الموافقة المختلفة ببيئات مختلفة.

"يمكنك اتباع دليل البدء السريع لخادم TrueFoundry MCP للحصول على خطوات مفصلة."

بوابة الذكاء الاصطناعي (AI Gateway) ➜ خوادم MCP ➜ "إضافة مجموعة خوادم MCP جديدة

name: prod-mcps
   access control:
       - Manage: SRE-Admins
       - User  : Prod-Runtime-Service-Accounts

داخل المجموعة، اختر إضافة/تعديل خادم MCP واملأ ثلاثة أمور: 

يمكنك بسهولة إضافة:

• بدون مصادقة خوادم تجريبية (على سبيل المثال، الآلة الحاسبة)
• مصادقة الرأس الخوادم التي تقبل مفتاح API ثابتًا (على سبيل المثال، Hugging Face) 
• أي عدد من الخوادم المستقبلية (Atlassian، Datadog، الخدمات المصغرة الداخلية)

خلف الكواليس، تخزن البوابة بيانات الاعتماد في مخزنها السري وتتولى تحديث الرمز المميز.

المصادقة والتحكم في الوصول المستند إلى الدور

تدعم TrueFoundry ثلاثة أنظمة مصادقة لكل خادم MCP:

“يتم وصف هذه الأنماط بمزيد من التفصيل في وثائق مصادقة خادم MCP.”

بمجرد تسجيل الخادم، أنت لا تسلم الرموز المميزة الخام لكل مطور. بدلاً من ذلك، يقومون بالمصادقة مرة واحدة إلى البوابة ويتلقون:

• PAT – محدود النطاق للمستخدم، سهل الاستخدام، مناسب لـ CLI / التجارب
• VAT – محدود النطاق لحساب الخدمة، مقيّد بخوادم محددة، مثالي لتطبيقات الإنتاج 

تتحقق البوابة من الرمز المميز للمكالمة مقابل:

1. على مستوى المجموعة الصلاحيات (هل يمكن لهذا المستخدم الوصول إلى أي خادم في prod-mcps؟)
2. على مستوى الخادم الصلاحيات (هل slack-mcp مدرج في القائمة البيضاء؟)
3. على مستوى الأداة الصلاحيات (هل يمكنهم استدعاء sendMessageToChannel؟)

إذا فشل أي تحقق، يتم رفض الطلب قبل وصوله إلى مساحة عمل Slack الخاصة بك.

من بيئة الاختبار إلى الكود: واجهة برمجة تطبيقات الوكيل

بعد التجربة في واجهة المستخدم، يمكنك النقر على “مقتطف كود واجهة برمجة التطبيقات” لتوليد أمثلة عمل بلغات Python أو JS أو cURL. فيما يلي نص JSON مختصر يربط ثلاثة خوادم معًا (GitHub، Slack، Calculator):

POST/api/llm/agent/responses

{
  "model": "gpt-4o",
  "stream": true,
  "iteration_limit": 5,
  "messages": [
    {
      "role": "user",
      "content": "Summarize open PRs on repo X and DM me the top blockers."
    }
  ],
  "mcp_servers": [
    {
      "integration_fqn": "truefoundry:prod-mcps:github-mcp",
      "tools": [ {"name": "listPullRequests"}, {"name": "createComment"} ]
    },
    {
      "integration_fqn": "truefoundry:prod-mcps:slack-mcp",
      "tools": [ {"name": "sendMessageToUser"} ]
    },
    {
      "integration_fqn": "truefoundry:common:calculator-mcp",
      "tools": [ {"name": "add"} ]
    }
  ]
}

“يمكنك العثور على مثال مشابه في دليل وكيل الكود لاستخدام خادم MCP، والذي يتضمن أيضًا مقتطفات Python و JS كاملة.”

تدفق الاستجابة تتداخل:

1. مساعد وحدات رمزية (استدلال نموذج اللغة الكبير)
2. استدعاء أداة كتل (اسم الدالة + وسائط تزايدية)
3. نتيجة الأداة أحداث (مخرجات JSON) 

يتيح لك هذا بناء تفاعلية واجهات مستخدم تعرض كل خطوة من حلقة الوكيل في الوقت الفعلي.

قابلية المراقبة، الضوابط والسياسة

حتى وكيل "مرحباً بالعالم" يمكن أن يكلف أموالاً حقيقية ويسبب أضراراً حقيقية. تقدم TrueFoundry قابلية مراقبة من الدرجة الأولى:

• لوحات معلومات الكمون / الأخطاء – TTFT، كمون المهام، أخطاء HTTP، إعادة محاولات الأداة 
• تتبع الوحدات الرمزية والتكلفة – تخصيص الإنفاق لكل نموذج، لكل فريق، لكل علامة ميزة 
• تتبعات OpenTelemetry – نطاقات متتالية عبر الوكيل، وكيل MCP، ونماذج اللغات الكبيرة (LLM) 
• حدود المعدل والتخزين المؤقت – لمنع الحلقات الجامحة وإعادة استخدام نتائج البحث المتطابقة على الويب
• خطافات الحماية – لفرض تنقية معلومات التعريف الشخصية (PII)، وفلاتر المحتوى غير اللائق (NSFW)، أو "موافقة بشرية" على أي أداة ضارة 

جميع المقاييس جاهزة للاستخدام؛ لا حاجة لوكلاء جانبيين أو مصدرين مخصصين.

دعم جميع بروتوكولات نقل MCP (HTTP وSTDIO)

لا تزال العديد من خوادم المصادر المفتوحة تستخدم stdio (stdin/stdout) بدلاً من HTTP. توصي TrueFoundry بتغليفها باستخدام mcp-proxy ونشرها كخدمة عادية 

# wrap a Python stdio server
mcp-proxy --port 8000 --host 0.0.0.0 --server stream python my_server.py

تتوفر قوالب جاهزة لخوادم Notion وPerplexity، بالإضافة إلى ملفات تعريف K8s لصور Node أو Python. بمجرد استخدام الوكيل، يكون التسجيل مطابقًا لأي نقطة نهاية HTTP MCP أخرى.

“دليل TrueFoundry لـ خادم MCP STDIO يغطي هذا النهج للوكالة ويوفر قوالب النشر.”

شرح تفصيلي كمثال: روبوت الامتثال للمؤسسات

لنعد إلى نظام GRC القديم لكن لنرفع مستوى الطموح:

"حافظ على تحديث أدلة الامتثال لدينا. إذا تغير ملف سياسة في GitHub، خزّن الفرق في MongoDB، أنشئ تذكرة Jira، وانشر ملخصًا في Slack."

الخوادم المعنية

التدفق

1. GitHub webhook يستدعي دالة سحابية.
2. تستدعي الدالة Agent API (VAT token) مع تمكين الخوادم الأربعة.
3. LLM يستنتج ← يستدعي github.getFileDiff ← mongo.insertDocument ← jira.createIssue ← slack.sendMessage.
4. يتم بث كل استدعاء أداة ونتيجته مرة أخرى؛ وتلتقط قابلية الملاحظة زمن الاستجابة لكل قفزة.
5. إذا كان الفرق أكبر من x (عدد معين من أسطر التعليمات البرمجية، كحد فاصل)، فإن حاجز حماية يدرج "يتطلب موافقة يدوية" ويوقف التنفيذ مؤقتًا؛ يمكن لمسؤول الأمن الموافقة عبر واجهة مستخدم البوابة (Gateway UI).

الحوكمة

• رمز VAT المرفق بالدالة يرى فقط الخوادم الأربعة المذكورة—أقل امتياز.
• فصل التطوير و الإنتاج تتيح لك المجموعات الاختبار مقابل Jira تجريبي و Slack مرحلي.
• يمكن للمدققين إعادة تشغيل أي حادث: يتم الاحتفاظ بالتتبعات + حمولات JSON الكاملة لمدة 30 يومًا افتراضيًا.

توسيع النظام البيئي: بناء خادم MCP الخاص بك

نظرًا لأن MCP هو مجرد JSON-RPC عبر HTTP أو stdio، يمكن لأي خدمة داخلية عرض الأدوات، إليك مثال صغير: 

• ضع هذه الحاوية في مجموعة Kubernetes الخاصة بك.
• سجّله في مجموعة التطوير مع بلا مصادقة أثناء التطوير.
• غيّر إلى مصادقة الرأس أو OAuth2 قبل نقله إلى prod-mcps.

منذ تلك اللحظة فصاعدًا، يمكن لكل وكيل في شركتك تحليل ضوابط الامتثال بنفس سهولة الاستخدام تمامًا كما هو الحال مع Slack أو GitHub.

ورقة الغش لأفضل الممارسات

"تم تكييف هذه الورقة من نظرة عامة على بروتوكول MCP من TrueFoundry، وتساعد هذه الإرشادات على ضمان عمليات نشر آمنة وموثوقة."

الخاتمة 

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

الأسئلة المتكررة

ما هو سجل MCP في أنظمة الذكاء الاصطناعي؟

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

ما الفرق بين سجل MCP وبوابة الذكاء الاصطناعي؟

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

هل يمكن لبوابة الذكاء الاصطناعي أن تعمل بدون سجل MCP؟

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

كيف تفرض بوابة الذكاء الاصطناعي السياسات من سجل MCP؟

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