MCP Servers بالعربي: اربط Claude بأدواتك من غير ما تبني API لكل أداة

pip install mcp psycopg2-binary

ده server كامل وشغّال. الـ docstring بيتحول تلقائيًا لـ description في الـ tool schema، والـ type hints بتتحول لـ JSON schema. أنت ما كتبتش JSON schema يدويًا.

التشغيل والربط مع Claude Desktop

في ملف ~/Library/Application Support/Claude/claude_desktop_config.json (على macOS):

افتح Claude Desktop وهتلاقي الأداة ظهرت في القائمة. اسأل Claude: "اعرض لي آخر 5 طلبات للمستخدم 42"، وهيستدعي get_user_orders تلقائيًا.

سيناريو واقعي: شركة بـ 7 أدوات داخلية

الافتراض: شركة SaaS عندها 7 أدوات داخلية (DB، Stripe، Intercom، Linear، GitHub، Notion، Sentry)، و 3 clients (Cursor للمطوّرين، Claude Desktop للـ support، تطبيق ويب للعملاء).

• قبل MCP: 7 × 3 = 21 integration، كل واحد بـ ~150 سطر glue code → ≈ 3150 سطر يتم صيانتها.
• بعد MCP: 7 servers فقط، كل client بيقرأهم بنفس الطريقة → ≈ 1050 سطر إجمالي.

الفرق ~66% أقل كود. ده مش بس لحظة كتابة، ده تكلفة maintenance على مدى سنة. لو في مطوّر بيصرف يوم في الأسبوع على integration glue، هتوفّر ~16 يوم مطوّر سنويًا للفريق المتوسط.

الـ trade-offs اللي لازم تعرفها

MCP مش حل سحري. اللي بتكسبه:

• توحيد الـ interface عبر clients مختلفة.
• أدوات جاهزة من المجتمع (في 200+ MCP server مفتوح المصدر حسب modelcontextprotocol.io).
• discovery تلقائي من الـ client (المستخدم بيشوف الأدوات بدون configuration يدوي إضافي لكل أداة).

اللي بتدفعه:

• طبقة إضافية للـ debugging. لو حصل error، لازم تشيك في 3 أماكن: الـ client، الـ MCP transport، والـ tool نفسها.
• Latency overhead صغيرة. الـ stdio transport بيضيف ~5-15ms لكل tool call مقارنة بـ direct function call داخل نفس الـ process. على HTTP بيوصل لـ 50-100ms حسب الشبكة.
• الأمان مسؤوليتك. الـ MCP server بيشتغل بصلاحياتك. لو فتحت أداة execute_sql بدون whitelist، الـ LLM ممكن يحذف جدول. لازم authorization layer جوّه الـ server.

متى لا تستخدم MCP

الطريقة دي بتفشل أو بتبقى overkill في الحالات دي:

• أداة واحدة بسيطة + client واحد. لو بتبني bot صغير في Slack بيتكلم مع API واحد، function calling المباشر أبسط وأسرع. MCP بيستحق التعب لو عندك ≥ 3 أدوات أو ≥ 2 clients.
• Latency-critical paths. لو أداتك لازم ترد في أقل من 10ms (real-time trading، voice agents)، الـ overhead بتاع MCP transport ممكن يبقى مشكلة. ابنِ integration مباشر.
• بيئات شديدة التقييد. لو الـ stack بتاعك ما بيسمحش بـ subprocess (serverless مع cold starts قاسية، أو Lambda بدون container)، الـ stdio transport هيتعبك. استخدم HTTP transport أو ابعد عن MCP خالص.
• أدوات حساسة للأمان من غير authorization طبقة. لو ما بتقدرش تحط Auth layer بين الـ LLM والأداة، MCP بيوسّع الـ blast radius. ابدأ بـ read-only فقط لحد ما تبني السياسات.

مفاهيم متقدمة بسرعة

Resources مقابل Tools

الفرق الدقيق: Tools بيستدعيها النموذج لما يحتاج (action). Resources بيقراها الـ client مرة واحدة ويحط محتواها في الـ context (data). لو عندك ملف configuration ثابت، خليه resource. لو عندك query بيتغير، خليه tool.

Sampling

الـ MCP server يقدر يطلب من الـ client نفسه يعمل LLM call (سامبلينغ معكوس). ده مفيد في agents تكتب sub-agents، لكن في مرحلة preview ومش كل client بيدعمه.

الخطوة التالية

افتح أبسط أداة داخلية عندك (يفضّل read-only لتقليل المخاطر)، نزّل pip install mcp، اكتب server بـ tool واحدة باتّباع المثال فوق، وربطه بـ Claude Desktop. لو شغّال في 30 دقيقة، أنت دلوقتي عارف هل MCP يستحق التوسع لباقي أدواتك ولا لأ. لو الأداة الأولى مفيدة، التانية هتاخد ربع الوقت.

المصادر

• التوثيق الرسمي للبروتوكول: modelcontextprotocol.io
• إعلان Anthropic الرسمي (نوفمبر 2024): anthropic.com/news/model-context-protocol
• Python SDK على GitHub: github.com/modelcontextprotocol/python-sdk
• قائمة الـ servers الجاهزة: github.com/modelcontextprotocol/servers
• مواصفات JSON-RPC 2.0: jsonrpc.org/specification
• توثيق إعداد Claude Desktop مع MCP: modelcontextprotocol.io/quickstart/user