يقع خادم MCP بين تطبيق الذكاء الاصطناعي والأنظمة التي يحتاج إلى الوصول إليها. يرسم هذا المقال المسار كاملًا بالمخططات: المضيف والعميل والخادم وطبقة النقل ومصافحة JSON-RPC واستدعاء الأداة ومعالجة الأخطاء والأمان، مع مثال عملي لموصل صور وفيديو حقيقي.
يمكن لمساعد الذكاء الاصطناعي لديك أن يصيغ عقدًا في ثوانٍ، لكنه لا يستطيع وحده قراءة تقويمك أو الاستعلام عن قاعدة بياناتك أو تغيير حجم صورة. يسد بروتوكول سياق النموذج (Model Context Protocol)، واختصاره MCP، هذه الفجوة بعقد مشترك واحد بين تطبيقات الذكاء الاصطناعي والأنظمة المحيطة بها. خادم MCP هو البرنامج الصغير على الطرف الآخر من هذا العقد: يعلن ما يستطيع فعله، وينتظر الطلبات، ويعيد النتائج بشكل متوقع. يرسم هذا المقال هذه البنية قطعة قطعة. كل مخطط نص عادي، لذا يمكن نسخه ولصقه في ملف README أو وثيقة تصميم أو طلب سحب دون مشكلة.
قبل MCP، كان كل تطبيق ذكاء اصطناعي يريد الوصول إلى قاعدة بيانات أو تقويم أو نظام ملفات يحتاج إلى موصل مخصص خاص به. وكان لكل موصل نظام مصادقة وصيغة أخطاء وعيوب خاصة به. ثلاثة تطبيقات وثلاث أدوات تعني تسع تكاملات، والشبكة تكبر مع كل منتج جديد على أي من الجانبين. يستبدل MCP هذه الشبكة ببروتوكول مشترك، فيتغير الحساب من التطبيقات مضروبة في الأدوات إلى التطبيقات مضافة إلى الأدوات.
Before MCP: one custom connector for every pair
App A ──► Database App B ──► Database App C ──► Database
App A ──► Calendar App B ──► Calendar App C ──► Calendar
App A ──► Files App B ──► Files App C ──► Files
3 apps x 3 tools = 9 connectors to build and maintain
With MCP: one shared protocol in the middle
App A ──┐ ┌── Database server
App B ──┼──── MCP (JSON-RPC) ─────┼── Calendar server
App C ──┘ └── Files server
3 clients + 3 servers = 6 pieces
كلمة خادم تُضلل الناس. خادم MCP ليس نموذجًا لغويًا ولا يفكر. إنه برنامج عادي، مكتوب بلغة TypeScript أو Python أو أي لغة تدعم مكتبة JSON، يغلف قدرة حقيقية ويصفها بصيغة يمكن لكل عميل متوافق قراءتها. لا يحتاج النموذج أبدًا إلى معرفة كيفية عمل مشغّل قاعدة البيانات لديك. يحتاج فقط إلى معرفة أن أداة اسمها run_query موجودة، وما الوسائط التي تقبلها.
يُحدد MCP ثلاثة أدوار، وأغلب الالتباس يأتي من الخلط بينها. إليك الصورة الكاملة قبل التفاصيل.
┌──────────── HOST (the AI application) ────────────┐
│ The LLM picks a tool, the host routes the call │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ client 1 │ │ client 2 │ │ client 3 │ │
│ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │
└────────┬───────────────┬───────────────┬──────────┘
│ session │ session │ session
┌─────┴──────┐ ┌─────┴──────┐ ┌─────┴──────┐
│ Server A │ │ Server B │ │ Server C │
│ files │ │ GitHub │ │ image tool │
└────────────┘ └────────────┘ └────────────┘
المضيف هو التطبيق الذي يستخدمه الشخص فعلًا: تطبيق دردشة على سطح المكتب، أو مساعد داخل بيئة التطوير، أو وكيل مخصص. يشغّل المضيف نموذج اللغة، ويقرر أي الخوادم يتصل بها، ويعرض للمستخدم ما على وشك الحدوث. تعمل نماذج الاستدلال مثل Claude Sonnet 5 وGPT 5.6 Sol وGemini 3.1 Pro داخل المضيف، لكنها لا تتحدث بروتوكول MCP بنفسها. يترجم المضيف بين صيغة استدعاء الأدوات في النموذج والبروتوكول، ولهذا يعمل خادم واحد مع نماذج كثيرة مختلفة.
داخل المضيف، يُنشأ عميل MCP واحد لكل خادم. يحتفظ كل عميل بجلسة ذات حالة، وعلاقة واحد لواحد مع خادم واحد فقط، ويتذكر القدرات التي اتفق عليها الطرفان، ويوجّه كل رسالة. المضيف المتصل بثلاثة خوادم يشغّل ثلاثة عملاء، كما يوضح المخطط. إذا انقطعت جلسة واحدة، تستمر الجلستان الأخريان في العمل.
يغلّف خادم MCP نظامًا حقيقيًا: قاعدة بيانات Postgres، أو حساب GitHub، أو مجلدًا يضم مستندات، أو واجهة API للصور. وهو يبقى صغيرًا عمدًا. يعلن ما يقدمه، ويتحقق من المدخلات، وينفذ الإجراء، ويعيد مخرجات منظمة. ولا يرى المحادثة كاملة أبدًا، بل الطلبات المرسلة إليه فقط، وهو قرار تصميمي يحمي الخصوصية ويُبقي الخوادم قابلة لإعادة الاستخدام.
ملخص سريع يمكنك تعليقه فوق مكتبك:
يقدم الخادم ثلاث لبنات أساسية تُسمى البدائيات (primitives). تختلف في تفصيل واحد يحدد التصميم كله: من يقرر متى يُستخدم كل منها.
| البدائية | يتحكم بها | الاستخدام المعتاد | أمثلة على الأساليب |
|---|---|---|---|
| الأدوات | النموذج | تنفيذ إجراء أو حساب نتيجة | tools/list، tools/call |
| الموارد | التطبيق | توفير سياق للقراءة فقط مثل الملفات أو السجلات | resources/list، resources/read |
| الأوامر النصية | المستخدم | قوالب قابلة لإعادة الاستخدام، وغالبًا ما تظهر كأوامر شرطة مائلة | prompts/list، prompts/get |
للأداة اسم، ووصف بلغة بسيطة، وinputSchema مكتوب بصيغة JSON Schema. يقرأ النموذج الوصف ليقرر إن كانت الأداة مناسبة للطلب، ويحافظ المخطط على صلاحية الوسائط. يستحق الوصف جهدًا حقيقيًا، لأن الوصف الغامض يجعل النموذج يخمّن. سمِّ الأدوات كالأفعال، وأبقِ كل أداة ضيقة النطاق، وأعد الحقول التي يحتاجها النموذج فقط. أداة اسمها search_orders بثلاث وسائط محددة النوع أفضل من أداة واحدة do_anything تحتوي على حقل نص حر واحد. ولا تقتصر نتائج الأدوات على النص، فيمكنها أن تحمل صورًا أو صوتًا أو روابط، ولهذا تتلاءم مولدات الوسائط مع البروتوكول بشكل طبيعي. قد تغلف أداة الصور Flux 2 Pro أو Seedream 4.5، وقد تغلف أداة الفيديو Veo 3.1 أو Kling v3 Video.
الموارد بيانات للقراءة فقط يُشار إليها بعنوان URI، مثل file:///reports/q3.md أو postgres://db/customers/schema. يختار المضيف أيها يرفقه بسياق النموذج، لذلك تناسب الموارد المستندات والمخططات والسجلات. وبعد أن يشترك العميل، يستطيع الخادم أن يعلن التغييرات عبر notifications/resources/updated.
الأوامر النصية قوالب رسائل تقبل معاملات يختارها المستخدم عن قصد، وغالبًا من قائمة أوامر الشرطة المائلة. فالأمر النصي مثل راجع طلب الدمج هذا يعيد قائمة جاهزة من الرسائل، فيبدأ كل زميل من الصياغة نفسها ومن قائمة التحقق نفسها.
تسير الرسائل أيضًا في الاتجاه المعاكس. يمكن للخوادم أن تطلب المساعدة من العميل عبر أخذ العينات (طلب إكمال من نموذج المضيف)، والجذور (السؤال عن المجلدات الواقعة ضمن النطاق)، والاستيضاح (طلب معلومات ناقصة من المستخدم). ويقرر المضيف السماح بكل واحدة منها.
💡 قاعدة عامة: إذا كان الإجراء يغيّر شيئًا في العالم، فابنِ أداة. وإذا كان يوفر معلومات فقط، فابدأ بمورد.
تحدد طبقة النقل كيفية انتقال البايتات بين العميل والخادم. تبقى الرسائل نفسها في الحالتين: طلبات JSON-RPC 2.0 وردودها وإشعاراتها. وهناك طبقتا نقل قياسيتان.
stdio: the host starts the server as a child process
┌────────┐ stdin: requests ┌───────────┐
│ Client │ ─────────────────────► │ Server │
│ │ ◄───────────────────── │ process │
└────────┘ stdout: responses └───────────┘
stderr: logs only
مع stdio، يشغّل المضيف الخادم كعملية فرعية، ويتبادل رسائل JSON-RPC مفصولة بأسطر جديدة عبر الإدخال والإخراج القياسيين. الإعداد سطر أوامر واحد، والتأخير ضئيل، وتصل بيانات الاعتماد عبر متغيرات البيئة. هناك قاعدة واحدة يتعثر فيها كثير من الكتّاب الجدد: يجب ألا يطبع الخادم أي شيء غير رسائل البروتوكول إلى stdout. توجَّه السجلات إلى stderr، وإلا فسيتلف التدفق وتنهار الجلسة.
Streamable HTTP: one URL, many clients
┌──────────┐ POST /mcp ┌────────────┐
│ Client A │ ───────────────────► │ │
└──────────┘ ◄─────────────────── │ Server │
┌──────────┐ JSON or SSE reply │ (web app) │
│ Client B │ ───────────────────► │ │
└──────────┘ ◄─────────────────── └────────────┘
يخدم Streamable HTTP عدة عملاء من نقطة نهاية واحدة. يرسل العميل كل رسالة كطلب HTTP من نوع POST، ويرد الخادم بـ JSON عادي، أو يفتح تدفق Server-Sent Events عندما يحتاج إلى إرسال عدة رسائل. يُنقل معرّف الجلسة في ترويسة Mcp-Session-Id. حلّت هذه الطبقة محل تصميم HTTP plus SSE الأقدم في مراجعة المواصفات بتاريخ 2025-03-26، وهي الخيار الصحيح للخوادم المستضافة والمنتجات متعددة المستخدمين وأي شيء يقع خلف موازن أحمال. تُبنى المصادقة على OAuth، لذا يستطيع الخادم أن يرد برمز 401 ويوجّه العميل نحو خادم التفويض الخاص به. أما الخوادم التي ما زالت تعمل بالتصميم السابق فيمكنها البقاء متوافقة بتشغيل نقطتي النهاية معًا أثناء الترحيل، لكن المشروع الجديد يجب أن يبدأ باستخدام Streamable HTTP.
| السؤال | stdio | Streamable HTTP |
|---|---|---|
| أين يعمل الخادم؟ | على الجهاز نفسه الذي يعمل عليه المضيف | في أي مكان يمكن الوصول إليه عبر عنوان URL |
| عدد المستخدمين لكل خادم | واحد | كثيرون |
| بيانات الاعتماد | متغيرات البيئة | OAuth أو ترويسات HTTP |
| الأفضل لـ | أدوات المطورين، الملفات المحلية | المنتجات المستضافة، الخدمات المشتركة |
| الفخ الرئيسي | مخرجات عشوائية على stdout | إدارة الجلسات خلف الوكلاء الوسيطة |
تقسيم عملي: قدّم نسخة stdio للمطورين الذين يريدون تجربة الخادم في دقيقة، ونسخة Streamable HTTP لبقية المستخدمين. يبقى كود الأداة نفسه، ولا يتغير سوى نقطة الدخول.
إليك طلبًا واحدًا من لحظة كتابة المستخدم إلى لحظة ظهور الإجابة.
User Host + LLM MCP client MCP server
│ │ │ │
├─ asks for image ───► │ │
│ │ picks a tool │ │
│ ├─ tool request ────► │
│ │ ├─ tools/call ──────►
│ │ │ │ does the work
│ │ ◄─ text, isError ───┤
│ ◄─ result ──────────┤ │
◄─ answer + URL ─────┤ │ │
│ │ │ │
تبدأ كل جلسة بـinitialize. يرسل العميل إصدار البروتوكول الذي يدعمه مع قدراته الخاصة. ويرد الخادم بالإصدار الذي اختاره والقدرات التي يقدمها. ثم يرسل العميل رسالة notifications/initialized ويبدأ التبادل العادي. وإذا تعذر التوفيق بين الإصدارات، ينفصل العميل بدلًا من التخمين.
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": { "sampling": {} },
"clientInfo": { "name": "example-host", "version": "1.0.0" }
}
}
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-06-18",
"capabilities": { "tools": { "listChanged": true } },
"serverInfo": { "name": "image-server", "version": "0.3.0" }
}
}
يرسل العميل tools/list، فيسلّم المضيف المخططات إلى النموذج، ويقرر النموذج إن كان سيستدعي إحدى الأدوات. وعندما تتغير قائمة أدوات الخادم أثناء التشغيل، يرسل notifications/tools/list_changed كي يحدّث العميل قائمته. يبدو الاستدعاء هكذا:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "generate_image",
"arguments": { "prompt": "A walnut desk with printed diagrams", "aspect_ratio": "16:9" }
}
}
يحمل الرد مصفوفة content وعلامة isError:
{
"jsonrpc": "2.0",
"id": 7,
"result": {
"content": [{ "type": "text", "text": "Job accepted, check status in 5 seconds" }],
"isError": false
}
}
يفصل MCP بين نوعين من الفشل. خطأ البروتوكول كائن خطأ من JSON-RPC، مثل الرمز -32602 للمعاملات غير الصالحة أو اسم أداة غير معروف. أما خطأ تنفيذ الأداة فهو نتيجة عادية تحمل isError: true ورسالة يستطيع النموذج قراءتها. والنوع الثاني هو الأهم. عندما تجيب أداة برسالة الأمر النصي طويل جدًا، يستطيع النموذج أن يختصر الأمر ويعيد المحاولة، لكن ذلك لا يحدث إلا إذا وصل الخطأ إليه كنص، لا كجلسة منهارة. ويمكن لأي من الطرفين أيضًا أن يرسل notifications/cancelled لإلغاء طلب بطيء.
شغّل الخادم تحت MCP Inspector (npx @modelcontextprotocol/inspector) قبل أن يلمسه أي نموذج. يعرض Inspector الأدوات، ويتيح لك تنفيذ الاستدعاءات يدويًا، ويُظهر حركة JSON-RPC الخام، فتستطيع فصل أخطاء البروتوكول عن أخطاء الأوامر النصية.
معظم المشكلات في بيئات الإنتاج تعود إلى الخيارات الثلاثة نفسها:
do_anything مع وسيط نص حر تجبر النموذج على التخمين. قسّمها إلى أفعال ضيقة مثل search_orders وrefund_order، ولكل منها وسائط محددة النوع.توضح حالة ملموسة لماذا تهم خيارات البنية. تقدم PicassoIA موصل MCP يولّد أدواته الصور والفيديو ويعدّلها على وحدات GPU الخاصة بها. تستغرق مهام الصور والفيديو من ثوانٍ إلى دقائق، وهذا يكسر التصور البسيط القائل: استدعِ أداة وانتظر الإجابة. وعادة ما تفرض المضيفات وأدوات تطوير البرمجيات مهلة زمنية للطلب، لذلك سيفشل خادم يتوقف حتى ينتهي التصيير في اللحظة التي يكون فيها العمل قد اقترب من الانتهاء.
يعرض الموصل أدوات اسمها generate_image، وedit_image، وgenerate_video_picassoia، وgenerate_video_seedance، وget_generation، وcancel_generation، وlist_models، وlist_generations، وget_account. يعيد استدعاء التوليد معرّف تنبؤ ووقتًا تقديريًا في اللحظة نفسها. ثم يستدعي النموذج get_generation بعد فترة الانتظار المقترحة، ويكرر ذلك بعد كل تلميح جديد، إلى أن تظهر الحالة succeeded أو failed. تبقى مدة استدعاء الأداة قصيرة، بينما يعمل العمل الثقيل كمهمة في الخلفية على وحدة GPU عاملة.
Model MCP server GPU worker
│ │ │
├─ generate_image ─────► │
│ ├─ submit job ──────────►
◄─ id + wait hint ─────┤ │
│ │ │ rendering
├─ get_generation ─────► │
◄─ status: processing ─┤ │
├─ get_generation ─────► │
◄─ succeeded + URL ────┤ │
│ │ │
النماذج التي يعتمد عليها الموصل هي PicassoIA Image وPicassoIA Image Editor Pro للصور الثابتة، إضافة إلى PicassoIA Video وSeedance 2.5 Lite للمقاطع التي تتضمن صوتًا. تعود النتائج كروابط URL عادية، لذا يستطيع أي مضيف عرضها.
يجب أن يحمي الخادم الذي يقف أمام طابور GPU هذا الطابور. تعلن PicassoIA عن سقف قدره خمسة تنبؤات متزامنة لكل حساب، مشتركة بين بيانات اعتماد API واتصالات MCP. ويحوّل الخادم الجيد هذا السقف إلى نتيجة أداة واضحة، مثل خمس مهام قيد التشغيل، أعد المحاولة بعد 30 ثانية، بدلًا من ترك الطلبات تتكدس خلفه. يستطيع النموذج قراءة هذه الرسالة والانتظار، وهذا أفضل بكثير من انتهاء المهلة.
أربع عادات تجعل الخادم غير المتزامن أسهل في الاستخدام من قِبل الوكيل:
يحمل MCP القدرة، ولذلك ينقل المخاطر أيضًا. يحدد البروتوكول شكل المحادثة، لكن المضيف والخادم يتحملان المسؤولية. تغطي ستة فحوصات معظم المشكلات قبل الإطلاق:
ينطبق المنطق نفسه على النشر. ثبّت إصدار البروتوكول في اختباراتك، وشغّل الخادم تحت Inspector في CI، وضع الخوادم البعيدة خلف بوابة تتولى TLS وحدود المعدل وOAuth، كي يبقى كود الأدوات مركزًا على الأدوات.
تثبت المخططات في الذهن أكثر عندما ترى استدعاء أداة ينتج شيئًا حقيقيًا. افتح PicassoIA، واكتب أمرًا نصيًا لصورة لمكتبك أو غرفة الخوادم أو رسمة على لوح أبيض، ثم ولّدها باستخدام Seedream 4.5 أو GPT Image 2. بعد ذلك، حرّك إطارك المفضل باستخدام Veo 3.1 أو Kling v3 Video. وإذا كان المضيف لديك يدعم اتصالات MCP، فأضف موصل PicassoIA، ودع مساعدك يشغّل المهمة بينما تتبع خطوات الاستعلام الواردة في المخطط أعلاه.
جرّب ثلاثة أوامر نصية وغيّر شيئًا واحدًا في كل مرة: زاوية الكاميرا، أو اتجاه الإضاءة، أو العدسة. ستظهر الفروق مدى أهمية الأمر النصي الدقيق، تمامًا كما يهم وصف الأداة الدقيق بالنسبة إلى النموذج. تصفح كل النماذج المتاحة على picassoia.com/en/all-models وابدأ أول توليد لك اليوم.
اختر لغتك
