REST أم MCP لأتمتة التواصل؟ أبق الموافقة البشرية في المسار

الإجابة أولًا: اختر REST لسير تطبيق حتمي بعقد معروف وسياسة إعادة وidempotency واضحة. واختر MCP عندما يحتاج وكيل تفاعلي إلى اكتشاف قائمة أدوات صغيرة ومحدودة النطاق. في المسارين ابدأ بالقراءة، واطلب من شخص اعتماد الحساب والنص والوسائط والرابط والوقت والمنطقة الزمنية قبل أي كتابة خارجية.

REST أم MCP؟

يوفر ناشر المسارين. يربط مثال MCP أدناه بالنقطة https://api.naasher.com/api/mcp عبر Streamable HTTP بمفتاح قراءة. اختبر channels.list وposts.list ثم أضف الكتابة حين توجد خطوة مراجعة صريحة. يستخدم عميل REST العقد ذي الإصدار تحت https://api.naasher.com/api/sdk/v1 ويجب أن يطبق حدود النطاق والاعتماد نفسها.

تحققنا من هذا المسار على بيئة ناشر الإنتاجية في 22 أغسطس 2026: نجحت المصادقة بمفتاح محدود النطاق، تفاوض الخادم على إصدار MCP 2025-11-25، ولم يعرض tools/list إلا أداتَي القراءة المسموح بهما. هذا هو السلوك المقصود: الصلاحيات تحدد ما يستطيع الوكيل اكتشافه أصلًا، لا ما سيُرفض بعد المحاولة فقط.

1. أنشئ مفتاحًا محدود النطاق

من الإعدادات ← مفاتيح API أنشئ مفتاحًا جديدًا وحدد بيئة الاستخدام. للاتصال الأول اختر:

• channels:read لعرض الحسابات الاجتماعية المتصلة.
• posts:read لعرض المنشورات والفلاتر المتاحة.

لا تضف posts:create أو posts:schedule أو analytics:read لمجرد أنها متاحة. امنح كل تكامل أقل مجموعة صلاحيات تؤدي مهمته، واستخدم مفتاحًا مستقلًا لكل عميل كي تستطيع إلغاء أحدها دون تعطيل الآخرين.

يعرض ناشر سر المفتاح مرة واحدة. خزّنه كمتغير بيئة أو في مخزن أسرار العميل، ولا تكتبه داخل ملف إعدادات سيُرفع إلى Git.

2. أضف نقطة الاتصال إلى العميل

يستخدم ناشر Streamable HTTP، وهو نقل MCP القياسي الذي يجمع رسائل JSON-RPC في نقطة HTTP واحدة. مثال إعداد عام:

{
  "mcpServers": {
    "naasher": {
      "type": "http",
      "url": "https://api.naasher.com/api/mcp",
      "headers": {
        "x-naasher-api-key": "<YOUR_KEY>"
      }
    }
  }
}

استبدل العنصر النائب عبر آلية الأسرار الخاصة بعميلك بدل كتابة المفتاح في ملف سيُرفع إلى Git. يدعم الخادم أيضًا ترويسة Authorization: Bearer. راجع توثيق خادم MCP للإعداد والأدوات الحالية.

3. اختبر القراءة قبل الكتابة

اطلب من الوكيل:

اعرض الأدوات المتاحة، ثم اعرض قنواتي المتصلة وآخر المنشورات. لا تنشئ أو تعدّل أو تنشر أي شيء.

مع مفتاح القراءة يجب أن يعرض tools/list:

• channels.list
• posts.list

إذا ظهرت أداة كتابة لم تتوقعها، أوقف الاختبار وألغ المفتاح ثم أنشئ واحدًا بنطاقات أضيق. وإذا لم تظهر أداة تحتاجها، عدّل النطاقات من ناشر بدل مشاركة مفتاح أوسع من تكامل آخر.

4. أضف الكتابة مع بوابة مراجعة

عندما تحتاج الوكيل لصياغة المسودات، أضف posts:create. ولتحديد موعد النشر أضف posts:schedule. اجعل الطلب ينشئ مسودة أولًا، ثم يعرض النص والقنوات والموعد والمنطقة الزمنية قبل الجدولة.

مثال آمن:

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

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

قائمة تحقق قبل الاعتماد

• المفتاح مخصص لعميل واحد ولم يُنسخ إلى مستودع أو محادثة.
• tools/list لا يعرض إلا الأدوات المطلوبة.
• المنطقة الزمنية والقنوات المقصودة واضحة قبل الجدولة.
• يوجد شخص يراجع النص والوسائط والروابط قبل النشر.
• عُرّف مالك لإلغاء المفتاح وتدويره عند انتهاء الاستخدام.
• لكل كتابة خارجية سياسة idempotency ونتيجة غير مؤكدة على مستوى التطبيق؛ صياغة الطلب ليست هذه السياسة.
• يرى المعتمد هوية الحساب البعيد والنص النهائي والوسائط والرابط والوقت والمنطقة الزمنية.

ميزة MCP متاحة ضمن باقتَي الفِرق والوكالات. راجع الأسعار، أو ابدأ بدليل ربط لينكدإن إذا كانت القناة هي الخطوة التالية.