Why Everyone Is Switching to MCP (And Why You Might Not Need To)

Watch on YouTube

Now Playing

Transcript

490 segments

0:00

لديك بالفعل واجهات

0:01

برمجة تطبيقات REST،

0:02

ويمكن لـ Claude Code

0:03

استدعاؤها بالفعل.

0:04

إذًا، لماذا يقوم

0:05

الجميع فجأة ببناء

0:07

خوادم MCP؟ هل يحل MCP

0:08

مشكلة جديدة حقًا، أم

0:10

أننا نضيف طبقة أخرى

0:11

أمام واجهات برمجة

0:12

تطبيقات تعمل بالفعل؟

0:14

لذا، في هذا الفيديو،

0:15

سنقوم أولاً ببناء

0:16

خدمة طلبات صغيرة

0:17

باستخدام REST API عادي،

0:19

ثم سنحضر وكيل برمجة

0:20

يعمل بالذكاء

0:21

الاصطناعي ونطلب منه

0:22

التعامل مع تلك الخدمة

0:23

. قد يكون هذا Claude Code أو

0:25

Cursor أو Codex أو أي وكيل

0:27

برمجة آخر. بالنسبة

0:28

لهذا المثال، سنستخدم

0:30

Claude Code وسنعطيه مهمة

0:31

بسيطة. اعثر على كل طلب

0:33

ظل غير مشحون لأكثر من

0:35

7 أيام. دعونا نرى إلى

0:37

أي مدى يمكننا الوصول

0:38

بدون MCP. دعونا نبدأ.

0:45

حسنًا، خدمة الطلبات

0:46

الخاصة بنا بسيطة

0:48

للغاية. لدينا get orders

0:49

لسرد الطلبات، و get orders

0:51

ID لجلب طلب واحد، و patch

0:53

orders ID لتحديث طلب واحد.

0:56

الآن، هناك بالطريقة

0:57

الواضحة طرق عديدة

0:58

لبناء REST API كهذا.

1:00

شخصياً، استخدمت في

1:01

الغالب Spring Boot لبناء

1:02

واجهات برمجة تطبيقات

1:03

REST. ولكن، إذا كنت تعمل

1:05

بلغة Python، فقد تلجأ

1:06

إلى Fast API. في TypeScript أو

1:08

JavaScript، لديك خيارات

1:10

مثل Express أو Fastify أو NestJS

1:12

. وفي .NET، قد تستخدم

1:14

ASP.NET Core. لهذا العرض

1:16

التوضيحي، سأستخدم

1:17

TypeScript مع Express. ليس لأن

1:19

Express هو الخيار الأفضل

1:21

بأي حال، ولكن لأننا

1:22

نستطيع إبقاء الكود

1:23

صغيرًا جدًا والتركيز

1:25

على ما يحدث معماريًا.

1:26

إذًا، قد يستدعي

1:27

وكيلنا في النهاية

1:29

شيئًا كهذا. Get orders،

1:31

الحالة غير مشحون،

1:33

وقبل 18 أغسطس 2026. وتقوم

1:35

الخدمة ببساطة بإرجاع

1:37

الطلبات المطابقة

1:38

بصيغة JSON. لا شيء خاص

1:39

بالذكاء الاصطناعي

1:41

هنا. إنها مجرد REST API

1:43

عادية. الآن، لنحضر

1:44

Claude Code. هل يستطيع Claude

1:46

استدعاء واجهة برمجة

1:47

التطبيقات هذه مباشرة

1:48

؟ بالتأكيد. يتمتع Claude

1:50

Code بإمكانية الوصول

1:51

إلى Terminal. لذا، يمكننا

1:52

تزويده بوثائق واجهة

1:53

برمجة التطبيقات

1:54

الخاصة بنا وتركه

1:55

يستخدم الكود. إذا كان

1:56

لواجهة برمجة

1:57

التطبيقات الخاصة بنا

1:58

مواصفات Open API،

1:59

فيمكننا تزويده بها

2:00

أيضًا. أو إذا كنت تبني

2:01

وكيلك الخاص، فيمكننا

2:03

كتابة دالة عادية

2:04

تستدعي نقطة النهاية

2:05

هذه وعرض تلك الدالة

2:07

على النموذج. إذًا،

2:08

نطلب من Claude العثور

2:10

على كل طلب لم يتم شحنه

2:11

لأكثر من 7 أيام. إنه

2:13

يفهم واجهة برمجة

2:14

التطبيقات، ويستدعي get

2:16

orders، ويمرر المرشحات

2:18

الصحيحة، ويستعيد

2:19

الطلبات المعلقة. وهو

2:21

يعمل حتى الآن. لم يحل

2:23

MCP أي شيء على الإطلاق

2:24

هنا. لكن مهمتنا

2:26

الفعلية أكثر إثارة

2:27

للاهتمام قليلاً. نحن

2:29

لا نريد فقط العثور

2:30

على تلك الطلبات. لكل

2:31

طلب معلق، نريد أيضاً

2:33

إنشاء إصدار على GitHub

2:34

ليتمكن شخص ما من

2:35

التحقيق فيه. حسناً.

2:37

يمتلك GitHub بالفعل

2:38

واجهة برمجة تطبيقات

2:39

REST. لذا، من الناحية

2:41

الفنية، يمكن لـ Claude

2:42

تعلم تلك الواجهة

2:43

أيضاً. فهو يحدد نقطة

2:44

النهاية التي تنشئ

2:45

الإصدار، ويرسل

2:46

المستودع، والعنوان،

2:47

والمحتوى. وهذا يعمل

2:49

أيضاً. إذاً، الآن

2:50

يتحدث Claude مباشرة مع

2:52

واجهتي برمجة تطبيقات.

2:54

واجهة طلباتنا وواجهة

2:56

GitHub. لا يزال بدون MCP.

2:58

وبصراحة، بالنسبة

2:59

لواجهتي برمجة

3:00

تطبيقات، قد يكون هذا

3:02

جيداً تماماً. لكن

3:03

تخيل الآن أن هذا

3:04

الوكيل ينمو. غداً، قد

3:05

يحتاج لإرسال شيء إلى

3:07

Slack، أو إنشاء تذكرة في

3:09

Jira، أو الاستعلام عن

3:10

PostgreSQL، أو التحقق من

3:11

شيء في Datadog. الآن، كل

3:13

نظام لديه نقاط نهاية

3:15

خاصة به، ومخططات،

3:16

ومصادقة، وترقيم

3:18

صفحات، وأخطاء،

3:19

وتوثيق. وهناك مشكلة

3:21

أخرى. ماذا يحدث عندما

3:23

تحتاج هذه الإمكانات

3:24

نفسها للعمل ليس فقط

3:26

من كود Claude، بل أيضاً

3:27

من Cursor، و Codex، ووكيل

3:29

داخلي، وأي شيء يبنيه

3:31

فريقك لاحقاً؟ الآن،

3:32

تبدأ مشكلة التكامل في

3:34

الظهور بشكل مختلف.

3:35

وهذه هي المشكلة التي

3:37

تحاول MCP توحيدها. MCP

3:38

تعني بروتوكول سياق

3:40

النموذج (Model Context Protocol)

3:42

. بدلاً من أن يتعلم كل

3:43

عميل ذكاء اصطناعي

3:44

طريقة مخصصة للتفاعل

3:46

مع كل نظام، تمنح MCP

3:47

تطبيقات الذكاء

3:48

الاصطناعي بروتوكولاً

3:49

مشتركاً لاكتشاف

3:50

الإمكانات واستخدامها

3:52

. يمكن لخادم MCP عرض

3:53

أدوات، وموارد،

3:55

ومطالبات. بالنسبة

3:57

لمثالنا، نحن نهتم

3:58

بشكل أساسي بالأدوات.

3:59

لذا، بدلاً من جعل Claude

4:01

يفكر في جلب الطلبات،

4:02

ومعايير الاستعلام،

4:04

وترقيم الصفحات،

4:05

وتنسيق الاستجابة،

4:06

يمكننا عرض شيء أكثر

4:07

أهمية بكثير. العثور

4:09

على طلبات البيع.

4:10

ويمكن أن يكون مدخله

4:12

ببساطة: "أقدم من سبعة

4:13

أيام". الأداة لها اسم،

4:16

ووصف، ومخطط إدخال

4:17

منظم. وكود Claude يفهم

4:19

بالفعل كيفية التعامل

4:21

مع أدوات MCP. الآن،

4:22

لدينا عقد مشترك بين

4:24

عميل الذكاء

4:24

الاصطناعي والإمكانية

4:26

التي يريد استخدامها.

4:27

إذاً، لنقم ببناء خادم

4:29

MCP واحد لخدمة الطلبات

4:30

الخاصة بنا. ومثلما لا

4:32

تقوم عادةً بتنفيذ HTTP

4:34

من الصفر عند بناء

4:35

واجهة REST، فأنت لا

4:37

تنفذ بروتوكول MCP

4:38

بأكمله بنفسك أيضاً.

4:39

هناك حزم تطوير برمجية

4:41

(SDKs) رسمية لـ MCP بلغات

4:43

مثل TypeScript و Python و Go و C#

4:45

و Java وغيرها. وبما أن

4:47

مثالنا مكتوب بالفعل

4:48

بلغة TypeScript، فسأستخدم

4:50

حزمة تطوير MCP الرسمية

4:51

لـ TypeScript. إذاً، الآن

4:53

لدينا Express لواجهة REST

4:55

الخاصة بنا وحزمة MCP SDK

4:56

لـ TypeScript لخادم MCP

4:58

الخاص بنا. داخل خادم

4:59

MCP ذلك، نعرض أداة

5:01

العثور على الطلبات

5:02

المعلقة. لكن، إليك

5:03

الجزء المهم. عندما

5:05

يستدعي Claude تلك الأداة

5:06

، ماذا يحدث في

5:07

الخلفية؟ خادم MCP

5:08

الخاص بنا يستدعي

5:09

ببساطة نفس نقطة نهاية

5:11

جلب الطلبات التي

5:12

بنيناها سابقاً. لم

5:13

نتخلص من واجهة REST. لم

5:15

نقم بإعادة بناء خدمة

5:16

الطلبات. وخدمة

5:18

الطلبات نفسها لا تعلم

5:19

حتى بوجود Cloud Code. لا

5:21

تزال خدمة خلفية عادية

5:23

. إذًا، انظر الآن إلى

5:25

البنية. قد تستدعي

5:26

واجهتك الأمامية

5:27

وظيفة الحصول على

5:28

الطلبات. قد تستدعيها

5:29

خدمة مصغرة أخرى. وقد

5:31

يستدعيها تطبيق

5:32

الهاتف، لكن Cloud Code

5:33

يمكنه رؤية شيء أكثر

5:35

أهمية. العثور على

5:36

الطلبات القديمة. تظل

5:38

واجهة برمجة تطبيقات

5:39

REST هي الواجهة

5:40

لتطبيقنا. يقوم خادم MCP

5:42

بعرض قدرات مختارة من

5:43

ذلك التطبيق بشكل

5:44

تفهمه عملاء الذكاء

5:46

الاصطناعي المتوافقون

5:47

. إذًا، يمكنك التفكير

5:49

في هذا كخدمة واحدة،

5:50

بواجهتين لنوعين

5:52

مختلفين من

5:52

المستهلكين. ويصبح هذا

5:54

التمييز أكثر وضوحًا

5:56

عندما نعود إلى GitHub.

5:57

لأننا هذه المرة، لا

5:59

نبني تكامل GitHub

6:00

بأنفسنا. لدى GitHub

6:02

بالفعل خادم MCP. لذا،

6:03

يمكن لـ Cloud Code الآن

6:05

رؤية أدوات قادمة من

6:06

نظامين مختلفين

6:07

تمامًا. قد يكشف خادم

6:08

MCP الخاص بطلباتنا عن

6:09

أداة العثور على

6:10

الطلبات القديمة.

6:11

ويكشف خادم MCP الخاص بـ

6:13

GitHub عن أدوات لأشياء

6:14

مثل إنشاء المشكلات.

6:16

الآن، أعطِ Cloud المهمة

6:17

الأصلية. اعثر على كل

6:19

طلب لم تتم مشاركته

6:21

لأكثر من 7 أيام وأنشئ

6:22

مشكلة على GitHub لكل

6:23

منها. يكتشف Cloud أدوات

6:25

الطلبات المناسبة،

6:26

ويستدعيها، ويحصل على

6:28

الطلبات القديمة، ثم

6:30

يجد أداة GitHub المناسبة

6:31

، وينشئ المشكلات. في

6:33

العمق، هذه الأنظمة

6:34

مختلفة تمامًا. أداتنا

6:36

تستدعي في النهاية

6:37

واجهة برمجة تطبيقات

6:38

Express REST الخاصة بنا.

6:39

تعمل أداة GitHub في

6:40

النهاية مع واجهة

6:41

برمجة تطبيقات GitHub.

6:43

لكن Claude يتفاعل مع

6:44

كليهما من خلال نفس

6:45

البروتوكول، وهنا

6:46

يبدأ MCP في أن يصبح

6:47

مفيدًا. إليك مهمة

6:49

مكتوبة بالطريقة

6:50

العادية. اقرأ طلب سحب

6:52

من GitHub، ثم انشره على

6:53

قناة Slack. خدمتان

6:54

تعنيان مجموعتي أدوات

6:56

تطوير (SDK). لكل واحدة

6:58

عميل خاص بها، ونوع

6:59

رمز خاص بها، وشكل

7:00

طريقة خاص بها. نداء

7:02

GitHub ونداء Slack لا

7:03

يشتركان في أي شيء سوى

7:05

وجودهما في نفس الملف.

7:06

وانظر إلى ما يحدد

7:08

هوية المستدعي. إنه

7:09

الرمز المميز. يرى GitHub

7:11

رمز وصول شخصي. ويرى

7:13

Slack رمز بوت، ولا يعرف

7:15

أي منهما من الذي طلب

7:17

هذا. الآن نفس المهمة

7:19

من خلال MCP. يمر كلا

7:20

النداءين عبر جلسة

7:22

واحدة. أنت تسمي

7:23

الأداة، وتمرر

7:24

قاموسًا من الوسائط،

7:25

وهذا هو النداء

7:26

بالكامل. أصبح نداء

7:28

GitHub ونداء Slack الآن

7:29

لهما نفس الشكل. وهذا

7:31

ما يوحّده معيار MCP.

7:33

أنت لا تتعلم مجموعة

7:34

أدوات تطوير جديدة لكل

7:36

خدمة تضيفها. هناك

7:37

واجهة واحدة. والجزء

7:39

الخاص بالخدمة يعيش في

7:40

تعريف الأداة على

7:41

الخادم. لكن انظر إلى

7:43

ما لا يزال مفقودًا. لا

7:44

شيء في أي من هذين

7:46

النداءين يقول من الذي

7:47

يسأل. يحتفظ خادم MCP

7:49

ببيانات الاعتماد. أي

7:50

شخص يتصل به يعمل

7:52

باستخدام تلك

7:53

البيانات. على حاسوبك

7:54

المحمول، هذا جيد لأنه

7:56

يوجد مستخدم واحد وهو

7:58

أنت. ضع الأمر أمام

7:59

فريق عمل وستعود إلى

8:01

مشكلة REST. مجموعة رموز

8:03

واحدة ولا توجد طريقة

8:04

لمعرفة صاحب هذا

8:06

الإجراء. وحد بروتوكول

8:08

MCP شكل الاستدعاء. لكنه

8:09

لم يوحد من المسموح له

8:11

بإجرائه. هذه الفجوة

8:13

هي ما تعمل Arcade على سده

8:14

، وهم رعاة هذا

8:15

الفيديو. Arcade هو بيئة

8:17

التشغيل الخاصة بـ MCP.

8:18

وهذه هي المهمة نفسها

8:20

للمرة الثالثة، تعمل

8:21

من خلال Arcade. وهذا هو

8:22

النصف الخاص بـ GitHub.

8:24

وهذا النصف الخاص بـ

8:25

Slack. نفس شكل استدعاء MCP

8:27

العادي مع إضافة وسيط

8:28

واحد، وهو معرف

8:29

المستخدم. يقوم كل شخص

8:31

بربط حساباته الخاصة

8:32

مرة واحدة. عندما يطلب

8:34

الوكيل تنفيذ إجراء ما

8:35

، يتحقق Arcade مما إذا

8:36

كان ذلك الشخص قد سمح

8:37

باستخدام تلك الأداة.

8:38

ينفذ الإجراء بصلاحية

8:39

الوصول الخاصة به

8:40

ويعيد النتيجة. لا

8:41

توجد رموز مشتركة

8:42

موجودة في أي مكان في

8:44

الكود الخاص بك.

8:45

بالتراجع للوراء، هذا

8:46

هو الشكل. يقوم كل شخص

8:48

بتفويض حساباته

8:49

الخاصة مرة واحدة. لا

8:50

يحتفظ خادم MCP بأي

8:52

أسرار. يقوم Arcade، وهو

8:54

بيئة تشغيل الإجراءات

8:55

حيث يعمل خادم MCP،

8:56

بالتحقق من الأذونات

8:58

ويتولى المصادقة

8:59

والتفويض. إذا منح

9:00

المستخدم موافقته،

9:02

سيقوم Arcade بحقن الرمز

9:03

في كود خادم MCP وقت

9:05

التشغيل. تعمل الأداة

9:06

وتعود النتيجة إلى

9:08

المستدعي. يمر كل

9:09

استدعاء عبر طبقة

9:10

واحدة، لذا فإن لكل

9:11

إجراء مالك وسجل يمكنك

9:13

قراءته لاحقاً.

9:14

النموذج الذي يمكنه

9:16

التفكير فقط ليس

9:17

وكيلاً. Arcade هو الجزء

9:18

الذي يسمح له بالتصرف.

9:20

الرابط موجود في الوصف

9:21

. الآن، هذا يثير

9:23

سؤالاً آخر. إذا كان

9:24

بإمكان الوكيل

9:25

استخدام MCP، هل يجب

9:26

علينا استبدال جميع

9:28

واجهات برمجة

9:28

التطبيقات بخوادم MCP؟

9:30

لا. MCP لا يستبدل REST.

9:33

ولا يستبدل gRPC. ولا

9:35

يستبدل نظامك الخلفي.

9:37

ولا يزيل سحرياً

9:38

المصادقة، أو التفويض

9:39

، أو التحقق، أو تحديد

9:40

المعدل، أو المحاولات

9:41

المتكررة، أو تصميم

9:42

الخدمة الجيد. يمكن

9:44

لواجهتك الأمامية

9:44

الاستمرار في استخدام

9:46

REST ويجب عليها ذلك.

9:47

يمكن لتطبيق الهاتف

9:47

المحمول الخاص بك

9:48

الاستمرار في استخدام

9:49

REST. يمكن للخدمات

9:50

المصغرة الخاصة بك

9:51

الاستمرار في استخدام

9:52

REST أو gRPC. ويمكن لخادم

9:53

MCP الخاص بك كشف قدرات

9:55

مختارة لتطبيقات

9:56

الذكاء الاصطناعي. في

9:57

الواقع، قد تقوم أداة

9:58

MCP شائعة ببساطة

9:59

باستدعاء واجهة برمجة

10:00

تطبيقات إنتاجية

10:01

موجودة في الخلفية.

10:02

لذا، MCP وواجهات برمجة

10:04

التطبيقات ليسا

10:05

منافسين حقاً. إنهما

10:06

يعملان في حدود مختلفة

10:08

. وهنا يصبح القرار

10:09

بسيطاً للغاية. لنفترض

10:11

أن لديك وكيلاً واحداً

10:13

يستدعي وظيفتين

10:14

داخليتين تتحكم فيهما

10:15

بالكامل، فربما لا

10:16

تحتاج إلى خادم MCP. قد

10:18

يكون استدعاء الوظيفة

10:19

المباشر أبسط. أو قد

10:20

يكون منح الوكيل

10:21

صلاحية الوصول إلى

10:22

واجهة برمجة تطبيقات

10:24

موجودة كافياً. لكن

10:25

تخيل الآن أن لديك

10:26

عشرات الأدوات،

10:27

وفرقًا مختلفة تمتلك

10:28

تلك الأدوات،

10:29

والتكاملات تتطور

10:30

بشكل مستقل، وتحتاج

10:31

تلك القدرات نفسها إلى

10:33

العمل من Cloud Code و Cursor و

10:34

Codex وجميع الوكلاء

10:35

الداخليين. هنا تصبح

10:37

الحاجة إلى واجهة

10:38

قياسية أكثر قيمة

10:39

بكثير. يصف كل خادم MCP

10:41

ما يمكنه فعله، وتفهم

10:43

العملاء المتوافقة

10:44

كيفية اكتشاف تلك

10:46

القدرات، ولم تعد

10:47

مضطراً لتصميم تكامل

10:48

مختلف تماماً لكل عميل

10:50

ولكل أداة. وهذا هو

10:52

المقابل. لذا، لا تزال

10:53

واجهة برمجة

10:54

التطبيقات (API) الخاصة

10:55

بك تقوم بعمل التطبيق

10:56

الفعلي. خادم MCP ليس

10:57

موجوداً لاستبدالها.

10:59

واجهة برمجة

10:59

التطبيقات (API) الخاصة

11:01

بك هي الباب. يعمل MCP

11:02

على توحيد المقبض الذي

11:03

تستخدمه عملاء الذكاء

11:04

الاصطناعي المتوافقة

11:05

لفتحه. يا رفاق، لا

11:06

أريد أن يظل هذا مجرد

11:08

مخطط معماري آخر. لذا،

11:09

قمت بتجهيز نفس المثال

11:10

الذي استخدمناه في هذا

11:12

الفيديو. ستحصل على

11:13

خدمة طلبات Express REST

11:14

العادية. وستحصل أيضاً

11:16

على خادم MCP الذي يعمل

11:17

فوقها. متصلاً بـ Cloud

11:19

Code أو Cursor. جرب واجهة

11:21

برمجة التطبيقات (API)

11:22

مباشرة أولاً. ثم قم

11:23

بتفعيل خادم MCP وشغل

11:24

نفس سير العمل مرة

11:26

أخرى. بمجرد رؤية كلا

11:27

النهجين يعملان على

11:29

نفس الخدمة تماماً،

11:30

يصبح الفرق بين API و MCP

11:32

أسهل بكثير في الفهم.

Interactive Summary

Ask follow-up questions or revisit key timestamps.

يشرح هذا الفيديو مفهوم بروتوكول سياق النموذج (Model Context Protocol - MCP) وكيفية تكامله مع واجهات برمجة التطبيقات (REST API) التقليدية. يوضح الفيديو من خلال مثال عملي بناء خدمة طلبات بسيطة، وكيف يمكن للوكلاء الأذكياء مثل Claude Code التعامل مع هذه الخدمات مباشرة أو عبر خوادم MCP. يركز الفيديو على أن MCP لا يستبدل واجهات REST، بل يعمل كطبقة توحيد تتيح للوكلاء اكتشاف واستخدام الإمكانات عبر أنظمة مختلفة بشكل موحد. كما يتطرق إلى دور بيئات التشغيل مثل Arcade في إدارة الأذونات والمصادقة، مما يسهل العمل التعاوني للفرق.