تقع بوابة MCP بين وكلاء الذكاء الاصطناعي لديك وأدواتك، لذلك يهم اختيار مكان تشغيلها. تضع هذه المقارنة Amazon Bedrock AgentCore Gateway وAzure API Management وبوابة MCP مفتوحة المصدر من Microsoft جنبًا إلى جنب من حيث المصادقة والتوجيه والتكلفة وجهد الإعداد.
يعمل وكيلك بشكل جيد مع ثلاث أدوات. ثم يضيف الفريق واجهة API للفوترة، ونظام تذاكر، وفهرس بحث، وعددًا من الخدمات الداخلية، فينتهي الأمر بكل عميل MCP إلى حمل عناوينه الخاصة وبيانات اعتماده الخاصة وفكرته الخاصة عن الطلب الآمن. تحل بوابة MCP هذه المشكلة بوضع نقطة نهاية واحدة خاضعة للتحكم أمام كل أداة. الجزء الصعب هو تحديد مكانها. تقدم AWS بوابة مُدارة مصممة للوكلاء، وتوسّع Azure منتج إدارة API الذي تشغّله فرق كثيرة بالفعل، ويتيح الاثنان لك استضافة وكيل وسيط بنفسك حين تريد تحكمًا كاملًا.
تضع هذه المقارنة الخيارات الفعلية جنبًا إلى جنب: ما الذي تفعله كل منها، وكيف تعمل المصادقة، وكيف تُبنى الفوترة، والخطوات الدقيقة لتشغيل كل واحدة. تتغير أسماء المنتجات والفئات والحدود بسرعة، لذلك تتبع التفاصيل أدناه وثائق المورّد كما كانت في أكتوبر 2026. أعد التحقق من تلك الوثائق قبل أن تلتزم بأي شيء.
البوابة هي وكيل عكسي (reverse proxy) يتحدث Model Context Protocol. يرسل العملاء رسائل JSON-RPC مثل tools/list و tools/call عبر Streamable HTTP، وتقرر البوابة من يُسمح له باستدعاء ماذا، وتحوّل كل استدعاء إلى الخلفية الصحيحة، وتسجّل ما حدث. لا يحتاج وكلاؤك الذكيون أبدًا إلى معرفة ما إذا كانت الأداة موجودة في دالة Lambda، أو في واجهة REST API، أو في حاوية في منطقة أخرى.
بدون بوابة، يشير كل عميل MCP مباشرة إلى كل خادم MCP. عشرة وكلاء وثمانية خوادم تعني ثمانين اتصالًا يجب ضبطها وتأمينها ومراقبتها. مع البوابة، يتصل عشرة عملاء بنقطة نهاية واحدة، وتوزع البوابة الاستدعاءات على الخوادم خلفها. يصبح تبديل خلفية تغييرًا في البوابة بدلًا من إطلاق جديد لكل عميل.
tools/list واحد.💡 نصيحة: اسأل من يستدعي كل أداة وكم مرة. إذا كانت الإجابة الصادقة "مطور واحد، محليًا"، فالبوابة سابقة لأوانها. وحين يظهر فريق ثانٍ أو عميل خارجي، تتوقف عن كونها اختيارية.
وصلت Amazon Bedrock AgentCore إلى الإتاحة العامة في أكتوبر 2025، وAgentCore Gateway هي نقطة الدخول لحركة مرور الوكلاء. تحتوي البوابة على هدف واحد أو أكثر من ثلاث فئات:
tools/list موحدًا واحدًا.model في الطلب الوجهة.تحتاج كل بوابة إلى مُصرِّح وارد. الخيارات هي OAuth مع JWT، وIAM مع AWS Signature Version 4، ووضع "المصادقة فقط" الذي يتحقق من الرموز ويترك التفويض للهدف، وعدم وجود تفويض على الإطلاق للتطوير. يجب أن يستخدم الإنتاج أحد الخيارين الأولين.
بالنسبة لأهداف MCP، تذكر AWS عدة أنواع للمصادر:
تمر الاستدعاءات الصادرة إلى أهداف OpenAPI وMCP عبر مزودي بيانات الاعتماد، يمكنهم تخزين بيانات اعتماد API أو إعدادات OAuth، والتوقيع عبر SigV4، أو تخطي المصادقة للنقاط العامة. ويستخدم هدفا Lambda وSmithy دور التنفيذ الذي ترفقه. وهناك ميزتان إضافيتان تهمان عند التوسع: البحث الدلالي عن الأدوات، الذي يساعد الوكيل على إيجاد الأداة الصحيحة بين مئات الأدوات، ومزامنة القدرات لأهداف MCP.
يتجاوز بعض الفرق الخيار المُدار ويشغّلون وكيل MCP مفتوح المصدر على ECS أو EKS خلف Application Load Balancer. أنت تملك التوسيع والتحديثات الأمنية والتحقق من الرموز والتسجيل، لكنك تحصل أيضًا على توجيه مخصص، وقاعدة شيفرة واحدة يمكن إعادة استخدامها على أي سحابة، وعدم الاعتماد على قائمة ميزات مورّد واحد. يناسب فرق المنصات ذات الخبرة في Kubernetes، ويتحول إلى عبء مكلف لغيرها.
تقدم Azure API Management (APIM) طريقتين مدمجتين لنشر خوادم MCP:
تمر الحوكمة عبر محرك السياسات. تُطبَّق السياسات حاليًا على كل العمليات المعروضة كأدوات في خادم MCP معين، وتذكر Microsoft تحديد المعدل والحصص، والتحقق من JWT عبر Microsoft Entra ID أو مزود هوية آخر، وتصفية عناوين IP، والتخزين المؤقت للاستجابات. تظهر الحركة في Azure Monitor وApplication Insights، ويمكن لـAzure API Center أن يعمل كسجل خاص حتى تجد الفرق الخوادم الموجودة. ويمكن إدارة كل شيء كشيفرة عبر Bicep وTerraform وAzure CLI وقوالب ARM.
الإتاحة واسعة: الفئات الكلاسيكية Developer وBasic وStandard وPremium، وفئات v2 (Basic v2 وStandard v2 وPremium v2)، والبوابة ذاتية الاستضافة لبنيتك التحتية الخاصة. هناك حدّان مهمان. يدعم APIM أدوات MCP فقط دون موارد أو أوامر نصية، وميزات MCP غير متاحة في مساحات العمل.
بمعزل عن APIM، يمثل مستودع microsoft/mcp-gateway على GitHub وكيلًا عكسيًا وطبقة إدارة لخوادم MCP على Kubernetes. تستخدم طبقة البيانات توجيهًا واعيًا بالجلسة وقائمًا على الحالة، فتصل الطلبات التي تشترك في معرّف جلسة إلى نسخة الخادم نفسها، وتنشر طبقة التحكم محولات الخوادم وتحدّثها وتحذفها. يعتمد التفويض على أدوار Entra ID، ويتضمن المستودع مسارات نشر باستخدام PowerShell وBicep إلى AKS مع Azure Container Registry وCosmos DB.
💡 تغيير في المواصفة: أزالت مراجعة مواصفة MCP بتاريخ 2026-07-28 الجلسات البروتوكولية، فأسقطت مصافحة initialize ورأس
Mcp-Session-Id. لا يزال ربط الجلسات (session affinity) مهمًا للخوادم على مراجعات أقدم أو للخوادم التي تحتفظ بالحالة في الذاكرة، لكن الخوادم الجديدة لم تعد تحتاج إليها.
الأمثلة التي تقدمها Microsoft للخوادم الموجودة خلف APIM هي LangChain وLangServe وLogic Apps وFunctions. وأي خادم متوافق مع MCP يستطيع APIM الوصول إليه عبر HTTP مرشح للاستخدام، مما يجعل البوابة غلافًا مفيدًا لمجموعة مختلطة من الخوادم القديمة والحديثة.
| الميزة | AgentCore Gateway | API Management | Microsoft MCP Gateway |
|---|---|---|---|
| نمط النشر | خدمة AWS مُدارة | خدمة Azure مُدارة، أو بوابة مستضافة ذاتيًا | مفتوحة المصدر، تشغّلها على Kubernetes |
| مصادر الأدوات | Lambda، وAPI Gateway REST، وOpenAPI، وSmithy، وخوادم MCP | واجهات REST APIs في APIM، وخوادم MCP موجودة | خوادم MCP تنشرها على المجموعة |
| ميزات MCP | الأدوات، والأوامر النصية، والموارد | الأدوات فقط | يعتمد على خوادمك |
| المصادقة الواردة | OAuth (JWT)، وIAM SigV4، والمصادقة فقط | JWT من Entra ID أو مزودين آخرين، إضافةً إلى طرق أخرى | تفويض الأدوار عبر Entra ID |
| الفوترة | لكل عملية MCP، ولكل استعلام بحث، ولكل أداة مفهرسة | حسب الفئة ووحدات التوسع | موارد AKS والسجل وCosmos DB التي تشغّلها |
| عبء التشغيل | منخفض | منخفض إلى متوسط | مرتفع |
| الأنسب في حالة | فرق تعتمد على AWS أولًا، ومصادر أدوات مختلطة كثيرة | فرق تستخدم APIM بالفعل لواجهات REST | فرق المنصات على Kubernetes |
الهوية. كلا الخيارين المُدارين يتحققان من JWT، ويقبل APIM صراحةً الرموز من Entra ID أو مزودي هوية آخرين. يضيف AgentCore خيار SigV4 للمستدعين الذين يملكون بيانات اعتماد AWS بالفعل، وهو مفيد للحركة بين الخدمات. أيًّا كان اختيارك، اختبر كيف ترد البوابة على استدعاء غير مصادق. يقوم نموذج تفويض MCP على OAuth، والرد الواضح 401 الذي يوجّه العملاء إلى خادم التفويض الصحيح هو ما يسمح لهم بتسجيل الدخول دون إعداد يدوي.
الفوترة. تفرض AgentCore Gateway رسومًا على الاستدعاءات التي تقوم بها وكلاؤك عبرها، وتُحسب كعمليات MCP مثل ListTools وCallTool وPing، إضافة إلى استعلامات البحث والأدوات المفهرسة للبحث الدلالي. يُسعَّر APIM حسب الفئة ووحدات التوسع، لذا تتبع فاتورتك السعة لا عدد الاستدعاءات. بوابة Microsoft مفتوحة المصدر، لكنك تدفع ثمن العنقود والسجل وقاعدة البيانات والأشخاص الذين يحدّثونها. تميل حركة المرور المتقطعة ذات الحجم المنخفض إلى تفضيل التسعير لكل عملية، وتميل الحركة الكثيفة والمستقرة إلى تفضيل السعة الثابتة. راجع صفحة تسعير كل مورّد للأرقام الحالية.
💡 نصيحة: لأن ListTools وPing تُحتسبان عمليات قابلة للفوترة على AgentCore، فإن العملاء الثرثارين الذين يحدّثون قائمة الأدوات في كل دورة يرفعون الفاتورة. خزّن القائمة مؤقتًا لدى العميل لبضع دقائق.
كلا المسارين سريع لأداة أولى إذا كانت خلفيتك موجودة بالفعل. تبقى الخطوات أدناه عند المستوى الذي تضمنه الوثائق، لذا تحقق من تسميات الواجهة وخيارات CLI مقابل الوثائق الحالية.
tools/list وتأكد من ظهور كل أداة تتوقعها، ومن عدم ظهور أي شيء آخر.تبدو سياسة بداية كالتالي:
<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401"
failed-validation-error-message="Unauthorized">
<openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
<audiences>
<audience>api://mcp-gateway</audience>
</audiences>
</validate-jwt>
<rate-limit calls="60" renewal-period="60" />
</inbound>
يعمل الطلب نفسه مع أي من البوابتين، ما يجعله طريقة عادلة للمقارنة:
curl -X POST "$GATEWAY_URL" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
قد تتوقع الخوادم على مراجعات المواصفة الأقدم استدعاء initialize أولًا ثم رأس Mcp-Session-Id لاحقًا، بينما لا يحتاج خادم على مراجعة 2026-07-28 ذلك. لأي شيء يتجاوز اختبار الدخان، وجّه MCP Inspector إلى البوابة ونفّذ استدعاء أداة حقيقيًا، لأن طلبًا لمرة واحدة لن يُظهر كيف تتصرف الاستجابات المتدفقة.
أيًّا كان اختيارك، وجّه القياسات عن بُعد للبوابة إلى لوحات المراقبة التي يتابعها فريقك بالفعل قبل أن يبدأ أول وكيل العمل. تخبرك أحجام استدعاء الأدوات ومعدلات الأخطاء والزمن لكل أداة بما يستخدمه الوكلاء فعلًا، وأيٌّ من العمليات البالغ عددها 200 لا يستدعيه أحد أبدًا.
اختره حين تكون أدواتك دوال Lambda أو واجهات REST APIs في API Gateway أو مواصفات OpenAPI، وحين تريد نقطة نهاية مُدارة واحدة تجمعها، وحين يتولى IAM أو OAuth بالفعل حوكمة المستدعين لديك. ويناسب أيضًا الفرق التي تريد البحث الدلالي عن الأدوات دون بنائه بنفسها، والخوادم التي تعتمد على الأوامر النصية والموارد.
اختره حين تكون واجهات REST APIs لديك موجودة بالفعل في APIM، وتكون هويتك Entra ID، ويكون فريق المنصة لديك على دراية بمحرك السياسات. ستحصل على تحديد المعدل والحصص والتخزين المؤقت والمراقبة التي تثق بها بالفعل. اختر البوابة مفتوحة المصدر من Microsoft فقط حين تريد تحكمًا على مستوى Kubernetes وتستطيع تحمّل عبء تشغيلها.
هل تعمل على السحابتين؟ يستطيع AgentCore تجميع خوادم MCP بعيدة، ويستطيع APIM أن يعرض خوادم يصل إليها عبر HTTP، لذا يمكن لبوابة في سحابة أن تقع أمام أدوات في السحابة الأخرى. هذا ممكن، لكنه يضيف زمن استجابة وتكاليف خروج بيانات ونظام هوية ثانيًا يجب التوفيق بينه. عمليًا، بوابة واحدة لكل سحابة مع مزود هوية مشترك أبسط عادةً من بوابة واحدة ممتدة على السحابتين.
💡 فحص سريع: عدّ مصادر أدواتك، ثم مزود هويتك، ثم شكل حركة المرور. إذا كانت الغالبية لدوال Lambda وOpenAPI فالاتجاه نحو AgentCore. وإذا كانت الغالبية واجهات REST موجودة في APIM فالاتجاه نحو API Management. وإذا كان فريق منصة Kubernetes يحتاج إلى تحكم صارم، فالاتجاه نحو الخيار ذاتي التشغيل.
بوابة MCP أشبه بالسباكة، وأفضل السباكة هي الجزء الذي لا يراه أحد. ينطبق الأمر نفسه على الخدمات التي تستدعيها وكلاؤك. فمثلًا، تعرض PicassoIA واجهة API للمطورين على api.picassoia.com/v1 مع مصادقة Bearer، ومهامَّ غير متزامنة تنشئها ثم تستعلم عن حالتها، وحدًّا أقصى قدره 5 تنبؤات متزامنة لكل حساب، تتشاركه اتصالات API واتصالات MCP. هذا النوع من السقف هو بالضبط ما ينبغي للبوابة أن تفرضه نيابةً عنك: ضع الطلبات في طابور أو قيّد معدلها من جهتك، بدلًا من أن تترك الوكلاء يتلقون الرفض تلو الآخر.
تساعد النماذج اللغوية في أعمال الإعداد أيضًا. يمكنك كتابة مسودة Bicep أو Terraform أو مواصفة OpenAPI لبوابتك مع Claude Sonnet 5، ومراجعة سياسة مع GPT 5.6 Sol، أو تلخيص سجل تغييرات مورّد طويل بسرعة مع Gemini 3.5 Flash. اعتبر مخرجاتها مسودة أولى، ومرّرها عبر المراجعة نفسها التي تقدمها لطلب دمج يكتبه زميل.
ثم هناك الجانب البصري. تبدو مقالات الهندسة والويكي الداخلي ومنشورات الإطلاق أفضل مع صورة رئيسية قوية. افتح Picasso IA، واختر نموذج تحويل النص إلى صورة مثل Seedream 4.5، وصف المشهد الذي تريده في بضع جمل، وولّد عدة اختلافات. غيّر العدسة أو الإضاءة أو الخلفية، وقارن. لن تكون صورتك الأولى أفضلها، وغالبًا ستكون الخامسة هي الأفضل. تصفح كل النماذج على picassoia.com/en/all-models، وأنشئ صورك الخاصة اليوم.
اختر لغتك
