الانتقال إلى المحتوى الرئيسي
فيما يلي بعض الأنماط التي تُظهر ما يجيده Didit MCP. صِغ طلباتك بلغة بسيطة، فالوكيل يختار الأدوات بنفسه. كل أداة مذكورة أدناه موجودة في مرجع الأدوات.

أمثلة سريعة

العمليات والمراقبة (عبر التطبيقات)
  • “اعرض لي آخر 5 جلسات قيد المراجعة عبر جميع تطبيقاتي.” ← didit_session_search مع status: "In Review" وlimit: 5
  • “كم عدد الأشخاص الذين حاولوا التحقق من رقم الهاتف لكنهم تسرّبوا خلال الـ15 يوماً الماضية؟” ← didit_analytics مع last_n_days: 15 (استدعاء واحد؛ يقرأ مسار التحويل الخاص بالميزة)
  • “ابحث عن العميل ذي vendor_data user_8842 وأخبرني بالتطبيق الذي ينتمي إليه وبحالته.” ← didit_vendor_user_search
  • “ما هو الرصيد لدي، وما معدل التحويل لهذا الشهر؟” ← didit_org_get_balance + didit_analytics
الإعدادات
  • “أنشئ سير عمل KYC يتضمن مسح الهوية + كشف الحيوية، وأعطني رابط التحقق.” ← didit_workflow_create ← didit_session_create
  • “أنشئ سير عمل للتحقق من الهوية يقبل جوازات السفر فقط، ثم كشف حيوية بصورة السيلفي.” ← didit_workflow_create. اكتفِ بقول documents_allowed: ["PASSPORT"]، وسيوسّعها MCP إلى جوازات السفر فقط لكل دولة (انظر المتقدم → إعدادات الميزات).
  • “سير عمل جديد: امسح جواز السفر؛ إذا رُفضت الهوية فارفض الجلسة؛ وإذا كانت المهنة المصرّح بها ≈ ‘Software Engineer’ (≥60%) فنفّذ كشف الحيوية؛ وإلا فاطلب إثبات العنوان باللغة الإسبانية؛ ثم اتخذ القرار تلقائياً.” ← didit_workflow_get_field_definitions ← didit_workflow_validate_graph ← didit_workflow_set_graph
  • “في سير العمل 26d33c04…، بعد التحقق من الهوية: إذا رُفضت فارفض الجلسة؛ وإذا كانت المهنة مطابقة بنسبة ≥80% لـ ‘Software Engineer’ فأضف خطوة Document AI لإثبات الأموال؛ ثم تابع.” ← didit_workflow_search ← didit_workflow_get_graph ← didit_workflow_edit_graph (تعديلات صغيرة، تُحفظ كمسودة قابلة للمراجعة)
  • “في أي الدول يمكنني تقديم تسجيل دخول عبر BankID أو MitID بدلاً من مسح المستند؟” ← didit_workflow_get_id_verification_methods_catalog
  • “سجّل وجهة webhook لتلقي تحديثات الحالة على https://myapp.com/webhooks/didit.” ← didit_webhook_create
الامتثال
  • “افحص هذه المحفظة بحثاً عن AML، وأضفها إلى قائمة الحظر إذا سجّلت تطابقًا.” ← didit_transaction_screen_wallet ← didit_blocklist_add
  • “افتح حالة للجلسة … وعيّنها لي.” ← didit_case_create ← didit_case_manage
  • “هل Acme Ltd شركة مسجلة في المملكة المتحدة، ومن هم مساهموها؟” ← didit_verify_kyb_search ← didit_verify_kyb_select

1. إعداد التحقق من الهوية

أنت: “أعدّ التحقق من الهوية عبر Didit لتطبيقي باستخدام مسح الهوية وكشف الحيوية، وأعطني رابطاً أستطيع تجربته.” الوكيل: سأنشئ سير العمل أولاً. (يستدعي didit_workflow_create بالمعاملات workflow_label: "Standard KYC" وfeatures: [{ "feature": "OCR" }, { "feature": "LIVENESS" }]) تم نشر “Standard KYC”، وworkflow_id = 6f2c…. سأنشئ الآن جلسة لتجربته. (يستدعي didit_session_create بالمعاملات workflow_id: "6f2c…" وvendor_data: "test-user-1") هذا رابطك: https://verify.didit.me/session/…. افتحه على هاتفك لتشغيل التدفق. في بيئة الإنتاج، ينشئ الخادم الخلفي لتطبيقك الجلسات عبر REST API:
الرأس x-api-key هو مفتاح API الخاص بـ REST لتطبيقك لخادمك الخلفي، وهو منفصل عن الطريقة التي سجّلت بها الدخول إلى هذا MCP، وهي تستخدم تسجيل الدخول باستخدام Didit. هل تريد أن أسجّل وجهة webhook أيضاً؟ أنت: “نعم، الـendpoint الخاص بي هو https://myapp.com/webhooks/didit.” الوكيل: (يستدعي didit_webhook_create بالمعاملات label: "Production" وurl: "https://myapp.com/webhooks/didit" وwebhook_version: "v3" وsubscribed_events: ["status.updated"]) تم. السر المشترك للتوقيع مُخفى في الاستجابة التي أتلقاها، لذا انسخه من Webhooks في الكونسول واحفظه باسم DIDIT_WEBHOOK_SECRET. تحقق من الرأس X-Signature-V2 في كل تسليم قبل الوثوق به.

2. التحقق من الشركات (KYB): التحقق من شركة في السجل

أنت: “هل Acme Trading Ltd شركة بريطانية حقيقية؟ رقم تسجيلها 12345678.” الوكيل: (يستدعي didit_verify_kyb_search بالمعاملات country_code: "GB" وname: "Acme Trading Ltd" وregistration_number: "12345678") هناك مرشح واحد: ACME TRADING LTD، تأسست عام 2019، وحالتها نشطة، ومكتبها المسجل في مانشستر. هل تريد السجل الكامل مع المسؤولين والمساهمين؟ أنت: “نعم، وأخبرني من هم المستفيدون الحقيقيون.” الوكيل: (يستدعي didit_verify_kyb_select بالمعامل kyb_response_id الخاص بالمرشح) تم استرجاع السجل الكامل: مديران، وشخص واحد له سيطرة كبيرة يملك 75% فأكثر من الأسهم وحقوق التصويت. يتضمن السجل تاريخ الإيداعات والعنوان المسجل. كان هذا استعلاماً من السجل خاضعاً للفوترة (استدعاءان يستهلكان الرصيد). إذا أردت أن يتم ذلك تلقائياً لكل عميل من الشركات، يمكنني إضافة KYB_REGISTRY إلى سير عمل KYB باستخدام didit_workflow_create، ويوضح didit_workflow_get_kyb_registry_catalog مستويات البيانات التي يبيعها سجل المملكة المتحدة.

3. العمل على قائمة انتظار المراجعة

أنت: “ما الذي ينتظر مراجعتي، وما المشكلة في كل واحد منها؟” الوكيل: (يستدعي didit_session_search مع status: "In Review" وlimit: 10) أربع جلسات عبر تطبيقين قيد المراجعة. أقرأ قرار كل جلسة. (يستدعي didit_session_get_decision لكل session_id) أنت: “وافق على a1f3: لقد نظرت إلى صورة السيلفي وتأكدت أنه الشخص نفسه. ارفض b7c2، المستند منتهي الصلاحية.” الوكيل: (يستدعي didit_session_update_status مع session_id: "a1f3…" وnew_status: "Approved"، ثم مع session_id: "b7c2…" وnew_status: "Declined" وcomment: "Expired document") تم تحديث الجلستين. (يستدعي didit_session_add_review على a1f3… مع الملاحظة “Manual selfie review: same person”) أُضيفت ملاحظة المراجعة حتى يوضح سجل التدقيق سبب اعتماد القرار رغم الدرجة. حالتا AML وإثبات العنوان ما زالتا مفتوحتين. قل كلمتك وسأفتح حالة لتطابق PEP باستخدام didit_case_create.

4. اختبار رجعي لقاعدة المعاملات قبل تفعيلها

أنت: “أريد وسم أي شخص يُجري أكثر من 3 تحويلات تتجاوز $1,000 في الساعة. ما مدى كثرة التنبيهات التي ستولّدها هذه القاعدة؟” الوكيل: (يستدعي didit_transaction_rule_backtest مع conditions على amount > 1000، وaggregation بعدد ≥ 3 عبر نافذة زمنية مدتها ساعة واحدة، وperiod_days: 90) خلال آخر 90 يومًا كانت هذه القاعدة ستُشغَّل على 14 معاملة من 6 أشخاص، واثنان من هؤلاء الأشخاص موسومان بالفعل. هل تريد أن أنشئها في وضع TEST بحيث تسجل التطابقات دون تنفيذ أي إجراء؟ أنت: “نعم، وضع TEST.” الوكيل: (يستدعي didit_transaction_rule_create مع title: "Velocity: 3+ transfers over $1,000 per hour" وcategory: "aml_ctf" وmode: "TEST"، والقيمتين نفسيهما لـconditions وaggregation، وقائمة actions تضع وسمًا على الشخص) تم الإنشاء. راقبها باستخدام didit_transaction_rule_get بعد بضعة أيام. وعندما تكون راضيًا، ينقل didit_transaction_rule_update قيمة mode إلى ACTIVE. كما تتضمن didit_transaction_rule_library_list قواعد السرعة الجاهزة من Didit، إذا فضلت تثبيت إحداها.

نتائج الجلسات غير متزامنة

تُرجع didit_session_create قيمة session_id وsession_token والرابط المستضاف url، لكن عملية التحقق لم تتم بعد. يفتح المستخدم الرابط url ويُكمل الخطوات. يصل القرار النهائي عبر إحدى الطريقتين:
  1. webhook من نوع status.updated (موصى به)، أو
  2. didit_session_get_decision (الاستعلام الدوري، كخيار احتياطي).
تشترك الطريقتان في البنية نفسها، وهي دائمًا مصفوفات بصيغة الجمع مع node_id لكل إدخال:
لا تقرأ أبدًا مفاتيح V2 بصيغة المفرد (id_verification وliveness)، فهي لا تُرسل إلا عندما تكون وجهة webhook مثبتة صراحةً على webhook_version: "V2". راجع نماذج البيانات للاطلاع على مرجع الحقول لكل ميزة، ومتقدم → webhook للاطلاع على قواعد التحقق وإعادة المحاولة.

استخدمه مع التكامل بالموجّه الواحد

بروتوكول MCP مفيد جدًا لتشغيل Didit. ولجعل وكيلًا يكتب تكاملًا كاملًا (مسار الخادم الخلفي + SDK الواجهة الأمامية + معالج webhook + مخطط قاعدة البيانات)، أعطِه موجّه التكامل. فهو يمر بالخطوات السبع، ويستدعي أدوات MCP لإنشاء سير العمل والجلسة وwebhook مباشرةً.

مرجع الأدوات

كل ما يمكن للوكيل استدعاؤه.

المواضيع المتقدمة واستكشاف الأخطاء وإصلاحها

الأدوار، والسلوك عبر التطبيقات، وwebhooks، والاستضافة الذاتية.
آخر تعديل في ٧ نوفمبر ٢٠٢٦