استضافة خادم MCP: أين تشغل خوادم MCP الخاصة بك فعلياً

ما المقصود فعلياً بـ "استضافة خادم MCP"؟

خادم MCP هو مجرد عملية (process). هذا كل ما في الأمر. بروتوكول سياق النموذج (Model Context Protocol) يحدد كيفية اكتشاف العميل للأدوات واستدعائها ضمن تلك العملية، لكنه لا يحدد مكان وجودها أو الجهة المسؤولة عن إبقائها قيد التشغيل. يترك هذا الأمر كمسألة بنية تحتية بحتة، وينقسم بناءً على وسيلة النقل.

خوادم Stdio تتواصل عبر بروتوكول MCP باستخدام المدخلات والمخرجات القياسية (standard input/output). وهي برامج تعمل بأسلوب سطر الأوامر (CLI)، وعادة ما يبدأها العميل نفسه باستخدام npx أو uvx. لا توجد منافذ، ولا روابط URL، ولا مستمع للشبكة؛ حيث يقوم العميل بإنشاء عملية فرعية على نفس الجهاز ويتواصل معها عبر الأنابيب (pipes).

خوادم HTTP/SSE تكشف عن نقاط نهاية HTTP مباشرة. فهي تستمع عبر منفذ وتعمل تماماً مثل أي خدمة ويب أخرى تعرف كيفية إدارتها.

تضع وثائق TrueFoundry حداً فاصلاً يترتب عليه نتيجة واضحة: خوادم HTTP تُنشر دون الحاجة إلى أغلفة إضافية، بينما يجب تغليف خوادم stdio باستخدام mcp-proxy لتحويل stdio إلى HTTP. كما توضح الوثائق بصراحة أي النوعين يجب اختياره عند البدء من الصفر؛ حيث يُنصح باستخدام الخوادم القائمة على HTTP لكونها أكثر أماناً وأسهل في النشر.

خيارات الاستضافة الثلاثة، بكل صراحة

الخيار الأول: استخدام stdio محلياً على جهازك المحمول

هذا هو المكان الذي يبدأ منه الجميع تقريباً، وهو الخيار الصحيح لشخص واحد. تقوم بنسخ كتلة برمجية ولصقها في إعدادات Cursor أو Claude، فيقوم العميل بتشغيل npx -y @some/mcp-server عند الطلب، ويتم وضع مفتاح واجهة برمجة التطبيقات (API key) في متغيرات البيئة أدناه.

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

الخيار الثاني: السحابة المدارة من قبل مورد

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

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

الخيار الثالث: الاستضافة الذاتية على بنيتك التحتية

أنت تقوم بتشغيل العملية على مجموعة Kubernetes الخاصة بك، داخل شبكتك الافتراضية الخاصة (VPC)، وخلف سياسة الشبكة الخاصة بك. هذا هو الخيار الذي تلجأ إليه الفرق بمجرد أن يبدأ الخادم في التعامل مع أي موارد داخلية.

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

ما الذي يتغير بمجرد توقفه عن كونه محلياً

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

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

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

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

حركة المرور الصادرة (Egress). يقوم الخادم الآن بإجراء مكالمات صادرة من داخل شبكتك بدلاً من جهاز محمول على شبكة واي فاي المكتب. عادةً ما يكون هذا هو الهدف، لكنه يجعل موقع الخادم في الشبكة قراراً أمنياً وليس مجرد صدفة.

أين تخطئ الفرق في استضافة خادم MCP

لا يزال كل مطور يشغل نسخته الخاصة. الفشل الأكثر شيوعاً ليس تقنياً. لا يتم إيقاف الإعدادات المحلية أبداً، لذا يعمل نصف الفريق على عنوان URL الخاص بالبوابة بينما لا يزال النصف الآخر يشغل npx محلياً باستخدام رمز شخصي. هذا ليس مركزية؛ بل هو مسار ثانٍ.

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

الحزم غير المثبتة بإصدارات محددة. يتم حل npx -y some-package إلى أحدث إصدار عند بدء الحاوية، لذا يمكن لنسختين متماثلتين بدأتا بفارق أسبوع تشغيل مجموعات أدوات مختلفة. قم بتثبيت إصدارات محددة في الوسائط.

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

Skip the plumbing.

Deploy an MCP server on your own cluster and put a governed URL in front of it in one sitting.

Get started free

كيف تعمل استضافة خادم MCP على TrueFoundry

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

المسار 1 — من الكود المصدري

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

إنه نشر خدمة قياسي: Deployments → New Deployment → Service، اختر مساحة العمل الخاصة بك، ثم اختر Git Repo أو Code From Laptop كمصدر. بالنسبة لخادم HTTP بلغة Python تم بناؤه باستخدام FastMCP ولا يحتوي على ملف Dockerfile، يتكون الإعداد من مسار سياق البناء، ومسار ملف requirements.txt، وإصدار Python، والأمر (python server.py)، والمنفذ 8000.

إذا كان مصدرك عبارة عن خادم stdio، فقم بتغليفه. المسار الموصى به هو استخدام ملف Dockerfile يقوم بتثبيت mcp-proxy وتعيين أمر تشغيل (CMD) مثل mcp-proxy --port 8000 --host 0.0.0.0 --server stream python server.py. لتجنب استخدام Dockerfile، استخدم خيار Python Build، وأضف mcp-proxy كاعتمادية، وقم بتعيين نفس الأمر مباشرة:

إعدادات المنفذ هي نفسها في كلتا الحالتين: المنفذ 8000، البروتوكول TCP، بروتوكول التطبيق http، مع ضبط خيار العرض (expose) على false إذا كان يجب أن تكون الخدمة قابلة للوصول داخل المجموعة فقط. يتم وضع القيم الحساسة في أسرار TrueFoundry، ويشار إليها بالصيغة tfy-secret://your-workspace:your-secret-group:API_KEY.

المسار 2 — من حزمة npx أو uvx

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

بالنسبة لـ حزم npm، تكون الصورة الأساسية هي node:24 والأمر هو:

npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y <package-name>

يقوم الأمر الأول npx -y mcp-proxy بتثبيت الوكيل وتشغيله، بينما يقوم الثاني بتشغيل حزمة الخادم الخاصة بك. لذا، يصبح خادم Notion كالتالي: npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server.

بالنسبة لـ حزم Python، تكون الصورة الأساسية هي public.ecr.aws/docker/library/python:3.11-slim ويقوم الأمر بتثبيت الأدوات أولاً:

sh -c "pip install uv mcp-proxy && mcp-proxy --host=0.0.0.0 --port=8000 uvx <package-name>"

النشر من نموذج صورة Docker مع صورة أساسية python:3.11-slim و mcp-proxy يغلف حزمة uvx MCP

تنتقل متغيرات البيئة كما هي من إعداداتك المحلية — مثل NOTION_API_KEY و GITHUB_TOKEN — مع نقل المتغيرات الحساسة إلى "الأسرار" (Secrets). ملاحظة هامة: عملية التشغيل الأولى تكون بطيئة بينما يقوم npx أو uvx بتنزيل الحزمة. إذا كانت سرعة التشغيل البارد (cold starts) مهمة، قم بتثبيتها مسبقاً في صورة مخصصة.

المسار 3 — استضافة stdio، يتم تشغيلها بواسطة البوابة (gateway)

يتجاوز المسار الثالث نشر الخدمة بالكامل: بدلاً من قيامك بتغليف خادم stdio ونشره، تقوم البوابة بتشغيل العملية وعرضها عبر نفس الرابط الذي تستخدمه للخوادم البعيدة. من خوادم MCP ← إضافة خادم، اختر خادم MCP مستضاف يعتمد على Stdio:

أنت تقدم أمراً، وسائط (arguments)، و متغيرات البيئة، أو الصق ملف JSON بنمط المحرر — وهو نفس شكل mcpServers ذو الإدخال الواحد المستخدم في Cursor أو VS Code — وستتم تعبئة النموذج تلقائيًا. خادم مرجع نظام الملفات هو الأمر: npx مع الوسائط -y, @modelcontextprotocol/server-filesystem, /tmp.

تقوم البوابة بتشغيله عبر مكتبة mcp-proxy في بيئة معزولة (sandboxed) في وضع عديم الحالة (stateless)، وتتصل العملاء عبر بروتوكول HTTP POST القابل للبث. يمكن أن تكون متغيرات البيئة عامة (يشارك الجميع بيانات اعتماد المصب) أو لكل مستخدم، حيث تحمل القيمة عنصرًا نائبًا واحدًا مصاغًا يتم حله من "تجاوزات المصادقة" (Auth Overrides) الخاصة بذلك المتصل. تنبيه واحد: توصي الوثائق بهذا المسار للتطوير المحلي في بيئات التطوير المتكاملة (IDEs) — فهي أسرع طريقة للحصول على عنوان URL مشترك ومُدار عبر خادم بنمط سطر الأوامر (CLI)، وليست النمط المتبع لأحمال العمل الإنتاجية ذات الحجم الكبير.

ثم قم بتسجيله خلف البوابة

بغض النظر عن كيفية نشر الخادم، تظل الخطوة الأخيرة كما هي. خذ عنوان URL لنقطة نهاية الخدمة، وانتقل إلى إضافة خادم ← توصيل أي خادم MCP عن بُعد، وقدم اسمًا ووصفًا وعنوان URL والمتعاونين وبيانات المصادقة.

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

المصادقة الصادرة — وهي الطريقة التي تثبت بها البوابة هويتها للخادم الذي قمت بنشره — تكون إما عبر مفتاح API، أو OAuth2، أو AWS SigV4، أو تمرير الرمز المميز (Token Passthrough). ينقسم مفتاح API إلى بيانات الاعتماد المشتركةحيث يخدم مفتاح واحد الجميع، و بيانات الاعتماد الفرديةحيث تحمل قيمة الترويسة (header) عنصرًا نائبًا مثل Bearer {{API_KEY}} ويقوم كل مستخدم بتوفير مفتاحه الخاص من خلال تجاوزات المصادقة (Auth Overrides):

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

إعداد OAuth2 لخادم MCP مع أنواع منح رمز التفويض (Authorization Code) وبيانات اعتماد العميل (Client Credentials)

بمجرد التسجيل، تظهر الأدوات ويمكن استدعاؤها من ساحة التجربة (Playground):

مثال عملي: الاستغناء عن النسخ الموجودة على أجهزة الكمبيوتر المحمولة

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

الخطوة 1 — النشر. نشر جديد (New Deployment) ← خدمة (Service) ← النشر من صورة Docker، الصورة الأساسية node:24، الأمر npx -y mcp-proxy --port 8000 --host 0.0.0.0 --server stream npx -y @notionhq/notion-mcp-server، المنفذ 8000، البروتوكول TCP، بروتوكول التطبيق http. قم بتثبيت إصدار الحزمة. ضع NOTION_API_KEY في الأسرار (Secrets)، وليس في حقل البيئة كنص عادي.

الخطوة 2 — التحقق. انتظر حتى ظهور DEPLOY_SUCCESS، ثم دوّن عنوان URL لنقطة نهاية الخدمة وقم بتنفيذ أمر curl عليه. يجب أن يستجيب برسائل بروتوكول MCP عبر HTTP. القيام بذلك قبل تسجيل أي شيء يفصل بين مشكلة "الحاوية لن تبدأ" ومشكلة "البوابة لا يمكنها الوصول إليها"، وهما مشكلتان مختلفتان تمامًا.

الخطوة 3 — التسجيل. إضافة خادم (Add Server) ← الاتصال بأي خادم MCP عن بُعد (Connect any Remote MCP Server)، الصق عنوان URL لنقطة النهاية، وقم بتسميته، وأضف فريق الهندسة بصفتهم مستخدم خادم MCP وأضف نفسك بصفتك مدير خادم MCP، ثم قم بتهيئة بيانات المصادقة.

الخطوة 4 — شارك رابط البوابة (Gateway URL). تحتوي علامة التبويب كيفية الاستخدام على مقتطفات اتصال خاصة بالمستأجر لكل من Cursor وVS Code وClaude Code وWindsurf وCodex، بالإضافة إلى حزم تطوير البرمجيات (SDKs) الخاصة بـ Python وTypeScript، إلى جانب زر إضافة MCP إلى Cursor يقوم بكتابة الإعدادات للمطور تلقائياً.

الخطوة 5 — احذف الكتل المحلية. هذه هي الخطوة التي تتجاهلها الفرق، وهي التي تجعل الخطوات الأربع الأخرى ذات قيمة. طالما أن إدخالات npx موجودة في إعدادات الجميع، فأنت تشغل تسع نسخ بدلاً من نسخة واحدة.

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

Ready to host your first one?

Deploy from a repo, an npx package, or a stdio command, and put it behind a governed URL.

Start free on TrueFoundry

مشكلات شائعة تجدر معرفتها

التثبيت المتعثر يبدو كأنه خادم متعثر. بالنسبة لخوادم stdio المستضافة، لا يظهر فشل تثبيت الحزمة كخطأ؛ بل يظل الخادم في حالة mcp_server_starting إلى أجل غير مسمى، لأن مدير الحزم لا يسلم العملية إلى معالج MCP. الأسباب المعتادة: رابط git بدون مرجع مثبت (pinned ref)، أو بيانات اعتماد مضمنة في رابط حزمة npm (حيث يقوم npm بإزالتها)، أو تنزيل جزئي يفسد ذاكرة التخزين المؤقت لـ npx بعد إنهاء التشغيل الأول. تغيير أي شيء في الوسائط (args) يؤدي إلى إعادة تهيئة بيئة الاختبار (sandbox) والبدء من جديد.

يتم إسقاط الإشعارات التي تقع خارج تدفق الاستجابة. تقوم البوابة بتشغيل خوادم stdio في وضع عديم الحالة (stateless)، لذا لا يتم تسليم الإشعارات المستقلة التي يبدأها الخادم خارج تدفق استجابة الطلب. تحقق من مصفوفة دعم البروتوكول قبل نقل خادم يرسل رسائل غير مطلوبة.

عنوان الربط (Bind address) سيوقعك في الفخ مرة واحدة. ربط localhost ينتج عنه حاوية تبدأ وتجتاز فحص السلامة الخاص بها، لكنها تظل غير مرئية للمجموعة (cluster). لهذا السبب تحديداً، يحمل كل أمر stdio wrap في الوثائق المعامل --host 0.0.0.0.

التشغيل البارد (Cold starts) حقيقي عند استخدام npx/uvx. يتم تنزيل الحزمة عند بدء تشغيل الحاوية — وهو أمر مقبول لخادم مخصص للتطوير، ولكنه مزعج لأي شيء حساس لزمن الاستجابة.

قراءات ذات صلة

• ما هي بوابة MCP — الطبقة التي تسبق أي خدمة تستضيفها
• خادم MCP الخاص بـ Slack — خادم تابع لجهة خارجية وكيفية إدارته
• خادم MCP الخاص بـ Datadog — النمط المطبق على أدوات المراقبة
• خادم MCP الخاص بـ Snowflake — حيث تجعل البيانات الخاصة الاستضافة الذاتية هي الخيار الافتراضي
• شرح خادم MCP الافتراضي — تجميع الأدوات من عدة خوادم مستضافة في نقطة نهاية واحدة

الخلاصة

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

ما يجعل الأمر يستحق التنفيذ بعناية هو أن خادم MCP يمثل نقطة نهاية للأدوات. الوصول دون تحكم ليس إنجازاً، بل هو ثغرة أمنية. إن النشر على نظام Kubernetes الخاص بك والتسجيل خلف بوابة في نفس المنصة يدمج المهمتين في وظيفة واحدة: تعمل العملية حيث تُطبق سياسة الشبكة الخاصة بك بالفعل، ويعرف عنوان URL الذي يواجهها مسبقاً من الذي يتصل.

Deploy and govern your first MCP server on TrueFoundry

Free to start