أي وكيل ذكاء اصطناعي بلا اتصال بأنظمتك هو مجرد نموذج يتكلم. القيمة تبدأ حين يقرأ من أنظمتك ويكتب فيها. والسؤال الذي يواجه كل من يبني هذا: أربطه بتكامل API مخصص، أم عبر بروتوكول MCP؟

الجواب المختصر: MCP لا يحل محل الـ API. بل يغلّفه في طبقة موحّدة يستطيع النموذج التنقل فيها.

المشكلة الأصلية: N×M

قبل MCP، كل ربط بين وكيل وأداة كان تكاملًا ثنائيًا مستقلًا. وكيل يتصل بقاعدة بيانات يحتاج كودًا مخصصًا. ونفس الوكيل مع تقويم يحتاج كودًا مختلفًا. ومتصفحًا يحتاج ثالثًا.

النتيجة معادلة غير مستدامة: عدد الوكلاء (N) مضروبًا في عدد الأدوات (M). كل زوج بتكامل خاص. عشرة وكلاء وعشر أدوات تعني مئة تكامل.

MCP يحوّل المعادلة إلى N+M: كل وكيل يتكلم MCP، وكل أداة تعرض خادم MCP، وأي وكيل يستطيع استخدام أي أداة. عشرة وكلاء وعشر أدوات تصبح عشرين مكوّنًا بدل مئة.

ما هو MCP بدقة

بروتوكول مفتوح أطلقته Anthropic في نوفمبر 2024، ثم تبرّعت به لمؤسسة Agentic AI Foundation تحت مظلة Linux Foundation. فأصبح معيارًا محايدًا لا يملكه مزوّد واحد.

أطرافه الثلاثة:

  • المضيف (Host): التطبيق الذي يعمل فيه الوكيل. Claude Desktop، VS Code، أو تطبيقك.
  • العميل (Client): المكوّن داخل المضيف الذي يتصل بالخوادم ويستهلك قدراتها.
  • الخادم (Server): برنامج محلي أو بعيد يعرض القدرات بصيغة موحّدة.

والخادم يعرض ثلاثة أنواع من القدرات، والتمييز بينها مهم عمليًا:

  • الأدوات (Tools): أفعال ينفّذها الوكيل. إنشاء سجل، إرسال رسالة، تشغيل أمر.
  • الموارد (Resources): بيانات للقراءة. ملفات، سجلات قاعدة بيانات، مخططات.
  • القوالب (Prompts): سير عمل جاهز يوجّه سلوك الوكيل في مهمة متكررة.

الفكرة الأساسية أن MCP يعامل التكاملات كمزوّدات سياق لا كنقاط بيانات خام. أي أنه لا يعرض عمليات CRUD مجردة، بل قدرات موصوفة يفهم النموذج متى يستخدمها.

الفرق المعماري

المحورAPI تقليديMCP
اكتشاف القدراتنقاط نهاية مكتوبة يدويًا في الكودالوكيل يكتشف الأدوات وقت التشغيل عبر طلب tools/list
إدارة الحالةREST بلا حالة. كل طلب مستقل وينسى المرسلجلسة JSON-RPC 2.0 لها حالة مستمرة
المستهلك المستهدفمطوّر يكتب الاستدعاء بنفسهنموذج يقرر الاستدعاء بنفسه
إعادة الاستخدامتكامل لكل نظام ولكل نموذجخادم واحد يخدم أي عميل متوافق
عند تغيير النموذجغالبًا إعادة كتابة التكاملاتلا تغيير. البروتوكول واحد

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

متى تستخدم كل واحد

الخلط بينهما مكلف في الاتجاهين. القاعدة العملية:

  • استخدم MCP حين يحتاج الوكيل اكتشاف أدوات واستدعاءها ديناميكيًا عبر عدة أنظمة.
  • استخدم API مباشرًا حين تريد تحكمًا حتميًا مباشرًا في تكامل واحد داخل كود التطبيق.
  • نقطة التحول العملية: من يشغّل ثلاثة تكاملات أو أكثر مرتبطة بالذكاء الاصطناعي يبدأ يرى MCP يقلّل التعقيد فعليًا.

وأغلب خوادم MCP في الواقع أغلفة رقيقة فوق واجهات REST موجودة أصلًا. القيمة ليست في استبدال الـ API بل في طبقة التوحيد فوقه.

التطبيق الفني: الطريقة التقليدية

في نمط استدعاء الدوال التقليدي، تعرّف كل أداة يدويًا للنموذج بمخطط JSON، ثم تكتب منطق التنفيذ وتربطه باسم الأداة:

typescript
// تعريف الأداة للنموذج. يدويًا لكل نظام
const tools = [{
 name: "get_ticket_status",
 description: "يرجّع حالة تذكرة دعم برقمها",
 parameters: {
  type: "object",
  properties: { ticketId: { type: "string" } },
  required: ["ticketId"],
 },
}];

// منطق التنفيذ. تكتبه وتصونه بنفسك
async function runTool(name, args) {
 if (name === "get_ticket_status") {
  const res = await fetch(
   `https://itsm.internal/api/tickets/${args.ticketId}`,
   { headers: { Authorization: `Bearer ${process.env.ITSM_TOKEN}` } }
  );
  return res.json();
 }
 throw new Error("أداة غير معروفة");
}

هذا يعمل جيدًا لنظام واحد. لكن مع إضافة Oracle وActive Directory وCisco، ثم تبديل النموذج، يظهر حجم التكرار.

التطبيق الفني: خادم MCP

نفس الوظيفة كخادم MCP. تبنيه مرة واحدة، ويعمل مع أي عميل متوافق:

typescript
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
 name: "itsm-gateway",
 version: "1.0.0",
});

server.tool(
 "get_ticket_status",
 "يرجّع حالة تذكرة دعم برقمها",
 { ticketId: z.string().describe("رقم التذكرة") },
 async ({ ticketId }) => {
  const res = await fetch(
   `https://itsm.internal/api/tickets/${ticketId}`,
   { headers: { Authorization: `Bearer ${process.env.ITSM_TOKEN}` } }
  );
  const data = await res.json();
  return {
   content: [{ type: "text", text: JSON.stringify(data) }],
  };
 }
);

await server.connect(new StdioServerTransport());

لاحظ ثلاثة فروق جوهرية في هذا المثال:

  • المخطط معرَّف بـ Zod، فيُتحقق من المدخلات على الخادم لا في ثقة عمياء بمخرجات النموذج.
  • الوصف جزء من تعريف الأداة نفسها، فالوكيل يكتشفها ويفهم متى يستخدمها تلقائيًا.
  • المفتاح يعيش في متغير بيئة على الخادم، ولا يمر عبر النموذج إطلاقًا.

ربط الخادم بالعميل

بعد بناء الخادم، تعريفه في أي عميل متوافق سطور قليلة:

json
{
 "mcpServers": {
  "itsm-gateway": {
   "command": "node",
   "args": ["/opt/mcp/itsm-gateway/index.js"],
   "env": { "ITSM_TOKEN": "${ITSM_TOKEN}" }
  }
 }
}

نفس هذا الملف تقريبًا يعمل في Claude Desktop وCursor وVS Code وغيرها. هذه هي القيمة العملية للمعيارية.

الفوائد الملموسة

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

المخاطر الأمنية

MCP يمركز الاعتمادات (credentials) لعدة أنظمة في مكان واحد، وهذا يخلق نقطة فشل واحدة: خادم واحد مخترق قد يعطي المهاجم وصولًا لكل قاعدة بيانات ونظام ملفات وخدمة سحابية مرتبطة بمساعدك.

المخاطر الموثّقة في المجتمع والأبحاث:

  • تسميم الأدوات (Tool poisoning): وصف أداة مُعدّل خبيثًا يوجّه الوكيل لتنفيذ ما لم يطلبه المستخدم. وهناك مستودعات إثبات مفهوم توضّح تسريب مفاتيح SSH بهذه الطريقة.
  • حقن الأوامر: بحث من Equixly في مارس 2025 وجد 43% من تطبيقات MCP المفحوصة عرضة لحقن الأوامر.
  • خوادم بلا مصادقة: نشر خادم دون ضوابط مصادقة يفتح كل ما خلفه.
  • صلاحيات مفرطة: خادم بصلاحيات أوسع من اللازم يمنح وكيلًا مخترقًا وصولًا أكبر من المقصود.
  • سجل غير موثّق: السجل الرسمي للخوادم مفتوح للنشر بلا تحقق أمني، ونسبة معتبرة من الإدخالات بلا مستودع مصدري يمكن فحصه.

وحتى الخوادم المرجعية الرسمية صدرت لها تنبيهات أمنية. مثل ثغرات اجتياز مسارات وحقن معاملات في خادم Git. والتوثيق الرسمي نفسه يوضح أن هذه الخوادم أمثلة تعليمية لا حلول جاهزة للإنتاج.

ضوابط عملية قبل الإنتاج

  • شغّل الخوادم غير الموثوقة داخل حاويات معزولة، وافترض انعدام الثقة حتى التحقق.
  • خزّن الاعتمادات في متغيرات بيئة فقط. لا في مخططات الأدوات ولا في محتوى الموارد.
  • تحقق من كل مدخلات الأدوات على الخادم بمخططات صارمة (Zod أو Pydantic). لا تثق أبدًا أن النموذج سيرسل معاملات سليمة.
  • سجّل كل استدعاء أداة بالوقت والمعاملات (منقّاة من البيانات الحساسة) والنتيجة.
  • افرض TLS ومصادقة متبادلة (mTLS) للاتصالات بين الخوادم.
  • ابدأ بوضع قراءة فقط، ووسّع الصلاحيات بعد مراجعة السجل فعليًا.

الخلاصة العملية

لو كان لديك نظام واحد وتكامل بسيط لا تخطط لتوسعته، فالـ API المباشر أسرع وأبسط. أما إن كانت لديك عدة أنظمة وتتوقع مشاريع وكلاء متعددة أو تغيير النماذج مستقبلًا، فبناء خادم MCP لكل نظام رئيسي يوفّر عليك تكرارًا كبيرًا.

والقاعدة العملية لا تتغير بأي من الطريقتين: أقل صلاحية ممكنة، قراءة فقط أولًا، وسجل تدقيق قابل للمراجعة لكل استدعاء.