أفضل 10 بوابات ووكلاء MCP للذكاء الاصطناعي المحلي في عام 2026

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

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

ما هي بوابة MCP، ولماذا يحتاج إليها الذكاء الاصطناعي المحلي؟

يوفّر بروتوكول سياق النموذج لعملاء الذكاء الاصطناعي طريقة قياسية لاكتشاف الأدوات والموارد والمطالبات واستدعائها. ولا يفرض البروتوكول وجود بوابة في كل عملية نشر.

إذا كنت تشغّل عميلًا واحدًا للذكاء الاصطناعي وخادمًا أو خادمي MCP، فعادةً ما تكون الاتصالات المباشرة أبسط:

عميل الذكاء الاصطناعي
   |
   +---- MCP لنظام الملفات
   |
   +---- GitHub MCP

تظهر المشكلة عندما يتضاعف كلا الجانبين.

Claude Code ----\
Codex -----------\
OpenClaw ---------> بوابة MCP
Cline ------------/      |
                     +----+-------+-------+
                     |            |       |
                  GitHub       الملفات    قاعدة البيانات
                    MCP         MCP       MCP

بدلًا من إعداد GitHub ونظام الملفات وقاعدة البيانات والمتصفح والأتمتة وخوادم MCP الداخلية بشكل منفصل في كل عميل، تصبح البوابة طبقة التحكم المشتركة.

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

ويصبح السؤال المعماري الأهم هو:

نية النموذج
     |
     v
بوابة MCP
     |
المصادقة / السياسة / تصفية الأدوات
بيانات الاعتماد / السجلات / التوجيه
     |
     v
الأدوات المميّزة

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

كيف صنّفنا أفضل بوابات MCP والوكلاء الوسيطين

هذه ليست قائمة متصدرين مرتبة حسب نجوم GitHub، كما أن المشاريع العشرة لا تحل جميعها المشكلة نفسها تمامًا.

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

• إمكانية الاستضافة الذاتية: هل يمكنك تشغيل البوابة على بنية تحتية تتحكم بها؟
• تجميع MCP: هل يمكن أن تظهر خوادم MCP متعددة خلف نقطة نهاية واحدة؟
• تصفية الأدوات: هل يمكنك تقييد الأدوات التي يراها الوكيل فعليًا؟
• المصادقة والتفويض: هل يدعم هوية العميل أو OAuth أو الرموز المميزة أو RBAC أو قوائم التحكم في الوصول (ACLs) أو محركات السياسات؟
• معالجة بيانات الاعتماد: هل يمكن توحيد الأسرار بدلًا من نسخها إلى كل عميل من عملاء الذكاء الاصطناعي؟
• دعم النقل: هل يمكنه العمل عبر stdio أو SSE أو HTTP القابل للبث أو أنماط نشر أخرى؟
• العزل: هل يمكن فصل خوادم MCP أو تنفيذ الأدوات عن المضيف؟
• قابلية المراقبة: هل تتوفر السجلات أو آثار التتبع أو المقاييس أو سجلات التدقيق؟
• مرونة النشر: هل يناسب حاسوبًا محمولًا أو خادمًا منزليًا أو مضيف Docker أو جهازًا افتراضيًا أو عنقود Kubernetes؟
• التوجه الحالي: هل لا يزال المشروع ذا صلة بمكدس MCP المتغير بسرعة في عام 2026؟

الترتيب الرقمي تحريري وليس نتيجة معيار قياس اصطناعي.

أفضل 10 بوابات ووكلاء MCP للذكاء الاصطناعي المحلي في لمحة

1. بوابة Docker MCP — الأفضل عمومًا للذكاء الاصطناعي المحلي القائم على Docker

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

تقع بوابة Docker بين عملاء الذكاء الاصطناعي وخوادم MCP، وتعمل على توحيد الإعدادات وبيانات الاعتماد والتوجيه والمصادقة وإدارة دورة حياة الخوادم.

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

يمكن للبوابة أيضًا إتاحة أدوات محددة فقط بدلًا من إغراق العميل بكل أداة من كل خادم. تتضمن أدوات MCP في Docker عناصر تحكم في الملفات التعريفية والأدوات، صُممت لتقليل الضوضاء والاستخدام غير الضروري للرموز.

يمكن للعميل الاتصال ببوابة واحدة:

{
  "mcpServers": {
    "MCP_DOCKER": {
      "command": "docker",
      "args": ["mcp", "gateway", "run"]
    }
  }
}

بينما يتولى Docker معالجة عمليات خادم MCP خلفه.

يناسب هذا خادمًا منزليًا بشكل خاص:

Claude Code / Codex / Cline
            |
     Docker MCP Gateway
            |
    +-------+-------+
    |       |       |
 نظام الملفات GitHub  n8n
 حاوية  خادم  خادم

الأفضل لـ: مستخدمي الذكاء الاصطناعي المحلي الذين يشغّلون Docker بالفعل ويريدون بوابة واحدة، مع تنفيذ معزول لخوادم MCP، ومعالجة الأسرار، وتصفية الأدوات، وسجلات مركزية.

المقايضة: يوفّر Docker الآن العديد من تجارب MCP ذات الصلة، بما في ذلك MCP Toolkit وGateway وSandboxes وميزات حوكمة أحدث. وبعض وظائف حوكمة الذكاء الاصطناعي في Docker مقيدة بشكل منفصل، لذا تحقّق من مجموعة الميزات التي يتضمنها نشرُك فعليًا بدلًا من افتراض توفر كل إمكانات Docker MCP في كل إصدار.

2. ToolHive — أفضل منصة كاملة لإدارة MCP مستضافة ذاتيًا

ToolHive يتجاوز بكثير الوكيل الخفيف.

تنقسم بنيته إلى عدة طبقات:

• البوابة: إتاحة نقاط نهاية MCP مُتحكَّم بها للعملاء؛
• السجل: الحفاظ على فهرس بخوادم MCP والمهارات المعتمدة؛
• بيئة التشغيل: نشر خوادم MCP وتشغيلها؛
• البوابة: توفير واجهة للإدارة والاكتشاف.

يمكن للبوابة تجميع أدوات متعددة، والتكامل مع موفري الهوية OAuth/OIDC، وتطبيق سياسات الوصول، وتصفية الأدوات والأوصاف، ومركزة عمليات التدقيق.

يمكن لبيئة التشغيل تشغيل خوادم MCP محليًا عبر Docker أو Podman، بينما يوسّع مشغّل Kubernetes النهج نفسه ليشمل العناقيد الأكبر. ويمنحه دعم OpenTelemetry وPrometheus قصة تشغيلية أقوى بكثير من وكيل عكسي أساسي.

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

بدلًا من ذلك:

سجل موثوق
      |
    بيئة التشغيل
      |
 خوادم MCP
      |
   البوابة
      |
+-----+------+------+
Claude     Codex   VS Code

الأفضل لـ: الفرق التي تريد أن تعيش آليات اكتشاف MCP ونشره وأمانه وسياساته وإمكانية رصدِه والوصول إلى البوابة في منصة واحدة مستضافة ذاتيًا.

المقايضة: يُعد ToolHive منصة متكاملة أكثر بكثير مما يحتاجه إعداد لمستخدم واحد. إذا كنت تريد فقط خمسة خوادم خلف نقطة نهاية واحدة، فإن MCPJungle أبسط.

3. agentgateway — الأفضل لحركة مرور MCP وLLM والوكيل إلى الوكيل في طبقة واحدة

agentgateway هو أحد أهم المشاريع التي تجدر متابعتها، لأنه يطرح سؤالًا أكبر:

لماذا تبني بوابة واحدة لـ MCP، وأخرى لواجهات برمجة تطبيقات LLM، وأخرى لحركة البيانات بين الوكلاء؟

تجمع بنيته ثلاث فئات متزايدة الأهمية من حركة البيانات:

الوكيل
  |
  +--> بوابة LLM
  |
  +--> بوابة MCP
  |
  +--> بوابة A2A

بالنسبة إلى MCP، يدعم المشروع اتحاد الأدوات، إلى جانب عمليات نقل stdio وHTTP وSSE وStreamable HTTP. وتشمل خيارات المصادقة OAuth وJWT ومفاتيح API، بينما توفّر RBAC دقيق الصلاحيات، وتحديد معدل الطلبات، وTLS، وOpenTelemetry طبقة الحوكمة.

ويتمتع أيضًا بتركيز مباشر على الذكاء الاصطناعي المحلي: إذ يمكن لـ agentgateway توجيه الاستدلال نحو نماذج مستضافة ذاتيًا وبنية استدلال على Kubernetes، بدلًا من افتراض أن كل استدعاء للنموذج يتجه إلى مزوّد سحابي.

يتكيف المشروع أيضًا بنشاط مع الأجيال الأحدث من بروتوكول MCP، بما في ذلك تغييرات البروتوكول الأكبر بكثير في عام 2026 ومشكلة التوافق التي تنشأ عندما يحدّث العملاء والخوادم في أوقات مختلفة.

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

المقابل: إذا كانت مشكلتك الوحيدة هي توحيد عدد قليل من خوادم MCP المحلية، فقد تكون agentgateway أكثر تعقيدًا معماريًا مما تحتاج إليه.

4. MCPJungle — أفضل بوابة بسيطة مستضافة ذاتيًا لخوادم MCP متعددة

MCPJungle هو على الأرجح أسهل مشروع في هذه القائمة يمكن شرحه:

سجّل خوادم MCP لديك مرة واحدة، ثم اسمح لعملاء الذكاء الاصطناعي بالاتصال بنقطة نهاية واحدة.

GitHub MCP ------\
Postgres MCP -----\
Filesystem MCP ----> MCPJungle ----> /mcp
Browser MCP -------/                    |
n8n MCP ----------/          +----------+---------+
                              Claude   Cursor   Codex

يدعم المشروع خوادم MCP البعيدة وخوادم stdio، مع توفير اكتشاف موحّد للأدوات والمطالبات والموارد.

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

يوفّر MCPJungle أيضًا مسارًا مفيدًا للانتقال من البنية التحتية الشخصية إلى البنية المشتركة. يمكنك البدء باستخدام Docker Compose ونقطة نهاية محلية، ثم الانتقال إلى هويات العملاء، ورموز الوصول، وقوائم السماح الصريحة للخوادم، وPostgreSQL، وOpenTelemetry مع ازدياد أهمية عملية النشر.

وهذا يجعله مناسبًا بشكل خاص للمختبر المنزلي. فلا يتعين عليك البدء بتثبيت Kubernetes أو بناء بنية مؤسسية لإدارة الهوية.

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

المقايضة: ترتبط ميزات الحوكمة الأكثر تقدمًا بأوضاعه الموجهة إلى الإنتاج والمؤسسات، كما أن نموذج الأمان فيه ليس واسع النطاق مثل ToolHive أو agentgateway أو بوابة API ناضجة.

5. IBM ContextForge — الأفضل لاتحاد MCP مع واجهات API والوكلاء الحاليين

تصبح IBM ContextForge مفيدة بشكل خاص عندما لا تتكون بنيتك التحتية بترتيب واضح من خوادم MCP.

تتضمن البيئات الفعلية عادةً مزيجًا من هذه العناصر:

خادم MCP
واجهة REST البرمجية
خدمة gRPC
وكيل A2A
واجهة API داخلية قديمة
       |
       v
  ContextForge
       |
       v
   عملاء الذكاء الاصطناعي

يعمل ContextForge كسجل ووكيل وطبقة اتحاد عبر خدمات MCP وA2A وREST وgRPC.

تتضمن بنيته الحالية وظائف بوابة الأدوات، وترجمة واجهات API، وتوجيه الوكلاء، وقابلية توسعة الإضافات، وتحديد معدل الطلبات، والمصادقة، وإعادة المحاولات، وإمكانية الرصد المستندة إلى OpenTelemetry.

بلغ المشروع مرحلة التوافر العام 1.0 في عام 2026، مع تعزيزات أمنية إضافية، وأعمال على البروتوكول، وتحسينات في الكتالوج، وتغييرات في النشر تركز على بيئات الإنتاج.

يمكن تشغيله عبر حزم Python أو Docker، وتوسيعه ليصل إلى عمليات نشر على Kubernetes وعبر عناقيد متعددة.

الأفضل من أجل: المؤسسات أو المختبرات المنزلية المتقدمة التي تحتاج إلى إتاحة أنظمة REST/gRPC الحالية للوكلاء، من دون إعادة كتابة كل خدمة باعتبارها خادم MCP مخصصًا.

المقايضة: إن ContextForge أوسع نطاقًا من بوابة مخصصة لـ MCP فقط. وتضيف هذه المرونة تعقيدًا تشغيليًا مقارنةً بـ MCPJungle أو Supergateway.

6. بوابة MCP من Microsoft — الأفضل لخوادم MCP المحتفظة بالحالة على Kubernetes

تكون بوابة MCP من Microsoft أكثر ملاءمة عندما تحتاج خوادم MCP نفسها إلى التحول إلى بنية تحتية مُدارة.

يجمع المشروع بين بوابة بيانات ومستوى تحكّم.

توجّه طبقة البيانات حركة مرور MCP، بينما يمكن لطبقة الإدارة تمثيل الخوادم كموارد مُدارة والتعامل مع عمليات النشر والتحديث والحذف.

ميزتها الأبرز هي التوجيه ذي الحالة والواعي بالجلسات.

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

جلسة العميل A ----> البوابة ----> حاوية MCP 1
جلسة العميل A ----> البوابة ----> حاوية MCP 1

جلسة العميل B ----> البوابة ----> حاوية MCP 2

يتضمن المشروع أيضًا التفويض، والقياس عن بُعد، والتكامل مع التحكم في الوصول، وإدارة دورة الحياة المصممة لبيئات Kubernetes.

الأفضل لـ: الفرق التي تستخدم Kubernetes بالفعل وتدير أساطيل من خوادم MCP ذات الحالة أو المُدارة ديناميكيًا.

المقايضة: ليست هذه الخيار الواضح لخادم منزلي واحد. فعادةً ما تكون بوابة Docker MCP أو MCPJungle أسهل بكثير في التشغيل.

7. بوابة OpenZiti MCP — الأفضل للوصول الآمن عن بُعد إلى أدوات MCP الخاصة

تحل بوابة OpenZiti MCP إحدى أكثر مشكلات الذكاء الاصطناعي المحلي عملية:

ماذا يحدث عندما لا يكون الوكيل وخادم MCP على شبكة LAN نفسها؟

يبدو الإعداد الخاص الشائع على النحو التالي:

الحاسوب المحمول / عميل الذكاء الاصطناعي
        |
      الإنترنت
        |
 الخادم المنزلي / NAS
        |
 أدوات MCP الخاصة

غالبًا ما يتمثل الحل التقليدي في عرض نقطة نهاية HTTPS، وتهيئة قواعد جدار الحماية، وإعداد VPN، أو وضع وكيل عكسي آخر أمام الخدمة.

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

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

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

الأفضل لـ: المستخدمين الذين يريدون الوصول عن بُعد إلى أدوات MCP الخاصة دون تعريضها مباشرةً للإنترنت العام.

المقايضة: أنت تعتمد نموذج شبكات OpenZiti/zrok كجزء من الحل. وإذا كانت شبكة LAN خاصة تقليدية أو شبكة VPN موجودة تحل مشكلة الاتصال بالفعل، فقد يكون هذا غير ضروري.

8. MetaMCP — الأفضل لتقليل الحمل الزائد لسياق مخططات الأدوات

MetaMCP يعالج مشكلة مختلفة تتعلق بتوسّع MCP.

لنفترض أن وكيلًا يتصل مباشرةً بـ:

MCP لـ Playwright      52 أداة
MCP لقواعد البيانات      20 أداة
MCP لـ GitHub      30 أداة
MCP لنظام الملفات      15 أداة
MCP للمراقبة      18 أداة

قد يحتاج النموذج إلى تلقي مجموعة كبيرة من مخططات أدوات JSON قبل أن يبدأ حتى في إنجاز عمل مفيد.

وهذا يستهلك السياق وقد يجعل اختيار الأدوات أكثر تشويشًا.

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

تصبح البنية كما يلي:

               +-- Playwright
               +-- GitHub
نموذج لغوي محلي --> MetaMCP -- قاعدة البيانات
               +-- الملفات
               +-- المزيد من الخوادم

يرى النموذج: 4 أدوات وصفية

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

توضح وثائق MetaMCP كيف يمكن أن يظل الحمل الزائد للمخططات ثابتًا تقريبًا عند إضافة خوادم MCP فرعية إضافية، بدلًا من نموه خطيًا مع كل أداة لاحقة.

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

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

9. بوابة Kong للذكاء الاصطناعي — الأفضل عندما تكون لديك بوابة API قيد التشغيل بالفعل

بوابة Kong للذكاء الاصطناعي هي طرح مختلف عن المشاريع التي تركز أولًا على المختبر المنزلي والمذكورة أعلاه.

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

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

يبدو النمط المفيد على النحو التالي:

عملاء الذكاء الاصطناعي
     |
Kong AI Gateway
     |
+----+-------+--------+
|            |        |
MCP A       MCP B    واجهة REST برمجية
|            |
الأدوات       الأدوات

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

الأنسب لـ: الفرق التي تستخدم Kong بالفعل وتريد دمج حوكمة MCP في استراتيجية قائمة لبوابات واجهات برمجة التطبيقات والذكاء الاصطناعي.

المقابل: يختلف توفر ميزة MCP في Kong بحسب النشر وإعداد المنتج، كما أن بعض الوصفات الأحدث لـ MCP الآمن تفرض حاليًا قيودًا خاصة بـ Konnect. وليس الخيار الأبسط لخادم Docker محلي صغير.

10. Supergateway — أفضل جسر خفيف لنقل MCP

Supergateway يندرج ضمن هذه القائمة لسبب أضيق بكثير: توافق النقل.

بُني قدر كبير من برمجيات MCP المبكرة حول stdio. ويكون ذلك ملائمًا عندما يعمل خادم MCP كعملية فرعية على الجهاز نفسه الذي يعمل عليه عميل الذكاء الاصطناعي.

ويصبح الأمر معقدًا عندما ينبغي أن يعمل الخادم على وحدة تخزين متصلة بالشبكة أو جهاز افتراضي أو مضيف حاويات أو جهاز آخر على الشبكة.

يمكن لـ Supergateway الربط بين وسائل نقل MCP مثل:

stdio
  |
  +--> SSE
  |
  +--> WebSocket
  |
  +--> HTTP قابل للبث

ويمكنه ترجمة HTTP القابل للبث البعيد مرة أخرى إلى stdio للعملاء الذين ما زالوا يتوقعون عملية محلية.

على سبيل المثال، يمكن إتاحة خادم ملفات محلي عبر stdio باستخدام HTTP القابل للبث:

npx -y supergateway \
  --stdio "npx -y @modelcontextprotocol/server-filesystem ./data" \
  --outputTransport streamableHttp \
  --port 8000

كما يدعم الرؤوس والمصادقة عبر Bearer ونقاط نهاية فحص الحالة وجلسات HTTP قابلة للبث ذات الحالة وخيارات نشر متعددة.

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

المقابل: Supergateway وكيل نقل، وليس منصة حوكمة متكاملة. وهو ليس بديلًا عن ToolHive أو Docker MCP Gateway أو agentgateway عندما تحتاج إلى سياسات مركزية وإدارة الهوية ودورة الحياة والتدقيق.

أي بوابة MCP ينبغي أن تختار؟

Docker MCP Gateway مقابل ToolHive مقابل MCPJungle

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

اختر Docker MCP Gateway عندما يكون Docker أساس حزمة الذكاء الاصطناعي المستضافة ذاتيًا لديك بالفعل، ويكون عزل الحاويات مهمًا.

اختر ToolHive عندما يحتاج عدة مطورين إلى كتالوج MCP موثوق، ونشر مركزي، وتكامل مع الهوية، وسياسات، ومراقبة.

اختر MCPJungle عندما تكون مشكلتك الرئيسية ببساطة هي أن يتوقف Claude وCodex وCursor والعملاء الآخرون عن حمل إعدادات MCP مكررة.

بوابة MCP مقابل الوكيل الوسيط مقابل المجمّع مقابل جسر النقل

لا تزال المصطلحات المحيطة ببنية MCP التحتية غير متسقة، لذا قد تكون أسماء المنتجات مضللة وحدها.

قد ينفّذ المشروع عدةً من هذه المهام في آنٍ واحد. والسؤال المفيد ليس ما الاسم الذي يطلقه المستودع على نفسه، بل أي مشكلة تحكم يحلها فعليًا.

كيفية بناء بنية بوابة MCP محلية

لا يلزم أن يبدأ الإعداد المحلي العملي بمنصة ضخمة.

ابدأ بأربع طبقات:

عملاء الذكاء الاصطناعي
Claude Code / Codex / OpenClaw
             |
             v
        بوابة MCP
             |
    +--------+--------+
    |        |        |
 الملفات     GitHub   الأتمتة
 MCP       MCP       MCP
    |
التخزين المحلي / NAS

أبقِ البوابة قريبة من الأدوات

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

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

افصل بين استضافة النموذج واستضافة MCP

لا يلزم أن تعمل بوابة MCP على الجهاز نفسه الذي يعمل عليه نموذج اللغة الكبير.

مضيف الوكيل             خادم GPU
    |                       |
بوابة MCP              Ollama
    |                     vLLM
الأدوات المحلية
    |
الملفات / قواعد البيانات / واجهات API

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

استخدم مجموعات أدوات منتقاة بدلًا من عرض كل شيء

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

أنشئ ملفات تعريف أو مجموعات أدوات منفصلة:

coding
  - github
  - filesystem-dev
  - docs

research
  - browser
  - papers
  - local-knowledge

home-ops
  - monitoring
  - home-assistant
  - docker-readonly

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

لماذا تهم تصفية الأدوات للنماذج المحلية

الأمان ليس السبب الوحيد للحد من الأدوات.

السياق عامل آخر.

قد تساهم كل أداة باسم ووصف ومعاملات ومخطط JSON وبيانات وصفية أخرى في مجموعة الأدوات المتاحة للنموذج.

مع عدد قليل من الأدوات، يكون هذا الأمر بسيطًا.

مع المئات، قد يصبح ذلك جزءًا من ميزانية الموجه:

5 خوادم MCP
× 20 أداة
= 100 مخطط أداة

20 خادم MCP
× 20 أداة
= 400 مخطط أداة

وقد يقلل ذلك من السياق المتاح للمحادثة، وتعليمة المستودع البرمجي، والمستندات المسترجعة، والاستدلال، والإخراج.

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

هناك ثلاثة حلول رئيسية:

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

تركّز Docker MCP Gateway وToolHive على التصفية والإتاحة المنسّقة. وتوفر MCPJungle مجموعات الأدوات. أما MetaMCP فتذهب إلى أبعد من ذلك بتحويل العديد من الأدوات الفرعية إلى سطح صغير ومستقر من الأدوات الوصفية.

ويزداد هذا أهمية عندما يتصل MCP بـقاعدة معرفة محلية، لأن مخططات الأدوات تتنافس الآن مع المستندات والسياق المسترجع على نافذة النموذج نفسها.

قائمة التحقق الأمنية لبوابة MCP للذكاء الاصطناعي المحلي

لا تكون البوابة مفيدة لمجرد مرور كل حركة المرور من خلالها. تأتي القيمة مما تفرضه البوابة فعليًا.

صادِق على العميل

ينبغي أن تعرف البوابة ما إذا كان المستدعي هو Codex على جهاز مطوّر، أو وكيلًا يعمل دائمًا، أو عملية CI، أو خدمة أخرى.

لا تعتبر «داخل شبكتي المحلية» هوية.

فوّض الخوادم والأدوات بشكل منفصل

لا يعني الوصول إلى خادم GitHub MCP بالضرورة الوصول إلى كل أدوات GitHub.

قد تسمح سياسة مفيدة بما يلي:

read_issue
list_pull_requests
search_code

مع الرفض:

merge_pull_request
delete_repository
change_branch_protection

أبقِ بيانات الاعتماد خارج ملفات إعداد الوكلاء

تتمثل إحدى أكبر فوائد البوابة في نقل مفاتيح API وبيانات اعتماد الخدمات بعيدًا عن كل عميل ذكاء اصطناعي على حدة.

التدفق المثالي هو:

الوكيل
  |
طلب أداة
  |
البوابة
  |
احقن بيانات اعتماد محددة النطاق
  |
خادم MCP

لا يحتاج النموذج إلى رؤية الرمز المميز الأساسي.

اعزل خوادم MCP غير الموثوقة

خادم MCP هو برنامج قابل للتنفيذ.

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

سجّل استدعاءات الأدوات، وليس أخطاء HTTP فقط

عندما يغيّر وكيل ملفًا أو يحدّث نظامًا خارجيًا، تحتاج إلى معلومات كافية لإعادة بناء:

• أي عميل أرسل الطلب؛
• أي أداة تم اختيارها؛
• أي الوسائط تمت الموافقة عليها؛
• ما النتيجة التي أُعيدت؛
• ما إذا كان الأثر الجانبي قد اكتمل فعلًا.

ولهذا السبب تُعد قابلية المراقبة عاملًا أساسيًا في التقييم، وليست إضافة حصرية للمؤسسات.

أزِل مسارات التجاوز

لا تحدد بوابة MCP المُعدّة بعناية حد الأمان الحقيقي إذا كان الوكيل نفسه يملك أيضًا:

• صدفة مضيف غير مقيّدة؛
• مقبس Docker قابل للكتابة؛
• بيانات اعتماد المسؤول؛
• وصول بصلاحيات الجذر إلى قاعدة البيانات؛
• اتصال MCP آخر غير مقيّد.

لا يكون حد الثقة لتنفيذ الأدوات ذا معنى إلا عندما تمر الإجراءات ذات الامتيازات فعليًا من خلاله.

هل تحتاج فعلًا إلى بوابة MCP؟

على الأرجح لا، إذا كان إعدادك يبدو هكذا:

عميل ذكاء اصطناعي واحد
   |
خادما MCP

إضافة بوابة ستنشئ خدمة أخرى لتثبيتها وتحديثها وتأمينها ومراقبتها وتصحيح أخطائها.

تبدأ البوابة في أن تصبح منطقية عندما يتحقق عدد من هذه الشروط:

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

قاعدة مفيدة هي:

عميل واحد + خادمان
        ↓
الاتصال المباشر بـMCP كافٍ

عدة عملاء + عدة خوادم
        ↓
تبدأ البوابة في تقديم المساعدة

الفرق + بيانات الاعتماد + السياسات + التدقيق
        ↓
البوابة تتحول إلى بنية تحتية

أين يندرج Soth MCP Proxy؟

يستحق Soth MCP Proxy المتابعة أيضًا، ولا سيما إذا كانت أولويتك هي وضع طبقة لسياسات الأمان أمام عملية نشر MCP موجودة.

يتضمن تصميمها الحالي فرض السياسات باستخدام OPA/Rego، وتسجيلًا دائمًا للتدقيق، وعناصر تحكم في الجلسات، ومقاييس Prometheus، ونقاط نهاية للصحة، وTLS.

تلك بنية مفيدة:

الوكيل
  |
وكيل Soth للسياسات
  |
خادم MCP موجود

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

في الوقت الحالي، اعتبرها وكيلًا أمنيًا خفيفًا وواعدًا، لا منصة ناضجة لإدارة MCP.

التحول في عام 2026: بوابة MCP تتحول إلى بنية تحتية للوكلاء

كان سؤال MCP الأول هو:

كيف أوصل مساعد الذكاء الاصطناعي الخاص بي بهذه الأداة؟

السؤال الأحدث هو:

كيف أحكم كل أداة يستخدمها كل وكيل؟

هذا يغيّر البنية.

2025

الوكيل
  |
خادم MCP
  |
الأداة


2026

الوكلاء
  |
بوابة الوكلاء / MCP
  |
الهوية
السياسات
التوجيه
بيانات الاعتماد
اكتشاف الأدوات
قابلية المراقبة
ترجمة البروتوكولات
  |
العديد من خوادم MCP
  |
واجهات برمجة التطبيقات / الملفات / قواعد البيانات / الخدمات

لهذا السبب، لم تعد مشاريع مثل agentgateway وContextForge تكتفي بـMCP، بل تتوسع أيضًا نحو توجيه النماذج وبروتوكولات التواصل بين الوكلاء.

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

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

الحكم النهائي

اختر Docker MCP Gateway إذا كان مكدس الذكاء الاصطناعي المحلي لديك يعمل بالفعل على Docker وتريد مزيجًا عمليًا من إدارة دورة حياة خوادم MCP وعزل الحاويات وبيانات الاعتماد والتصفية والوصول المركزي.

اختر ToolHive إذا كانت MCP تتحول إلى بنية تحتية مشتركة للفريق وتحتاج إلى طبقة للسجل وبيئة التشغيل والبوابة والسياسات وقابلية المراقبة، بدلًا من وكيل واحد فقط.

اختر agentgateway إذا كنت تتوقع أن تتقارب حركة MCP وحركة النماذج والتواصل بين الوكلاء خلف بوابة واحدة مصممة للذكاء الاصطناعي.

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

اختر IBM ContextForge إذا كانت بيئتك تتضمن واجهات REST أو gRPC حالية ينبغي أن تصبح قابلة للاستخدام إلى جانب MCP وخدمات الوكلاء.

اختر Microsoft MCP Gateway إذا كانت مجموعة خوادم MCP لديك تعمل بالفعل ضمن Kubernetes وتحتاج إلى توجيه يراعي الجلسات والتحكم في دورة الحياة.

اختر OpenZiti MCP Gateway إذا احتاجت الوكلاء إلى الوصول عن بُعد إلى أدوات MCP الخاصة من دون كشف هذه الخدمات على منافذ عامة.

اختر MetaMCP إذا كانت مشكلتك الأكبر لا تتعلق بالاتصال، بل بعدد مخططات الأدوات التي تستهلك سياق النماذج المحلية وتربكها.

اختر Kong AI Gateway عندما ينبغي أن تصبح MCP فئة أخرى من حركة المرور الخاضعة للحوكمة ضمن منصة Kong الحالية لواجهات API والذكاء الاصطناعي.

اختر Supergateway عندما تحتاج ببساطة إلى جسر واضح بين وسائل نقل MCP عبر stdio والشبكة.

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

الأسئلة الشائعة

ما هي بوابة MCP؟

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

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

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

ما أفضل بوابة MCP لخادم منزلي؟

تُعدّ Docker MCP Gateway وMCPJungle من أقوى الخيارات للبدء. تناسب Docker MCP Gateway المستخدمين الذين يشغّلون Docker بالفعل، إذ توفر عزل الحاويات وإدارة دورة حياتها. أما MCPJungle فهي جذابة عندما يكون الهدف الأساسي وضع عدة خوادم MCP خلف نقطة نهاية واحدة واضحة.

ما الفرق بين بوابة MCP ووكيل MCP؟

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

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

نعم. تتمثل إحدى المزايا الرئيسية للبوابة في السماح لـ Claude وCodex وCursor وCline وOpenClaw والوكلاء المخصصين بإعادة استخدام بنية MCP التحتية المشتركة بدلًا من إعداد كل خادم MCP على حدة في كل عميل.

هل يمكن لبوابة MCP تقليل استخدام الرموز؟

نعم، إذا كانت تصفي مخططات الأدوات أو تجردها قبل وصولها إلى النموذج. يمكن لـ Docker MCP Gateway وToolHive إتاحة مجموعات أدوات منتقاة، ويدعم MCPJungle مجموعات الأدوات، بينما يقلل MetaMCP كتالوج أدوات تابعًا كبيرًا إلى مجموعة صغيرة من الأدوات الوصفية.

ما أفضل بوابة MCP للنماذج المحلية؟

بالنسبة إلى الذكاء الاصطناعي المحلي العام، يُعد Docker MCP Gateway وMCPJungle خيارين عمليين. ويُعد MetaMCP مثيرًا للاهتمام خصوصًا عندما تواجه النماذج المحلية الأصغر صعوبة مع كتالوجات الأدوات الكبيرة، بينما يكون agentgateway مناسبًا عندما تحتاج بنية توجيه الاستدلال المستضاف ذاتيًا وحوكمة MCP إلى العمل ضمن طبقة البنية التحتية نفسها.

هل يمكنني إتاحة خادم MCP يستخدم stdio عبر HTTP؟

نعم. يمكن لـ Supergateway تحويل خوادم MCP التي تستخدم stdio إلى وسائل نقل Streamable HTTP أو SSE أو WebSocket. كما يمكن للبوابات الأخرى توصيل خوادم stdio المحلية أو العمل كوسيط لها لتحويلها إلى نقاط نهاية MCP يمكن الوصول إليها عبر الشبكة.

كيف يمكنني الوصول بأمان إلى خادم MCP خارج شبكتي المنزلية؟

استخدم شبكة خاصة موثّقة أو بوابة مصممة للوصول عن بُعد بدلًا من مجرد إعادة توجيه منفذ عام. صُممت OpenZiti MCP Gateway خصيصًا لإتاحة الوصول عن بُعد إلى خدمات MCP الخاصة عبر طبقة تراكبية عديمة الثقة، من دون كشف الخادم مباشرةً على عنوان IP عام.

هل تُعد بوابة MCP حدًا أمنيًا؟

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

هل ينبغي تشغيل خوادم MCP في Docker؟

تُفيد الحاويات في عزل تبعيات خادم MCP، والوصول إلى نظام الملفات، والوصول إلى الشبكة، واستخدام الموارد. ويجعل كل من Docker MCP Gateway وToolHive تشغيل MCP داخل الحاويات جزءًا محوريًا من نهجهما، لكن الحاويات لا تحل محل المصادقة أو التفويض أو تصفية الأدوات أو التدقيق.

ما الفرق بين MetaMCP وبوابة MCP عادية؟

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