كيف أصبح MCP بمثابة USB-C لدمج AI — تحليل تقني معمق
Engineering Team
مشكلة الدمج N x M
قبل وجود Model Context Protocol، كان ربط نماذج AI بالأدوات الخارجية تمرينًا في الانفجار التوافقي. كل تطبيق AI (Claude، GPT، Gemini، Copilot) كان يحتاج إلى دمج مخصص لكل أداة (Slack، Jira، GitHub، قواعد البيانات، APIs). مع M تطبيق AI و N أداة، كانت الصناعة بحاجة إلى M x N محول مخصص — كل منها بتدفق مصادقة خاص وتنسيق بيانات ومعالجة أخطاء وعبء صيانة.
فكر في الحجم: بحلول عام 2025، كان هناك حوالي 20 منصة تطبيقات AI رئيسية ومئات من الأدوات المؤسسية. كانت الحسابات غير مستدامة. كل منصة AI جديدة كان عليها إعادة بناء عمليات الدمج من الصفر. كل أداة جديدة كان عليها كتابة محولات لكل منصة AI. كانت نفس المشكلة التي واجهتها صناعة الأجهزة قبل USB: كل جهاز له موصله الخاص، وكل حاسوب يحتاج منافذ مختلفة.
يحل MCP هذا بنفس الطريقة التي حل بها USB-C مشكلة الموصلات: توحيد الواجهة. مع MCP، كل تطبيق AI ينفذ MCP client واحد، وكل أداة تنفذ MCP server واحد. مشكلة M x N تصبح M + N. بروتوكول واحد، توافق عالمي.
بنية البروتوكول: JSON-RPC والقدرات والبدائيات الثلاث
MCP مبني على JSON-RPC 2.0، نفس بروتوكول RPC خفيف الوزن المستخدم بواسطة Language Server Protocol (LSP) الذي يدعم كل محرر كود حديث. كان هذا خيار تصميم متعمد: JSON-RPC بسيط ومفهوم جيدًا ولا يعتمد على لغة محددة ومُختبر في المعارك.
تفاوض القدرات
يبدأ اتصال MCP بمصافحة initialize حيث يعلن client و server قدراتهما لبعضهما البعض. هذا يسمح بتطور أنيق للبروتوكول. الميزات الجديدة تُضاف كأعلام capability جديدة، ويمكن للعملاء أو الخوادم القديمة تجاهل القدرات غير المعروفة.
البدائيات الثلاث
يحدد MCP ثلاث بدائيات أساسية:
-
Tools: دوال يستدعيها نموذج AI. يتم اكتشافها عبر tools/list وتنفيذها عبر tools/call. كل أداة لها اسم ووصف ومخطط إدخال محدد في JSON Schema.
-
Resources: بيانات يقرأها نموذج AI. محددة بواسطة URI ومسترجعة عبر resources/read. تشمل الملفات وسجلات قواعد البيانات واستجابات API وغيرها.
-
Prompts: قوالب prompts قابلة لإعادة الاستخدام يوفرها الخادم. يتم اكتشافها عبر prompts/list واسترجاعها عبر prompts/get. توحد طريقة تعامل AI مع المهام الخاصة بمجال الخادم.
المقارنة مع function calling و OpenAPI
لفهم موقع MCP، لنقارنه مع بديلين رئيسيين.
MCP مقابل Function Calling
يضمّن function calling (المستخدم من OpenAI و Anthropic وغيرهم) تعريفات الأدوات بشكل مضمن في كل طلب API. يصف المطورون الأدوات كـ JSON Schemas، ويختار LLM أي أداة يستدعيها وبأي معلمات.
| الجانب | Function Calling | MCP |
|---|---|---|
| تعريف الأدوات | مضمن في طلب API | محدد على خادم خارجي |
| الاكتشاف | لا يوجد (يوفره المطور) | ديناميكي (اكتشاف عبر tools/list) |
| الحالة | عديم الحالة (لكل طلب) | ذو حالة (قائم على الجلسات) |
| النقل | استدعاءات HTTPS API | stdio، SSE، Streamable HTTP |
| التوحيد | خاص بالمزود | معيار مفتوح |
| أدوات متعددة | تنسيق يدوي | أصلي في البروتوكول |
MCP مقابل OpenAPI
OpenAPI (سابقًا Swagger) هي مواصفة لوصف REST APIs. يمكن لـ AI قراءة مواصفات OpenAPI مباشرة وإنشاء استدعاءات API، لكن هناك اختلافات مهمة.
| الجانب | OpenAPI | MCP |
|---|---|---|
| الغرض | توثيق REST API | التواصل بين AI والأدوات |
| محسّن لـ AI | لا (عام) | مصمم لتفاعل AI |
| إدارة الجلسات | لا يوجد | مدمج |
| أمان الأنواع | JSON Schema | JSON Schema + تحقق وقت التشغيل |
| نموذج الموارد | URL + طريقة HTTP | URI + نوع المورد |
الجدول الزمني للتبني
لنتتبع تطور MCP:
- نوفمبر 2024: تطلق Anthropic بروتوكول MCP كمصدر مفتوح. الإصدار الأولي يدعم نقل stdio فقط.
- الربع الأول 2025: Claude Desktop و Cursor و Windsurf يدمجون دعم MCP. مجتمع المطورين يتوسع بسرعة.
- الربع الثاني 2025: إضافة نقل SSE. خوادم MCP البعيدة تصبح عملية.
- الربع الثالث 2025: OpenAI تعلن عن دعم MCP. Google DeepMind تدمج MCP client في Gemini.
- الربع الرابع 2025: إطلاق نقل Streamable HTTP. تسارع التبني المؤسسي.
- الربع الأول 2026: Microsoft تتبنى MCP في منصة Copilot. إطلاق MCP Registry (كتالوج الخوادم الرسمي).
- الربع الثاني 2026: MCP يصبح المعيار الفعلي لاتصالات AI-الأدوات. أكثر من 1,000 خادم رسمي مسجل في Registry.
مستقبل التواصل بين الوكلاء
التطور التالي لـ MCP هو التواصل بين الوكلاء (A2A). حاليًا، يحدد MCP التواصل بين تطبيقات AI (host) والأدوات الخارجية (server)، لكن قدرة وكلاء AI على التواصل مباشرة مع بعضهم البعض لا تزال في مراحلها المبكرة.
رؤية المستقبل:
- الوكلاء يكشفون خوادم MCP: كل وكيل AI لديه خادم MCP خاص به، قابل للاكتشاف والاستدعاء من وكلاء آخرين كأدوات متاحة
- تنسيق متعدد الوكلاء: بوابة MCP تدير تفويض المهام وتدفق البيانات بين عدة وكلاء
- بروتوكول تفويض موحد: طريقة قياسية للوكلاء لتفكيك المهام المعقدة إلى مهام فرعية وتفويضها إلى وكلاء متخصصين
الأسئلة الشائعة
س: هل MCP مرتبط بـ LSP (Language Server Protocol)؟ ج: نعم. MCP مستوحى من LSP. كلاهما يستخدم JSON-RPC 2.0، ويستخدم نمط تفاوض القدرات، ويتبع بنية client-server. كما فصل LSP محررات الكود عن دعم لغات البرمجة، يفصل MCP تطبيقات AI عن دمج الأدوات.
س: ما المخاطر الأمنية عند كشف خادم MCP؟ ج: المخاطر الرئيسية تشمل تجاوز المصادقة، إساءة استخدام الأدوات، تسرب البيانات، وحجب الخدمة. استخدام مصادقة OAuth 2.0، والتحقق من المدخلات، وتحديد المعدل، والتفويض على مستوى الأداة، وتسجيل تدقيق جميع استدعاءات الأدوات هي تدابير أساسية.
س: هل يمكن تحويل REST API موجودة إلى خادم MCP؟ ج: نعم. النمط الشائع هو تغليف كل نقطة نهاية API كأداة MCP. تتوفر أيضًا أدوات لإنشاء خوادم MCP تلقائيًا من مواصفات OpenAPI.
س: ما حجم الحمل الإضافي لأداء MCP؟ ج: الحمل الإضافي لبروتوكول JSON-RPC ضئيل. لنقل stdio في حدود الميكروثانية؛ لنقل HTTP يعادل طلب HTTP عادي. عنق الزجاجة عادة في تنفيذ الأداة نفسها (استعلام قاعدة بيانات، استدعاء API).
س: هل هناك حد لحجم رسائل MCP؟ ج: البروتوكول نفسه لا يحدد حدًا للحجم. الحدود العملية تعتمد على النقل والبنية التحتية. لعمليات النشر الإنتاجية، حافظ على استجابات الأدوات الفردية أقل من 10 ميجابايت واستخدم الترقيم أو التدفق لمجموعات البيانات الكبيرة.