MCP Servers بالعربي: اربط Claude بأدواتك من غير ما تبني API لكل أداة
مستوى المقال: متوسط — يفترض إنك جربت function calling قبل كده مع Claude أو OpenAI، وعندك خلفية أساسية في Python و JSON-RPC مش لازمة بس بتساعد.
لو ربطت Claude بـ 3 أدوات داخلية (DB، نظام التذاكر، Notion)، وكل client جديد (Cursor، Claude Desktop، تطبيقك) بيطلب منك تكتب نفس الـ wrappers من جديد، أنت بتدفع ضريبة integration مكررة. Model Context Protocol (MCP) بيحل المشكلة دي ببروتوكول واحد بين النموذج وأدواتك. تكتب الـ server مرة، وأي client متوافق بيستخدمه على طول.
المشكلة باختصار
قبل MCP، لو عندك 4 أدوات و 3 LLM clients، أنت محتاج تبني وتصون 12 integration منفصل. كل client بياخد JSON schema بشكل مختلف شوية، كل API بيرجع errors بصيغة مختلفة، وكل تحديث في أداة بيخليك تعدّل في 3 أماكن. الكود بيتحول لـ glue code أكتر من business logic.
الـ trade-off القديم: يا إما تعمل كود مكرر ومتشتت، يا إما تبني abstraction layer داخلية بنفسك (وتصونها لوحدك). MCP بيقدم layer جاهزة ومفتوحة المصدر بدلًا منك.
مثال للمبتدئ: فكر في MCP زي USB-C
تخيل عندك لابتوب وعايز توصله بشاشة، فلاش، شاحن، وكاميرا. زمان كل جهاز كان له منفذ مختلف: HDMI، USB-A، Mini-DisplayPort، وهكذا. كل ما تشتري لابتوب جديد لازم تشتري dongles جديدة.
USB-C وحّد كل ده في منفذ واحد. أي جهاز يدعم USB-C بيشتغل مع أي لابتوب يدعم USB-C، بدون dongle. MCP هو USB-C في عالم الـ AI tools. النموذج (الـ client) فيه منفذ واحد بياخد توصيلة من أي MCP server، وأنت كمطوّر بتبني server واحد فقط.
التعريف العلمي الدقيق
MCP هو بروتوكول مفتوح أنشأته Anthropic في نوفمبر 2024، ومبني على JSON-RPC 2.0. البروتوكول بيعرّف 3 primitives رسمية:
- Tools — دوال يقدر النموذج يستدعيها (زي function calling لكن standardized).
- Resources — بيانات يقدر النموذج يقراها (ملفات، rows من DB، صفحات Notion).
- Prompts — قوالب جاهزة يقدر المستخدم يختارها من واجهة الـ client.
الـ transport layer بتدعم stdio (للـ servers المحلية)، و HTTP + SSE (للـ servers البعيدة). الـ handshake بيبدأ بـ initialize message والـ client بيستقبل قائمة الأدوات المتاحة عن طريق tools/list.
مثال تنفيذي: MCP server بـ 30 سطر Python
هنبني server بسيط بيوفر أداة واحدة: get_user_orders. الافتراض: عندك Postgres محلي وجدول orders.
pip install mcp psycopg2-binaryfrom mcp.server.fastmcp import FastMCP
import psycopg2
mcp = FastMCP("orders-server")
@mcp.tool()
def get_user_orders(user_id: int, limit: int = 10) -> list[dict]:
"""Return latest orders for a given user_id, newest first."""
conn = psycopg2.connect("dbname=shop user=postgres")
cur = conn.cursor()
cur.execute(
"SELECT id, total, status, created_at "
"FROM orders WHERE user_id = %s "
"ORDER BY created_at DESC LIMIT %s",
(user_id, limit),
)
rows = cur.fetchall()
conn.close()
return [
{"id": r[0], "total": float(r[1]), "status": r[2], "created_at": str(r[3])}
for r in rows
]
if __name__ == "__main__":
mcp.run(transport="stdio")
ده server كامل وشغّال. الـ docstring بيتحول تلقائيًا لـ description في الـ tool schema، والـ type hints بتتحول لـ JSON schema. أنت ما كتبتش JSON schema يدويًا.
التشغيل والربط مع Claude Desktop
في ملف ~/Library/Application Support/Claude/claude_desktop_config.json (على macOS):
{
"mcpServers": {
"orders": {
"command": "python",
"args": ["/absolute/path/to/orders_server.py"]
}
}
}
افتح 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