إذا كنت قد قضيت سنوات في صيانة منطق الأعمال داخل تطبيقات PHP، فإن مشاهدة دروس بروتوكول سياق النموذج (Model Context Protocol) قد

إذا كنت قد قضيت سنوات في صيانة منطق الأعمال (business logic) داخل تطبيقات PHP، فقد تشعر أن دروس Model Context Protocol تشبه الوقوف أمام باب مغلق. فكل دليل تقريبًا يفترض استخدام TypeScript أو Python. إنهم يشرحون كيفية استخدام SDKs الرسمية، وتثبيت حزم npm، وحزم pip. وهذا يترك كمية هائلة من بيانات الأعمال — سجلات العملاء، وتاريخ الطلبات، وأنظمة المخزون — حبيسة قواعد أكواد PHP التي تبدو غير مرئية للموجة الحالية من أدوات الذكاء الاصطناعي.

الخبر السار هو أن MCP لا يتطلب تلك الـ SDKs. فـ MCP ليس مكتبة، بل هو بروتوكول نقل (wire protocol). إذا كان وقت التشغيل (runtime) الخاص بك يمكنه قراءة سطر نصي من المدخلات القياسية (standard input)، وتحليل JSON، وكتابة JSON مرة أخرى، فيمكنه التحدث بهذا البروتوكول. ولقد كانت PHP تفعل ذلك بالضبط منذ وقت طويل قبل وجود النماذج اللغوية الكبيرة (LLMs).

ما هو MCP في الواقع

يرمز MCP إلى Model Context Protocol. في جوهره، هو معيار مفتوح لربط مساعدي الذكاء الاصطناعي بالبيانات والأدوات وواجهات برمجة التطبيقات (APIs) الخارجية. بدلاً من بناء تكامل مخصص لكل مساعد أو نموذج، تقوم ببناء واجهة واحدة متوافقة. وأي عميل (client) يفهم MCP يمكنه بعد ذلك التحدث مع خادمك دون معرفة أي شيء عن PHP أو Laravel أو مخطط قاعدة البيانات الخاص بك.

في الخلفية، يستخدم MCP بروتوكول JSON-RPC 2.0. وهذا يعني أن كل طلب هو كائن JSON بسيط يحتوي على اسم الطريقة (method name)، والمعلمات (parameters)، ومعرف (ID). يستجيب الخادم بكائن JSON آخر يحمل إما نتيجة أو خطأ.

يكشف الخادم عن ثلاثة عناصر أساسية:

• الأدوات (Tools): الإجراءات التي يمكن للنموذج استدعاؤها. قد تقوم الأداة بالاستعلام عن قاعدة بيانات، أو تحديث حالة، أو استدعاء API طرف ثالث.
• الموارد (Resources): بيانات ثابتة أو شبه ثابتة يمكن للنموذج الرجوع إليها عبر URI. فكر في الملفات، أو وثائق التكوين، أو مجموعات البيانات المرجعية.
• المطالبات (Prompts): قوالب محددة مسبقًا تساعد المستخدم على التفاعل مع النظام.

هناك تمييز هام في التحكم يجب تذكره. الأدوات يتم التحكم فيها بواسطة النموذج (model-controlled)؛ حيث يقرر المساعد متى يستدعي إحداها. أما الموارد فيتم التحكم فيها بواسطة التطبيق (application-controlled)؛ حيث يقرر الخادم البيانات المتاحة ويقوم النموذج ببساطة بقراءة ما يتم تقديمه. إن ضبط هذا الأمر بشكل صحيح يحافظ على قابلية التنبؤ بهيكلية نظامك. فأنت لا تريد نموذجًا يبحث عن موارد كان ينبغي أن تكون أدوات، أو العكس.

كيفية عمل النقل (Transport)

يحدد MCP طريقتين للنقل، واختيارك يحدد كيفية كتابة جانب PHP.

stdio هي الطريقة الأبسط. يقوم عميل MCP بتشغيل سكربت PHP الخاص بك كعملية فرعية (subprocess). يكتب عميل MCP رسائل JSON-RPC إلى المدخلات القياسية (standard input) للسكربت الخاص بك، ويكتب السكربت الخاص بك الردود إلى المخرجات القياسية (standard output). لا توجد مقابس (sockets) لإدارتها، ولا منافذ (ports) لفتحها، ولا ترويسات مصادقة (authentication headers) لتحليلها. إذا كانت أداتك وعميلك يعملان على نفس الجهاز، فهذا عادةً هو المكان الصحيح للبدء.

فرض التشغيل عبر stdio قاعدتين صارمتين على عملية PHP الخاصة بك. أولاً، يجب ألا يكتب تطبيقك أبدًا بيانات غير تابعة للبروتوكول إلى stdout. إذا قمت بطباعة جملة تصحيح (debug statement) أو سمحت بتسرب تنبيه PHP (PHP notice)، فستؤدي إلى كسر محلل (parser) العميل. قم بتوجيه جميع عمليات التسجيل (logging) والتشخيص إلى stderr. ثانياً، قم بتعطيل تخزين المخرجات مؤقتًا (output buffering) تمامًا. تحب PHP تخزين stdout مؤقتًا، خاصة في سياقات CGI أو الويب، ولكن حتى سكربتات CLI يمكن أن تحتفظ بالبيانات. قم بتفريغ (flush) كل استجابة فوراً. إذا كنت تستخدم التدفقات (streams)، فقم بضبط stream_set_write_buffer(STDOUT, 0) أو أوقف التخزين المؤقت الضمني حتى يتلقى العميل سطر الجديد فور إرساله.

Streamable HTTP يعمل بشكل مختلف. يعمل تطبيق PHP الخاص بك كنقطة نهاية HTTP مستمرة، يتم الوصول إليها عادةً عبر طلبات POST. هذا مفيد عندما يكون الخادم على مضيف مختلف، أو عندما تريد تشغيل برنامج خلفية (daemon) طويل الأمد يمكن لعدة عملاء الوصول إليه. في PHP، يعني هذا عادةً التشغيل تحت إدارة RoadRunner أو FrankenPHP أو مدير عمليات مماثل بدلاً من دورة الطلب والاستجابة التقليدية التي تنتهي بعد كل استدعاء.

بناؤه باستخدام PHP

لا تحتاج إلى إطار عمل للبدء. خادم MCP بسيط في PHP هو عبارة عن حلقة (loop) تقرأ من STDIN وتفك تشفير JSON، وتوزع المهام إلى معالج (handler)، وتُشفر النتيجة.

while ($line = fgets(STDIN)) {
    $request = json_decode($line, true);
    // route to tool or resource handler
    // write JSON-RPC response to STDOUT
}

داخل تلك الحلقة، يكمن العمل الحقيقي في بناء واجهات منطقية للنموذج.

توليد مخططات الأدوات من الكود. إحدى أسرع الطرق للتسبب في المشاكل هي كتابة مخططات JSON يدوياً لمعلمات الأدوات (tool parameters)، مما يؤدي إلى عدم توافقها مع منطق التحقق (validation logic) الفعلي لديك. تتميز لغة PHP بقدرات انعكاس (reflection) غنية؛ حيث يمكنك فحص تواقيع الدوال (method signatures)، وقراءة قواعد التحقق الموجودة في نماذجك أو كائنات الأوامر (command objects)، وتوليد المخطط من تلك القيود. إذا كان الكود الداخلي لديك يتطلب تنسيق بريد إلكتروني صالح، فيجب أن يذكر مخطط MCP الشيء نفسه. عندما تتغير قواعد التحقق، يتم تحديث المخطط تلقائياً. لا يوجد تفاوت، ولا توجد إخفاقات صامتة.

افصل بين أخطاء البروتوكول وأخطاء الأدوات. يمتلك JSON-RPC مساحة أخطاء خاصة به. استخدمها للأخطاء المتعلقة بالبروتوكول: مثل JSON غير الصحيح، أو الطرق غير المعروفة، أو فقدان معرفات الطلب (request IDs). عندما تعمل الأداة بشكل صحيح ولكنها تواجه مشكلة في منطق العمل (business problem)، فقم بإرجاع نتيجة عادية مع علامة خطأ داخل الحمولة (payload). إذا لم تجد أداة البحث عن العملاء أي سجل مطابق، فهذا ليس انهياراً في البروتوكول. إرجاع نتيجة مهيكلة مثل {"found": false} يتيح للنموذج فهم ما حدث واختيار الخطوة التالية؛ فقد يحاول إجراء بحث أوسع، أو قد يطلب توضيحاً من المستخدم. أما إذا قمت بإلقاء خطأ JSON-RPC، فغالباً ما يفقد النموذج السياق.

خطط للمهام التي تستغرق وقتاً طويلاً. صُممت PHP للطلبات القصيرة. قد ينتهي وقت طلب الويب في ثلاثين ثانية، وحتى نصوص CLI يمكن أن تستهلك الذاكرة أو الصبر. إذا كانت الأداة تحتاج إلى دقائق لتنتهي — ربما لإنشاء تقرير كبير أو مزامنة البيانات عبر الأنظمة — فلا تجعل النموذج ينتظر. أرجع معرف المهمة (job identifier) على الفور، ثم وفّر أداة ثانية للتحقق من الحالة باستخدام ذلك المعرف. يمكنك تخزين التقدم في Redis، أو جدول قاعدة بيانات، أو حتى ملف بسيط إذا كان الحجم منخفضاً. يتلقى النموذج المعرف، ثم يتحقق لاحقاً، وفي النهاية يحصل على النتيجة المكتملة.

الأمان عندما يمتلك النموذج مفاتيح الوصول

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

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

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

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

قم بتصفية مخرجاتك. لا تقم بتحويل نموذج Eloquent كامل أو كيان Doctrine إلى سلسلة (serialize) وتفريغه في النتيجة. أرجع فقط الحقول التي يحتاجها النموذج فعلياً. الحقول الداخلية — مثل أسعار التكلفة، ملاحظات الموظفين، معرفات قاعدة البيانات التي يجب أن تظل داخلية — ليس من شأنها عبور الشبكة. كن صريحاً بشأن شكل البيانات المرتجعة.

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

من أين تبدأ

لا تحتاج إلى إذن من مطور حزمة SDK لربط تطبيق PHP الخاص بك بمساعد ذكاء اصطناعي. أنت بحاجة إلى JSON-RPC، وحلقة تكرار (loop)، وبعض الانضباط فيما يتعلق بـ stdout.

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

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