خادم MCP يعمل. الوكيل لا يعمل.
انفجر MCP قبل عام. الجميع تسابق لبناء الخوادم. الحماس كان حقيقياً.
معظم خوادم MCP تخيّب التوقعات.
المطورون يلومون البروتوكول. على وسائل التواصل الاجتماعي يبدو وكأن MCP يحتضر. لكن التبني المؤسسي يروي قصة مختلفة. الشركات تنشر. التكاملات تعمل. النتائج لا تزال مخيبة.
لماذا؟
المطورون يتعاملون مع MCP كغلاف لواجهة REST API. فريق Block تعلّم هذا أثناء بناء أكثر من 60 خادماً. Philipp Schmid قالها بوضوح: MCP هو واجهة مستخدم للوكلاء، وليس للمطورين. مستخدمون مختلفون. مبادئ تصميم مختلفة.
البروتوكول يعمل بشكل جيد. الخوادم لا تعمل.
إليك ما يخطئ فيه المطورون وكيفية إصلاحه.
النموذج الذهني الخاطئ
عندما يبني معظم المطورين خادم MCP، يفتحون وثائق API ويبدأون بربط نقاط النهاية بالأدوات.
GET /users يصبح get_user(). POST /orders يصبح create_order(). نظيف، منطقي، مألوف.
المشكلة أن تصميم API مبني للمطورين البشر.
| المطورون | الوكلاء | |
|---|---|---|
| الاكتشاف | رخيص — اقرأ الوثائق مرة واحدة | مكلف — المخطط يُحمّل في كل طلب |
| التركيب | امزج وطابق نقاط نهاية صغيرة | استدعاءات أدوات متعددة الخطوات، تكرار بطيء |
| المرونة | خيارات أكثر، مرونة أكثر | التعقيد يؤدي إلى الهلوسة |
المطور يقرأ الوثائق مرة واحدة وينتقل. نموذج اللغة يدفع هذه التكلفة في كل طلب. كل وصف أداة يُحمّل في نافذة السياق. كل نتيجة وسيطة تُخزّن في سجل المحادثة.
أنت لا تبني واجهة API. أنت تبني واجهة مستخدم لمستخدم غير بشري. صمّمها كذلك.
الخطأ الأول: ثلاث أدوات حيث يجب أن تكون واحدة
هذا هو النمط الأكثر شيوعاً.
مطور يبني خادم MCP لتتبع الطلبات. يكشف:
get_user_by_email(email)list_orders(user_id)get_order_status(order_id)
منطقي. قابل للتركيب. بالضبط كما يجب أن تعمل واجهة REST API.
الآن الوكيل يجب أن يجيب: "ما حالة آخر طلب لهذا العميل؟"
ثلاث استدعاءات أدوات. ثلاث رحلات ذهاب وإياب. ثلاث مجموعات نتائج في نافذة السياق. الوكيل يجب أن ينسّق التسلسل بالكامل — رموز أكثر، تأخير أكثر، مساحة أكبر لحدوث خطأ.
الحل هو أداة واحدة: track_latest_order(email). تستدعي الثلاث داخلياً وتُعيد إجابة واحدة نظيفة: "الطلب #12345 شُحن عبر FedEx، يصل الخميس."
نفس النتيجة. استدعاء واحد.
قم بالتنسيق في الكود. ليس في نافذة سياق نموذج اللغة. عندما تجد نفسك تبني أدوات سيستدعيها الوكيل دائماً بالتسلسل، ادمجها. القابلية للتركيب التي تجعل واجهات API أنيقة تجعل خوادم MCP هشّة.
الخطأ الثاني: تفريغ استجابات API الخام
واجهة API تُعيد كائن JSON من 47 حقلاً. فالأداة تُعيد كائن JSON من 47 حقلاً.
هذا الكائن يعيش الآن في نافذة السياق لبقية المحادثة.
كل حقل لا يحتاجه الوكيل هو وزن ميت ينافس على الانتباه. في سير العمل الطويلة للوكلاء يتراكم هذا بسرعة. أنت لا تهدر رموزاً في استدعاء واحد. أنت تُضعف كل استدعاء لاحق في الجلسة.
مثال Gmail من Philschmid يوضح هذا. قبل:
def messages_get(message_id, format) -> {"id", "snippet", "payload": {"headers", "body": {"data"}}}
الوكيل يجب أن يحلل كائنات payload متداخلة ويفك تشفير محتوى base64 فقط لقراءة بريد إلكتروني.
بعد:
def gmail_read(message_id) -> {"subject", "sender", "body", "attachments"}
نفس البيانات. قابلة للقراءة البشرية. بدون عبء تحليل.
أعد بالضبط ما يحتاجه الوكيل لإكمال الخطوة التالية. لا أكثر. تنسيق المخرجات ليس تحسيناً. إنه الوظيفة.
الخطأ الثالث: أسماء أدوات عامة
خادم MCP لا يعمل بمعزل. يعمل بجانب خوادم أخرى.
إذا كان GitHub و Jira كلاهما يكشف create_issue، الوكيل يخمّن أيهما يستدعي. أحياناً يخمّن صحيحاً.
نمط Block من أكثر من 60 خادماً: استخدم أسماء مسبوقة بالخدمة وموجهة بالإجراء.
{service}_{action}_{resource}
فيصبح create_issue هو linear_create_issue. و send_message يصبح slack_send_message. و get_error_details يصبح sentry_get_error_details.
الوكيل يجد الأداة الصحيحة أسرع. استدعاءات خاطئة أقل. سياق مهدر أقل.
الخطأ الرابع: التعامل مع سلاسل التوثيق كشكليات
أسماء الأدوات وأوصافها ليست توثيقاً. إنها أوامر.
النموذج يقرأ سلسلة التوثيق ليقرر متى يستدعي الأداة، وماذا يمرر، وماذا يتوقع. سلسلة توثيق غامضة هي تعليمات غامضة. النموذج يخمّن.
Block قالها مباشرة: أسماء الأدوات والأوصاف والمعلمات تُعامل كأوامر لنموذج اللغة. ضبطها بشكل صحيح مهم بقدر أهمية منطق الأداة نفسها.
اكتبها كتعليمات. حدد:
- متى تُستخدم هذه الأداة، وليس فقط ماذا تفعل
- الصيغة المتوقعة لكل وسيط
- كيف تبدو الاستجابة الناجحة
- ماذا تجرب إذا فشلت
النقطة الأخيرة أهم مما يدركه معظم الناس.
الخطأ الخامس: إلقاء الاستثناءات بدلاً من إعادة السياق
عندما تفشل أداة، معظم التطبيقات تلقي خطأً وتتركه ينتشر.
الوكيل لا يعرف ما الخطأ أو ماذا يجرب بعد ذلك.
الحل: أعد نصاً مفيداً بدلاً من ذلك.
"المستخدم غير موجود. يرجى محاولة البحث بعنوان البريد الإلكتروني بدلاً من ذلك."
هذه ليست رسالة خطأ. هذه تعليمات. الوكيل يقرأها كملاحظة ويستخدمها لتصحيح نفسه في الدور التالي.
قاعدة Philschmid: لا تلقِ استثناء Python. أعد سياقاً. الوكيل يرى الخطأ ويتعافى. بدونه، الوكيل يهلوس مسار تعافٍ أو يتوقف كلياً.
معالجة الأخطاء جزء من تجربة المستخدم.
الخطأ السادس: كشف كل ما يمكن لنظامك فعله
أدوات أكثر تبدو كقدرة أكثر. ليست كذلك.
كل أداة تكشفها تضيف إلى عبء الأوصاف الذي يُحمّل في كل طلب. أدوات أكثر تعني قرارات أكثر للنموذج. قرارات أكثر تعني فرصة أعلى لاختيار الخاطئة.
Block و Philschmid يصلان إلى نفس الرقم بشكل مستقل: 5 إلى 15 أداة لكل خادم. خادم واحد، وظيفة واحدة.
إذا كان خادمك يتعامل مع بيانات CRM وتذاكر الدعم وسجلات الفواتير والملاحظات الداخلية، فقد بنيت أربعة خوادم تتشارك عملية واحدة. افصلها. حدد نطاقها. احذف الأدوات التي لا يستدعيها أحد.
نماذج اللغة لا تزال ضعيفة في التخطيط عبر خطوات كثيرة. فريق Block يشير إلى هذا صراحة. صمم خادمك ليحتاج تسلسلاً أقل، لا أكثر. أدوات أقل محددة النطاق تتفوق على أدوات كثيرة سيئة النطاق في كل مرة.
النمط الكامن وراء كل هذه الأخطاء
كل خطأ هنا يأتي من نفس المكان: التصميم للنظام، وليس للوكيل.
مبادئ REST API: القابلية للتركيب، المرونة، قابلية الاكتشاف. تعمل للمطورين البشر. لا تعمل لوكلاء الذكاء الاصطناعي.
MCP هو واجهة مستخدم لمستخدم غير بشري. نفس التفكير المنتجي، مستخدم مختلف.
ادمج استدعاءات الأدوات. جرّد الاستجابات. سمِّ للاكتشاف. اكتب سلاسل التوثيق كتعليمات. أعد سياقاً عند الفشل. حافظ على مساحة السطح صغيرة.
ابنِه كما لو أن المستخدم وكيل. لأنه كذلك.
هذا المقال مستوحى من أفضل ممارسات MCP لـ Philipp Schmid ودليل Block لتصميم خوادم MCP. كلاهما يستحق القراءة بالكامل.