MCP — Model Context Protocol — يُتيح لوكلاء AI إجراء استدعاءات أدوات مباشرة لخدمات خارجية أثناء التشغيل. تُصدر Figma خادم MCP رسمياً، كما بنى المجتمع عدداً من الخوادم الإضافية. الفكرة الأساسية: يمكن لوكيلك أن يطلب بيانات التصميم من Figma مباشرة، عند الطلب، في منتصف المحادثة. لا حاجة لخطوة تصدير. الاتصال دائماً حي.

يتخذ figmascope الرهان المعماري المعاكس تماماً: صدّر مرة واحدة، ابعث حزمة، لا تتصل مجدداً. هذان خياران مختلفان حقاً بتداعيات مختلفة. إليك ما يكلفه كل منهما وما يكسبه.

ما هو خادم MCP في Figma

Model Context Protocol هو المعيار المفتوح من Anthropic للربط بين وكلاء AI والأدوات الخارجية عبر واجهة خادم. يكشف خادم MCP عن أدوات مكتوبة يمكن للوكيل استدعاؤها: "get_file" و"get_node" و"get_styles" وغيرها. عندما يحتاج الوكيل إلى سياق التصميم، يستدعي الأداة، فيستدعي خادم MCP واجهة برمجة Figma، ويعود الناتج كسياق للمطالبة الحالية.

يشمل خادم MCP الرسمي من Figma قراءة الملفات وفحص العقد واسترداد المكونات والوصول إلى التعليقات. خوادم MCP المجتمعية (يوجد عدة منها على GitHub) توسّع هذا بمخططات مخصصة وتحويلات إضافية أو نطاقات أضيق مُحسَّنة لسير عمل وكلاء محددة.

لاستخدام أي خادم Figma MCP، تُهيئه في عميل الوكيل (Claude Desktop أو Cursor أو Continue وغيرها)، توفر PAT لـ Figma، ويعمل الخادم كعملية محلية. عندما يحتاج وكيلك إلى سياق Figma، يستدعي الأداة. لا تصدّر شيئاً صراحةً — الوكيل يجلب ما يحتاجه عند الحاجة.

نموذج MCP في التطبيق العملي

سير عمل Figma المدعوم بـ MCP يبدو هكذا عادةً: تفتح Cursor، تبدأ محادثة، تقول "نفّذ شاشة الدفع من ملف Figma هذا"، فيستدعي الوكيل get_file، يسحب شجرة العقد، ويحتوي بيانات التصميم في السياق. إذا قلت بعدها "حدّث المصمم رموز الزر"، يمكن للوكيل الاستدعاء مجدداً والحصول على بيانات منعشة.

نموذج الاتصال الحي هذا حقيقي ومقنع لسير عمل بعينها. الوكيل يعمل مع بيانات حالية. لا تدير نتائج التصدير. لا توجد خطوة يدوية بين "دفع المصمم تغييراً" و"امتلاك الوكيل له".

أين يتفوق MCP

بيانات حية، بلا خطوة تصدير. يجلب الوكيل الحالة الراهنة عند الطلب. إذا تغيّر التصميم قبل عشر دقائق، يمكن للوكيل رؤيته. يتطلب figmascope إعادة تصدير يدوية لالتقاط التغييرات.

استكشاف تصميم تحادثي. "ما لون زر CTA؟" "كم شاشة تستخدم هذا المكوّن؟" مع MCP، يمكن للوكيل الإجابة باستدعاء Figma. مع الحزمة، الإجابة بحداثة آخر تصدير فقط.

التعديل المباشر على Figma. بعض خوادم MCP تكشف عمليات كتابة — إنشاء عقد وتحديث خصائص ونشر تعليقات. هذا متاح فقط مع الاتصال الحي. الحزمة الثابتة لا تمتلك مسار كتابة.

لا سير عمل يدوي. للمطورين المستخدمين فعلاً لإعدادات وكلاء متصلة بـ MCP، عدم وجود خطوة تصدير يعني شيئاً أقل لنسيانه. إدارة السياق مُفوَّضة للوكيل.

أين يخسر MCP

نموذج الاتصال الحي له تكاليف معمارية يسهل الاستهانة بها.

حالة مرتبطة بالجلسة. استدعاءات MCP تحدث في سياق جلسة محادثة. البيانات التي جلبها الوكيل في الجلسة A غير متاحة في الجلسة B دون إعادة الجلب. إذا بدأت محادثة جديدة، يبدأ الوكيل من الصفر. حزمة figmascope تستمر بين الجلسات وبين المطورين وبين الأدوات — هي مجرد ملفات.

غير مرئية لـ git. لا توجد نتيجة تصدير. لا شيء للالتزام به. سياق التصميم الذي أثّر في كودك لا يعيش في المستودع. بعد ستة أشهر، إذا أردت فهم شكل التصميم عند بناء مكوّن، لا يوجد سجل. مع حزمة في المستودع، لديك تاريخ التزامات لنية التصميم.

يتطلب اتصالاً. يحتاج MCP خادماً قيد التشغيل واتصالاً حياً بـ Figma API و PAT ذا وصول. الشبكة معطلة، Figma API معطل، PAT منتهي الصلاحية — لا يملك الوكيل سياقاً. الحزمة تعمل على متن طائرة.

استرداد يعتمد على النموذج. ما يطلبه الوكيل عبر MCP يعتمد على ما يقرر طلبه. قد لا يجلب قيم الرموز. قد لا يسحب مخزون المكونات. قد يطلب فقط الفرع الفرعي للعقد الذي يظن أنه يحتاجه، مُفوِّتاً السياق المكاني من العقد المجاورة. الاسترداد احتمالي لا حتمي. figmascope يجلب كل شيء في كل مرة، وفق مخطط ثابت.

أصعب في الاختبار وإعادة الإنتاج. "وكيلي بنى هذا المكوّن من بيانات Figma هذه في هذه اللحظة" لا يمكن التحقق منه مع MCP. الجلب مؤقت. مع حزمة، يمكنك الإعادة بدقة: نفس الحزمة، نفس الوكيل، نفس المطالبة — ناتج حتمي. هذا مهم للتنقيح ومراجعة الكود والمساءلة عند الإصدار.

ضغط على نافذة السياق. استدعاء get_file ساذج على ملف Figma معقد يُعيد شجرة JSON ضخمة. يتعين على الوكلاء إجراء استدعاءات أدوات انتقائية للبقاء ضمن حدود نوافذ السياق. هذا يُدخل استدلالات وحكماً قد تخطئ. figmascope يُعالج الشجرة مسبقاً إلى IR منظم يحتوي فقط ما هو مطلوب، بحجم معروف ومحدود.

نموذج حزمة figmascope: التقاط مرة، ابعث للأبد

يُصدر figmascope ملف .zip من ملفات عادية من Figma REST API — بلا إضافة، بلا خادم، يعمل في متصفحك. تحتوي الحزمة على:

بمجرد التصدير، الحزمة مكتفية بذاتها وثابتة. تُودع في مستودعك جانب الكود الذي تصفه. أي وكيل، أي جلسة، أي مطور، أي وظيفة CI يمكنه قراءتها. لا اتصال بأي شيء مطلوب.

فروق قابلة للإصدار: مقارنة الحزم مثل الكود

هذه أقوى حجة نموذج الحزمة. لأن الناتج عبارة عن JSON و Markdown منظم، يمكنك استخدام diff عليه.

صدّر حزمة قبل سبرينت تصميم. صدّر أخرى بعده. شغّل diff على tokens.json:

- "spacing.4": "16px"
+ "spacing.4": "14px"

هذا تغيير جذري في مقياس التباعد. إنه مرئي وقابل للمراجعة وقابل للتتبع حتى التزام محدد. مع MCP، يحدث نفس التغيير صامتاً — في المرة التالية التي يجلب فيها الوكيل، يحصل على القيمة الجديدة، ولا سجل بأن شيئاً تغيّر.

يمكنك تشغيل هذا كبوابة للـ PR: صدّر الحزمة كجزء من تسليم التصميم، أودعها، اشترط موافقة المصمم والمطور على الفرق قبل بدء التنفيذ. هذا مواصفات-التصميم-كـ-كود. MCP لا يملك ما يعادله.

حجة الحتمية

نفس إصدار ملف Figma + نفس تصدير figmascope = نفس الحزمة. في كل مرة. مخطط IR ثابت. منطق استرداد الرموز حتمي. استخراج مفاتيح السلاسل يعتمد على قواعد.

استرداد MCP غير حتمي. الوكيل يقرر ما يجلبه. وكلاء مختلفون، صياغات مطالبات مختلفة، حدود نوافذ سياق مختلفة — سلوك جلب مختلف. الناتج يعتمد على النموذج.

لتوليد كود واجهة مستخدم الإنتاج، الحتمية مهمة. تريد أن تكون المواصفات التي ولّدت مكوناً قابلة للإعادة. تريد أن تتمكن من إعادة توليد المكوّن من نفس المدخلات والحصول على نتائج متسقة. الحزم تدعم هذا. جلسات MCP لا تدعمه.

المقارنة

البُعد Figma MCP حزمة figmascope
حداثة البيانات دائماً حية — تجلب حالة Figma الحالية لقطة — بحداثة آخر تصدير
خطوة تصدير مطلوبة لا نعم — مرة واحدة لكل إصدار تصميم
قابلية التحكم بالإصدار لا — لا توجد نتيجة نعم — الحزمة JSON + Markdown قابلة للمقارنة
استمرارية عبر الجلسات لا — يجب إعادة الجلب في كل جلسة نعم — الملفات تستمر إلى أجل غير مسمى
يعمل دون اتصال لا نعم
ناتج حتمي لا — الاسترداد يعتمد على النموذج نعم — نفس المدخل → نفس الحزمة دائماً
ضغط على نافذة السياق عالٍ — JSON الخام لـ Figma ضخم وغير منظم منخفض — IR مُعالج مسبقاً بحجم محدود
عمليات الكتابة على Figma نعم (بعض خوادم MCP) لا — تصدير للقراءة فقط
مواصفات التصميم في تاريخ git لا نعم — أودع الحزمة، تتبع تاريخ التصميم
إعداد وكيل مطلوب نعم — هيّئ خادم MCP لكل عميل وكيل لا — أي وكيل يقرأ الملفات يعمل
مفاتيح سلاسل i18n غير موجودة في مخطط Figma MCP الأساسي نعم — stringRef.key في IR + strings.json
IR مكاني / تخطيطي شجرة عقد Figma الخام (بلا أنواع تخطيط دلالية) IR مكتوب: stack / overlay / absolute / leaf
استرداد الرموز المتغيرات إن وُجدت؛ وإلا القيم الخام متغيرات → مستنتجة من التكرار → لا شيء

MCP يتألق لـ "تحرير Figma مباشرة" — الحزم تتألق لـ "بناء واجهة مستخدم إنتاجية"

هذا هو الملخص الصادق. إذا كان سير عملك استكشاف تصميم تحادثياً — "غيّر هذا المكوّن"، "علّق على هذه الشاشة"، "ما هي رموز الألوان في هذا الإطار" — فالاتصال الحي لـ MCP هو النموذج الصحيح. الوكيل متعاون في عملية التصميم، ويحتاج إلى بيانات حالية للقيام بذلك.

إذا كان سير عملك بناء واجهة مستخدم إنتاجية من تصميم منتهٍ (أو قريب من الانتهاء) — تنفيذ مكونات ووصل الحالة وكتابة الاختبارات — فنموذج الحزمة أفضل. تريد المواصفة مرسّخة في مستودعك، قابلة للمقارنة عبر تكرارات التصميم، قابلة للقراءة من أي وكيل بلا تهيئة، وحتمية بما يكفي للبناء عليها.

النموذجان متكاملان. استخدم MCP عندما يكون التصميم في طور التطور وتتكرر بشكل تشاركي. صدّر حزمة figmascope عندما يستقر التصميم وتسلّمه للمهندسين للتنفيذ. تصبح الحزمة مصدر الحقيقة الذي يُبنى التنفيذ عليه — قابل للتتبع والمراجعة والإعادة.