الـ MCP من الناحية التانية — الـ Client والـ Host — MCP Clients & Hosts

فكّر في الموضوع زي مطعم:

• الـ Server = المطبخ. بيقدّم أطباق (أدوات) وبيقول «دي القايمة بتاعتي».
• الـ Client = الجرسون المخصص لمطبخ واحد. بيروح ييجي بين الصالة والمطبخ ده بس.
• الـ Host = المطعم نفسه. بيدير كل الجرسونات، بيجمّع القوايم من كل المطابخ في منيو واحد، وبيوصّل الطلبات للزبون (الموديل).

الزبون (الموديل) بيشوف منيو واحد بس. مبيعرفش إن ورا الكواليس فيه 5 مطابخ وServers. الـ Host هو اللي بيخفي التعقيد ده ويقدّم كل شيء كواجهة واحدة.

<!-- Field 6: Real-world analogy (Layer 2) -->

تخيّل مكتب فيه موظف جديد (الموديل) لسه أول يوم. المكتب فيه أقسام كتير: قسم قانوني، قسم مالي، قسم موارد بشرية — كل قسم عنده خدماته ونظامه.

• كل قسم = Server، بيقدّم خدماته الخاصة.
• كل مرة الموظف محتاج يكلّم قسم، فيه موظف تنسيق مخصص للقسم ده = Client.
• بس مين نظّم كل ده؟ مين قال للموظف الجديد «دي كل الأقسام المتاحة، ودي خدمة كل واحد»؟ مين بيوجّه طلبه للقسم الصح؟ مين بيقوله «الطلب ده محتاج موافقة المدير الأول»؟ ده مكتب الإدارة = الhost.

الموظف الجديد (الموديل) شاطر، بس لوحده تايه. الـ Host هو اللي بيعمله الخريطة، بيوصّله بالأقسام، وبيحطّ قواعد اللعبة. لاحظ: الذكاء في الموظف، بس التنظيم في المكتب. الـ Host مش بيفكّر مكان الموديل — بيمكّنه من إنه يشتغل بترتيب.

<!-- Field 7: Simple example -->

مثال حقيقي

خلّي عندك Copilot داخلي لشركة، موصّل بتلات Servers:

> - Server 1 — Docs: أداة search_wiki > - Server 2 — Jira: أدوات list_issues + create_issue > - Server 3 — Calendar: أداة find_free_slot

الموظف يكتب: «دوّرلي على تذاكر الـ bugs المفتوحة، واحجزلي ساعة بكرة أراجعها».

اللي بيحصل جوّه الـ Host: 1. التجميع: الـ Host جمّع الأدوات الأربعة من التلات Servers في منيو واحد قدّم للموديل. 2. التوجيه: الموديل قرر يستخدم list_issues → الـ Host وجّه الطلب لـ Client الـ Jira بالظبط، مش أي Client تاني. 3. الموافقة: الموديل بعدين قرر find_free_slot وبعده حجز → الـ Host عرض للموظف: «أحجز ساعة 11 بكرة؟». 4. الرجوع: كل نتيجة رجعت للموديل عن طريق الـ Host، فكمّل الرد.

الموظف شاف تجربة واحدة سلسة. الـ Host هو اللي مسك التعقيد كله.

<!-- Field 8: How it works (Layer 3) -->

الـ Host بيعمل خمس شغلانات أساسية. دي «الوصف الوظيفي» بتاعه:

1. Discovery — الاكتشاف: يسأل كل Server موصّل «إيه القدرات عندك؟» ويجمّع الردود. ده بيحصل عند بداية الاتصال (Capability Negotiation). 2. إدارة دورة الاتصال (Connection Lifecycle): يفتح الاتصال بكل Server، يحافظ عليه، يقفله بترتيب، ويتعامل مع الانقطاع. 3. تجميع الأدوات (Tool Aggregation): يجمّع أدوات كل الـ Servers في قايمة واحدة يقدّمها للموديل — مع حلّ تعارض الأسماء (لو Server-ين عندهم أداة بنفس الاسم). 4. التوجيه (Routing): لما الموديل يطلب أداة، الـ Host يعرف الأداة دي من أي Server، ويبعت الطلب للـ Client الصح. 5. الصلاحيات والموافقات (Permissions UI): يعرض للمستخدم أي أداة الـ Agent عايز يستخدمها، وياخد موافقة على الأفعال الحساسة.

الحتة اللي بتلخبط الناس: الـ Client مش هو الـ Host. الـ Client صغير ومملّ — بيتكلم مع Server واحد وخلاص. الـ Host هو العقل المدبّر اللي بيدير الـ Clients دول كلهم. تطبيق واحد (Host) بيحتوي جوّاه Clients متعددة، Client لكل Server.

<!-- Field 9: Step-by-step explanation -->

خطوة بخطوة — رحلة طلب كاملة

خلينا نتتبّع سؤال واحد من أوله لآخره، عبر الأدوار التلاتة:

الإعداد (مرة واحدة عند التشغيل): 1. الـ Host بيقرّر يوصّل بـ 3 Servers → بيعمل Client لكل واحد. 2. كل Client بيفتح اتصال بـ Server-ه، ويسأله عن قدراته (Discovery). 3. الـ Host بيجمّع الأدوات كلها (Aggregation) في منيو واحد.

وقت السؤال (كل مرة): 4. المستخدم بيبعت سؤال للـ Host. 5. الـ Host بيبعت السؤال + منيو الأدوات المجمّع للـ LLM. 6. الموديل بيقرّر: «محتاج أداة search_wiki». 7. الـ Host بيشوف الأداة دي من أنهي Server → بيوجّه الطلب للـ Client الصح (Routing). 8. الـ Client بيبعت للـ Server، الـ Server ينفّذ، ويرجّع النتيجة. 9. النتيجة بترجع عبر الـ Client للـ Host، والـ Host بيحطّها في Context الموديل. 10. الموديل بيكمّل — يجاوب، أو يطلب أداة تانية (رجوع للخطوة 6).

لاحظ: الخطوات 6→9 ممكن تتكرر كذا مرة في نفس السؤال (Agent Loop). والـ Host ماسك الخيط في كل دورة.

<!-- Field 10: Visual explanation -->

بالرسم

الأدوار التلاتة، ورحلة الطلب الكاملة:

┌───────────────────────── HOST (تطبيقك) ─────────────────────────┐
│                                                                 │
│   User ──► [ Host logic ]                                        │
│                 │  ▲                                             │
│                 ▼  │                                             │
│              [  LLM  ]  ◄── منيو الأدوات المجمّع (Aggregation)     │
│                 │  ▲                                             │
│      Tool Call  │  │  Tool Result                                │
│                 ▼  │                                             │
│         [ Routing: الأداة دي من أنهي Server؟ ]                    │
│           │            │             │                          │
│           ▼            ▼             ▼                          │
│       Client A     Client B     Client C                        │
└───────────┼────────────┼─────────────┼─────────────────────────┘
            │            │             │
            ▼            ▼             ▼
        Server A     Server B     Server C
        (Docs)       (Jira)       (Calendar)
      يقدّم أدوات    يقدّم أدوات    يقدّم أدوات

  رحلة كاملة (round trip):
  user → host → LLM → tool call → routing → client → server
       → result → client → host → LLM → answer

خد بالك من حاجة في الرسمة: الموديل بيشوف صندوق واحد (منيو مجمّع)، مبيشوفش التلات Servers. ده جوهر شغل الـ Host: بيخفي التعدد ويقدّم واجهة واحدة. والـ Clients (A, B, C) كل واحد أعمى عن التاني — كل واحد بيعرف Server-ه بس. الـ Host وحده هو اللي شايف الصورة كاملة.

<!-- Field 11: Technical explanation (Layer 4) -->

أول حاجة تثبتها: العلاقة بين Client و Server علاقة 1-إلى-1؛ والعلاقة بين Host و Clients علاقة 1-إلى-كتير. الـ Host بيحتوي جوّاه N من الـ Clients، كل Client مربوط بـ Server واحد. ده التقسيم المعماري اللي لو فهمته، فهمت الباقي.

تاني حاجة: الـ Client متعمّد إنه يكون رقيق وغبي (thin). كل شغله إنه يتكلم بروتوكول MCP مع Server واحد: يفتح اتصال، يعمل Discovery، يبعت طلبات ويستقبل ردود. مفيهوش منطق أعمال. ده تصميم مقصود — بيخلّي الـ Client قابل لإعادة الاستخدام، والتعقيد كله متجمّع في مكان واحد (الـ Host).

تالت حاجة، وهي أهم نقطة تحكم: Sampling بيقلب اتجاه المبادرة. العادة إن الـ Host بيطلب من الـ Server (استخدم أداة). الـ Sampling بيعكس: الـ Server بيطلب من الـ Host إنه يسأل الـ LLM نيابةً عنه. ليه ده موجود؟ عشان Server يقدر يعمل خطوة ذكية (يلخّص، يصنّف) من غير ما يكون عنده موديل خاص بيه أو مفتاح API. الـ Server بيستعير «مخ» الـ Host. الأثر على التحكم: الـ Host لازم يفضل هو صاحب القرار — يراجع طلب الـ Sampling، ممكن يعرضه للمستخدم، ويتحكم في التكلفة، مش يمرّره أعمى. لأنك بتدّي Server طرف تالت قناة يستهلك بيها موديلك (وفلوسك).

رابع حاجة: Roots بتحدّد نطاق رؤية الـ Server. الـ Root هو زي «المجلد المسموح» — الـ Host بيقول للـ Server «أنت مسموح تشوف الحدود دي بس» (مثلًا مجلد مشروع معيّن، مش الجهاز كله). ده سياج على «إيه اللي الـ Server يقدر يوصّله»، وأداة أمان مهمة في التحكم في الاستهلاك.

<!-- Field 12: Developer perspective (API-level reality) -->

على مستوى الـ API — الواقع العملي

خمس حقايق هتقابلك أول ما تبني Host:

• تعارض أسماء الأدوات حقيقي. لو Server-ين عندهم أداة اسمها search، لازم تعمل Namespacing (زي jira.search و docs.search) قبل ما تقدّمهم للموديل — وإلا التوجيه هيلخبط.
• دورة الاتصال محتاجة إدارة صريحة. Servers بتفصل، بتبوظ، بتبقى بطيئة. الـ Host لازم يتعامل مع Server واقع من غير ما ينهار النظام كله — والأدوات بتاعته تختفي من المنيو بأدب.
• منيو أدوات كبير بيكلّفك Tokens وبيشتّت الموديل. كل وصف أداة بيدخل الـ Context بتاع الموديل. 50 أداة من 10 Servers = Context متضخّم + قرارات أسوأ. صفِّي الأدوات المتاحة حسب السياق — مش تحطّ كل حاجة قدّام الموديل دايمًا.
• Sampling محتاج حوكمة. لو سمحت للـ Servers تعمل Sampling، حط سقف تكلفة، راجع الطلبات، ويفضّل موافقة على الأقل أول مرة. Server بيطلب Sampling في Loop ممكن يفاجئك بفاتورة.
• الموافقات لازم تكون واضحة للمستخدم. واجهة الصلاحيات مش تفصيلة UI — دي طبقة الأمان اللي المستخدم بيشوف بيها الـ Agent بيعمل إيه. اعرض الأداة، الـ Server، والمدخلات — قبل التنفيذ.

<!-- Field 13: Code example (D-4 provider-agnostic, CR-4 Arabic surround) -->

الكود

الكود ده مش من SDK معيّن — دي الفكرة عريانة: إزاي Host بسيط بيوصّل Clients متعددة، بيجمّع أدواتهم، وبيوجّه طلب الموديل للـ Client الصح. اقراه كسودوكود:

# ---------- 1) الـ Host بيعمل Client لكل Server ويكتشف أدواته ----------
servers = {
    "docs":     connect_client("docs-server"),      # Client ← Server (1:1)
    "jira":     connect_client("jira-server"),
    "calendar": connect_client("calendar-server"),
}

tool_registry = {}                                   # المنيو المجمّع
for name, client in servers.items():
    for tool in client.discover_tools():             # Discovery
        key = f"{name}.{tool.name}"                   # Namespacing يمنع التعارض
        tool_registry[key] = (client, tool)          # افتكر الأداة دي من أنهي Client

# ---------- 2) قدّم المنيو المجمّع للموديل ----------
tools_for_model = [t.schema for (_, t) in tool_registry.values()]

# ---------- 3) الحلقة: الموديل يطلب، الـ Host يوجّه ----------
while True:
    step = llm.step(conversation, tools=tools_for_model)   # Agent loop

    if step.is_final_answer:
        return step.text

    # الموديل طلب أداة — وجّهها للـ Client الصح (Routing)
    client, tool = tool_registry[step.tool_call.name]

    if tool.is_sensitive:                            # واجهة الصلاحيات
        if not ask_user_approval(step.tool_call):
            conversation.add_tool_result("rejected by user")
            continue

    result = client.call(tool.name, step.tool_call.args)   # Client ← Server
    conversation.add_tool_result(result)             # النتيجة ترجع للموديل

لاحظ تلات حاجات قبل ما تكمّل:

• الـ Host هو اللي بيمسك الـ `tool_registry`. ده قلب التجميع والتوجيه: كل أداة عارف هي من أنهي Client. من غير الخريطة دي، الموديل يطلب أداة والـ Host مش عارف يبعتها فين.
• الـ Namespacing (`docs.search`) مش رفاهية. من غيره، تعارض الأسماء بيكسر التوجيه بصمت.
• الـ Clients مش ظاهرين للموديل خالص. الموديل بيشوف أسماء أدوات بس. إدارة الاتصالات والتوجيه كلها شغل الـ Host الداخلي.

<!-- Field 14: Common mistakes -->

تمرين (25 دقيقة): على ورق، صمّم Host بسيط لـ 3 Servers متخيّلة (Docs، Database، Email). ارسم: (1) إزاي هتعمل Discovery وتجمّع الأدوات، (2) إزاي هتحلّ تعارض لو Server-ين عندهم أداة search، (3) لما الموديل يطلب send_email، إزاي هيعرف الـ Host يوجّهه للـ Client الصح، و(4) فين بالظبط هتحطّ الموافقة البشرية. بعدين اسأل نفسك: لو Server الـ Email وقع، إيه اللي بيحصل للمنيو المقدّم للموديل؟ لو مجاوبتش بثقة، ارجع لقسم دورة الاتصال.

<!-- Field 27: Interview questions -->

⚠️ خد بالك: الغلطة #1 هي الأشهر على الإطلاق — الناس بتسمع «Client» و«Host» وتفتكرهم مترادفين. لأ. تطبيق واحد (Host) جوّاه Clients كتير.

<!-- Field 15: Common misconceptions -->

مفاهيم غلط منتشرة

1) «الـ MCP ده Plugins للـ Claude بس» — ❌ لأ. الـ MCP معيار مفتوح (Open Standard)، أي Host يقدر ينفّذه: IDE، تطبيق شات، منصة Agents، أداة داخلية. حقيقة إنه ظهر في سياق مساعد معيّن مبيخلّيهوش حصري ليه. أنت تقدر تبني Host بتاعك بالكامل يستهلك أي MCP Server.

2) «الـ Client والـ Host نفس الحاجة» — ❌ دي أكتر خلطة منتشرة. الـ Client بيتكلم مع Server واحد وبس — رقيق وبسيط. الـ Host هو التطبيق اللي بيحتوي Clients متعددة ويديرهم. علاقة الاحتواء دي هي المفتاح: Host واحد ← Clients كتير ← كل Client لـ Server واحد.

3) «لو بستخدم MCP يبقى لازم أبني Host» — ❌ لأ. لو أنت بس عايز تستهلك أدوات جوّه تطبيق موجود، تقدر تستخدم Host جاهز. بتبني Host بنفسك لما بتبني منتج محتاج يدير الأدوات بطريقتك (منصة Agents، IDE، Copilot). فرّق بين «مستهلِك لأدوات» و«باني لمنصة».

4) «الـ Sampling يعني الـ Server عنده موديل خاص بيه» — ❌ بالعكس. الـ Sampling موجود عشان الـ Server مش عنده موديل — فبيطلب من الـ Host إنه يسأل الـ LLM نيابةً عنه. الموديل والفاتورة بتوع الـ Host، مش الـ Server. عشان كده الحوكمة مهمة.

<!-- Field 16: When to use it (Layer 7a) -->

🔒 أمان

الـ Host هو نقطة فرض الأمان كلها — لأنه ماسك الصلاحيات والموافقات والتوجيه. تلات نقط لازم تكون واعي ليها:

1) الـ Host هو حارس الموافقات. أي Approval Gate على فعل حساس بيتنفّذ في طبقة الـ Host، مش الـ Server ولا الموديل. لو الـ Host مش بيعرض الأدوات الحساسة للمستخدم قبل التنفيذ، مفيش حماية. (تفاصيل التهديدات كاملة في مفهوم أمان الـ MCP.)

2) Sampling قناة استهلاك لازم تحكمها. لما تسمح للـ Servers تطلب Sampling، أنت بتدّي كود طرف تالت طريقة يستهلك بيها موديلك وفلوسك. الـ Host لازم يفضل صاحب القرار: سقف، مراجعة، موافقة. متمرّرش طلبات Sampling أعمى.

3) Roots سياج نطاق الرؤية. استخدم الـ Roots لتحصر إيه اللي كل Server يقدر يشوفه — زي مجلد مشروع بدل الجهاز كله. الـ Host اللي مش بيحدّد Roots بيدّي الـ Servers رؤية أوسع من اللازم.

<!-- Field 21: Cost considerations -->

💸 التكلفة

فين الفلوس بتروح في تصميم الـ Host؟ حتّتين أساسيتين، والاتنين تحت سيطرتك:

• حجم منيو الأدوات = Tokens ثابتة في كل طلب. كل وصف أداة بيتحطّ في Context الموديل مع كل استدعاء. لو عندك 40 أداة، والوصف متوسّطه 60 Token، ده 2,400 Token زيادة في كل طلب — قبل ما المستخدم يكتب حرف. على 100k طلب شهريًا، الفرق بين تقديم 40 أداة و10 أدوات مصفّاة ممكن يكون فرق ملموس في الفاتورة. صفِّي الأدوات حسب السياق.
• Sampling من الـ Servers = استهلاك مش متوقّع. Server بيطلب Sampling في Loop ممكن يضاعف استدعاءات الموديل من ورا ظهرك. حطّ سقف وراقب.

> 💸 ملحوظة: الأرقام توضيحية لإطار التفكير (Volatile fragment — راجع أسعار مزوّدك). الفكرة الثابتة: الـ Host بيتحكم في كمية الـ Context المقدّمة للموديل — وده أكبر مقبض تكلفة في إيدك.

<!-- Field 22: Performance considerations -->

الأداء

• Discovery متوازي أسرع. اكتشاف أدوات 10 Servers بالتسلسل بطيء عند التشغيل — اعمله بالتوازي.
• Server بطيء بيأخّر الحلقة كلها. حطّ Timeout لكل Client، وخلّي Server المتأخّر يفشل بأدب بدل ما يعلّق الطلب.
• تصفية الأدوات بتحسّن الأداء والجودة مع بعض. منيو أصغر = Context أقصر = استجابة أسرع + قرار أدق. مكسب مزدوج نادر.

<!-- Field 23: Related concepts -->

• بتبني منصة Agents: المستخدمين بيوصّلوا أدواتهم، وأنت محتاج تدير التوصيل والتجميع والتوجيه — ده Host بامتياز.
• بتبني منتج زي IDE أو محرّر: عايز الموديل جوّه أداتك يوصل لأدوات وسياق متغيّر (ملفات، Terminal، Extensions) — محتاج Host يدير ده.
• بتبني Copilot داخلي لشركة: موصّل بأنظمة داخلية متعددة (Wiki، Jira، Database)، وعايز تجربة موحّدة وتحكم مركزي في الصلاحيات — Host.
• عايز تحكم دقيق في التجميع والتوجيه والموافقات: لو محتاج تتحكم في أنهي أدوات تظهر، إمتى، ومين يوافق — تبني الطبقة دي بنفسك.

<!-- Field 17: When NOT to use it (Layer 7b) -->

• بتستخدم تطبيق جاهز فيه Host شغّال: لو أداتك بتدير الأدوات كويس أصلًا، متعملش Host من الصفر — ده شغل تحتية كبير.
• محتاج أداة واحدة معروفة بس: توصيل مباشر (Direct Tool) أبسط من بناء بنية Host كاملة لأداة واحدة.
• الفريق صغير والمنتج لسه بيثبت فكرته: بناء Host متين (إدارة اتصالات، تجميع، حوكمة Sampling) شغل حقيقي — أجّله لحد ما تحتاجه فعلًا.
• مش هتدير Servers متعددة: فايدة الـ Host المعمارية بتظهر مع التعدد. Server واحد؟ العائد قليل مقابل التعقيد.

💡 نصيحة: القاعدة العملية: بتبني منتج بيدير أدوات لناس تانية → Host. بتوصّل أدواتك لنفسك في تطبيق موجود → استهلك. لو لقيت نفسك بتكتب منطق تجميع وتوجيه، أنت في أرض الـ Host.

<!-- Field 18: Alternatives -->

البدايل

البدايل مش أعداء: أنظمة كتير بتبني Host فوق Framework جاهز، وبتضيف بعض Direct Tools جنب الـ MCP Servers.

<!-- Field 19: Trade-offs -->

الموازنات

القاعدة: التحكم مقابل السرعة. بتبني Host لما التحكم في إدارة الأدوات هو جوهر منتجك. بتستهلك لما الأدوات وسيلة مش منتج.

<!-- Field 20: Security considerations -->