MCP مقابل API: لماذا تفشل واجهات برمجة التطبيقات التقليدية مع وكلاء الذكاء الاصطناعي
تفشل واجهات برمجة التطبيقات (APIs) التقليدية مع وكلاء الذكاء الاصطناعي.
لسنوات، قام المطورون ببناء تطبيقات الويب باستخدام REST و GraphQL. تعمل هذه الأدوات بشكل جيد مع البشر، وتعمل بشكل جيد مع الكود الحتمي (deterministic code). لكن وكلاء الذكاء الاصطناعي مختلفون؛ فهم يعملون بناءً على القصد والاستنتاج.
إذا عاملت النموذج اللغوي الكبير (LLM) كمطور بشري، فسترتكب خطأً. سينتهي بك الأمر بأنظمة بطيئة ومكلفة وهشة.
يغير بروتوكول سياق النموذج (Model Context Protocol - MCP) هذا الواقع. فهو معيار مفتوح للاتصال بالذكاء الاصطناعي.
مشكلة التكامل
عندما تقوم بربط ذكاء اصطناعي بخمس أدوات مختلفة باستخدام واجهات برمجة التطبيقات التقليدية، فإنك تضطر لكتابة خمسة وعشرين موصلاً مخصصاً. هذه هي مشكلة N x M، وهي تخلق ديوناً تقنية هائلة.
يحل MCP هذه المشكلة، حيث ينشئ بنية N + M. كل أداة تستخدم خادم MCP واحد، وكل وكيل يستخدم عميل MCP واحد. إنه يعمل كمحول عالمي (universal adapter) للنماذج اللغوية الكبيرة (LLMs).
ثلاثة أسباب تجعل MCP يتفوق على REST في مجال الذكاء الاصطناعي:
الاكتشاف الديناميكي (Dynamic Discovery) في REST، يجب عليك كتابة نقاط النهاية (endpoints) بشكل ثابت. إذا قمت بتغيير نقطة نهاية، يجب عليك تحديث الكود والمطالبات (prompts). أما MCP فيستخدم الاكتشاف الديناميكي؛ حيث يسأل الوكيل الخادم عما يمكنه فعله، فيرد الخادم بقائمة من الأدوات والقدرات، وبذلك يتعلم الوكيل أثناء التشغيل.
كفاءة الرموز (Token Efficiency) غالباً ما ترسل واجهات برمجة التطبيقات التقليدية حمولات JSON ضخمة. وفي عالم الذكاء الاصطناعي، تكلف الرموز (tokens) مالاً. البيانات المتضخمة تسبب التأخير (latency) وتآكل السياق (context rot). تفقد النماذج اللغوية الكبيرة تركيزها عندما ترى الكثير من البيانات الوصفية (metadata) غير ذات الصلة. تعيد خوادم MCP بيانات محسنة لنوافذ سياق النماذج اللغوية الكبيرة.
الجلسات ذات الحالة (Stateful Sessions) واجهة REST عديمة الحالة (stateless). بينما يحتاج وكلاء الذكاء الاصطناعي إلى حلقة مستمرة من التفكير والعمل. يستخدم MCP بروتوكول JSON-RPC 2.0، مما يسمح بمفاوضات ذات حالة (stateful negotiations). يظل السياق حياً عبر الإجراءات دون الحاجة لإعادة إرسال حمولات ضخمة.
يستخدم MCP ثلاثة أجزاء رئيسية:
- الأدوات (Tools): الإجراءات التي يتخذها النموذج، مثل تشغيل استعلام SQL.
- الموارد (Resources): بيانات للقراءة فقط مثل ملفات السجل (log files) أو المستندات.
- المطالبات (Prompts): قوالب لتوجيه استنتاج النموذج.
لا يحل MCP محل قاعدة بياناتك أو واجهات برمجة التطبيقات الحالية لديك. بل يحل محل "كود الربط" (glue code) الهش الذي تكتبه لربط تلك الخدمات بنموذج لغوي كبير.
توقف عن بناء وظائف مخصصة لتحويل JSON إلى نصوص (stringify) من أجل ذكائك الاصطناعي. ابدأ في بناء بنيات تحتية قابلة للتوسع.
المصدر: https://dev.to/chaudharidevam/mcp-vs-api-why-traditional-apis-are-failing-ai-agents-28m8