التفاوض على القدرات

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

يُبرم هذا الاتفاق أثناء مصافحة initialize، أي أول تبادل على الإطلاق. بعد ذلك يعرف كل طرف ما يقدمه الآخر وما هو غير متاح.

يعلن العميل عن clientCapabilities، ويعلن الخادم عن serverCapabilities. وكل مجموعة ليست سوى خريطة لعلامات الميزات وبعض الخيارات الصغيرة.

يسرد الخادم ما يقدمه، مثل tools والموارد والمطالبات. وإذا كان المفتاح غائبًا، يعرف العملاء ألا يتوقعوا منك تلك الوظيفة الأساسية.

يسرد العميل الميزات التي يستطيع تقديمها للطرف الآخر، مثل roots وأخذ العينات والاستجلاب. وهكذا يتعلم خادمك أنه يستطيع أصلًا طلب الجذور.

يمكن أن تحتوي الإمكانية على خيارات إضافية. فمثلًا، قد تحمل الجذور listChanged: true، ما يعني أن العميل سيُخطرك عند تغير مجموعة جذوره.

القاعدة بسيطة: إذا كانت الإمكانية مفقودة، فاعتبر الميزة غير متاحة. لا تستدعِ مطلقًا شيئًا لم يتعهد الطرف الآخر بقدرته على تنفيذه.

إلى جانب الميزات، يرسل الطرفان protocolVersion. ويجب أن يتفقا على إصدار مشترك، وإلا رُفضت الجلسة قبل بدء أي عمل فعلي.

نادرًا ما تنشئ هذه الخرائط يدويًا. إذ يتولى Python SDK ملء إمكانات خادمك من الأدوات والموارد التي سجلتها، ثم يتبادلها نيابةً عنك.

بعد init، يمكنك فحص إمكانات العميل التي التقطتها جلستك. وهذا الفحص هو بالضبط ما يحمي استدعاءً اختياريًا مثل list_roots.

تُحسم الإمكانات عند بدء التشغيل وتظل سارية طوال الجلسة. ويمكنك الاعتماد عليها طوال عمر الاتصال دون إعادة التفاوض عند كل استدعاء.

عند initialize، يتبادل العميل والخادم خرائط الإمكانات وإصدار البروتوكول. وتعني العلامة المفقودة عدم الدعم، بينما ينشئ SDK هذه الخرائط ويقرأها نيابةً عنك. 🎯