Didit MCP: उन्नत विषय, समस्या निवारण और सेल्फ़-होस्टिंग

स्कोप और भूमिका अनुमतियाँ

कनेक्टर didit:management और didit:verification स्कोप के तहत काम करता है। एक तीसरा स्कोप, didit:staff, भी विज्ञापित है, लेकिन वह केवल Didit स्टाफ़ खातों के लिए मायने रखता है। दोनों सीमाएँ हर कॉल पर लागू होती हैं: token में वही स्कोप होते हैं जिन्हें आपने स्वीकृत किया है, और इन स्कोप के भीतर आपकी कंसोल भूमिका तय करती है कि आप क्या कर सकते हैं। प्रभावी पहुँच दोनों का प्रतिच्छेदन है। इसलिए केवल didit:verification स्वीकृत करने पर प्रबंधन सतह बंद रहती है, भले ही आप OWNER हों। हर टूल एक बैकएंड अनुमति से मैप होता है (जैसे read:sessions, write:workflows, delete:lists; हर टूल के लिए यह टूल संदर्भ में सूचीबद्ध है)। सर्वर token introspection से मिली संगठन अनुमतियों के आधार पर वह अनुमति पहले से जाँचता है, और यह MCP_PERMISSION_MODE से नियंत्रित होता है:

मोड	व्यवहार
`shadow` (डिफ़ॉल्ट)	हर टूल सूचीबद्ध होता है; ऐसा कॉल जिसे आपकी भूमिका करने की अनुमति नहीं है, बैकएंड तक जाता है, जो `403` लौटाता है। यह निर्णय सर्वर के ऑडिट लॉग में दर्ज होता है।
`enforce`	जिन टूल को आपकी भूमिका चलाने की अनुमति नहीं है, वे `tools/list` से हटा दिए जाते हैं; ऐसे किसी टूल को कॉल करने पर `missing_scope` त्रुटि लौटती है, जिसमें अनुमति का नाम होता है।
`off`	कोई पूर्व-जाँच नहीं होती।

MCP आपकी भूमिका से आगे कभी नहीं जाता। किसी एक टूल पर 403 का अर्थ है कि आपकी भूमिका में वह अनुमति नहीं है, न कि पूरा कनेक्शन विफल हो गया है।

क्रॉस-एप्लिकेशन और संगठन निर्धारण

Didit प्रबंधन API हर एप्लिकेशन के दायरे में है (/organization/{org}/application/{app}/…)। MCP आपके लिए दायरा स्वयं तय करता है:

एक संगठन + एक एप्लिकेशन → अपने-आप तय हो जाता है; आपको कभी ID पास नहीं करनी होती।
कई एप्लिकेशन → क्रॉस-एप्लिकेशन टूल (didit_session_search, didit_transaction_search, didit_case_search, didit_vendor_user_search, didit_vendor_business_search, didit_workflow_search, didit_analytics) एक ही कॉल में सभी एप्लिकेशन का परिणाम एकत्र करते हैं, और हर पंक्ति पर उसका organization_id / application_id अंकित होता है।
प्रति-एप्लिकेशन सूची टूल (didit_session_list, didit_transaction_list, didit_case_list, didit_vendor_user_list, didit_vendor_business_list, didit_workflow_list) कोई एप्लिकेशन निर्दिष्ट न करने पर अपने-आप सभी एप्लिकेशन पर लागू होते हैं। इसलिए कई एप्लिकेशन होने पर भी सामान्य “मेरे सत्र सूचीबद्ध करें” अनुरोध काम करता है। किसी एक एप्लिकेशन तक सीमित करने के लिए organization_id और application_id दें।

अपने सभी संगठन और एप्लिकेशन (और उनकी ID) एक ही कॉल में देखने के लिए didit_context_get का उपयोग करें। यह हर एप्लिकेशन का mode (live या sandbox) भी बताता है, इसलिए एप्लिकेशन के नाम से एनवायरनमेंट का अनुमान कभी न लगाएँ। सैंडबॉक्स एप्लिकेशन पर didit_session_create बिना बिलिंग वाले परीक्षण रन के लिए sandbox_scenario स्वीकार करता है।

हॉस्टेड कैटलॉग में क्या है

हॉस्टेड कनेक्टर आपको 169 टूल देता है। इसमें 17 Investigator टूल भी सूचीबद्ध हैं, जो तभी काम करते हैं जब Investigator आपके संगठन के लिए सक्षम हो। दो और टूल, didit_org_top_up (Stripe चेकआउट) और didit_org_reveal_application_api_key (कच्चा सीक्रेट), हर OAuth-प्रमाणित कॉलर के tools/list में छिपे रहते हैं। पाँच खाता-सेटअप टूल (didit_account_*) रिमोट सर्वर से पूरी तरह बाहर रखे गए हैं और वहाँ चलने से इनकार करते हैं, क्योंकि रिमोट कनेक्टर को टूल तर्कों के रूप में क्रेडेंशियल कभी नहीं लेने चाहिए। स्थानीय stdio सर्वर इन सभी को रखता है, और कुल 193 टूल होते हैं। सूचीबद्ध हर टूल के साथ MCP एनोटेशन (readOnlyHint, destructiveHint, openWorldHint, एक title) और एक outputSchema आता है। साथ ही _meta["anthropic/toolGroup"] लेबल होता है, जो उसका क्षेत्र बताता है (जैसे Sessions, Workflows & Questionnaires, Transactions (AML) आदि)। Claude जैसे क्लाइंट इन एनोटेशन का उपयोग करके कनेक्टर के टूल को केवल-पढ़ने, लिखने और विनाशकारी समूहों में बाँटते हैं।

शाखा वाले वर्कफ़्लो

सरल वर्कफ़्लो सुविधाओं की एक सपाट सूची होते हैं। शर्त-आधारित तर्क के लिए, जैसे किसी स्थिति पर अस्वीकार करना, निकाले गए फ़ील्ड के आधार पर रूट करना, किसी मिलान के आधार पर किसी चरण को सशर्त चलाना, या दस्तावेज़ AI अनुरोध जोड़ना, MCP Didit के नोड ग्राफ़ का उपयोग करता है (यह कंसोल के विज़ुअल बिल्डर जैसी ही संरचना है)। ग्राफ़ { start_node, nodes } का रूप लेता है, और हर नोड एक feature, branch, status (टर्मिनल), action या webhook होता है। शाखा के नियम ऑपरेटरों का समर्थन करते हैं, जिनमें fuzzy_match भी शामिल है (स्ट्रिंग फ़ील्ड के लिए, score 0–100 समानता थ्रेशोल्ड के साथ), जो kyc.extra_fields.profession जैसे निकाले गए फ़ील्ड पर लागू होता है। एक DOCUMENT_AI सुविधा नोड दस्तावेज़ों का अनुरोध करता है (उदाहरण के लिए, धन का प्रमाण)।

मौजूदा वर्कफ़्लो को संपादित करना (अनुशंसित)

असली वर्कफ़्लो में बड़े feature configs होते हैं। OCR का documents_allowed allow-list 150 KB+ तक का हो सकता है, और इसके साथ POA सूचियाँ और फ़ोन-देश सूचियाँ भी होती हैं। इसलिए पूरा ग्राफ़ न पढ़ें और उसे दोबारा न भेजें। इसके बजाय छोटे ऑपरेशन से संपादित करें:

खोजें और निरीक्षण करें

didit_workflow_search { workflow_id } आपके सभी ऐप्स में वर्कफ़्लो को खोजता है। didit_workflow_get_graph संरचना लौटाता है, जिसमें बड़े configs सारांशित होते हैं (यह कभी ओवरफ़्लो नहीं होता; कच्चे मान पाने के लिए include_config: true पास करें)। didit_workflow_get_field_definitions शाखा-योग्य फ़ील्ड और मान्य ऑपरेटरों की सूची देता है।

ops से संपादित करें

didit_workflow_edit_graph कुछ छोटे ops लेता है: set_next, set_node, set_branches, merge_node_config। MCP सर्वर-साइड पर पूरा ग्राफ़ लाता है, उन्हें लागू करता है, सत्यापित करता है, स्वतः एक draft बनाता है और उसे सहेजता है। आपकी allow-lists बाइट-दर-बाइट सुरक्षित रहती हैं और अनुरोध से होकर कभी नहीं गुज़रतीं। सत्यापन विफल होने पर applied: false लौटता है, और कुछ भी सहेजा नहीं जाता।

समीक्षा और प्रकाशित करें

यह तब तक समीक्षा योग्य draft बना रहता है जब तक आप publish नहीं करते (कंसोल में या didit_workflow_publish के ज़रिए)। लाइव संस्करण कभी नहीं छुआ जाता।

उदाहरण के लिए, पहचान सत्यापन के बाद एक शाखा डालने के लिए, जो आपकी मौजूदा पाइपलाइन में वापस जुड़ती है, आपको केवल यह भेजना होता है: OCR नोड का next एक नई शाखा की ओर पुनः रूट करें, और शाखा के साथ एक टर्मिनल Declined नोड और एक DOCUMENT_AI चरण जोड़ें (जिसका next मूल अगले चरण की ओर वापस इंगित करता है)। बाकी 10 नोड और उनकी allow-lists अछूते रहते हैं।

“पहचान सत्यापन के बाद, यदि वह अस्वीकृत हुई, तो अस्वीकार करें; यदि profession ≈ ‘Software Engineer’ (≥80%) है, तो धन के प्रमाण का अनुरोध करें; फिर जारी रखें।” → एक branch नोड: kyc.status == Declined → एक Declined status नोड; kyc.extra_fields.profession fuzzy_match “Software Engineer” score 80 → एक DOCUMENT_AI धन का प्रमाण नोड → और पाइपलाइन में वापस जाने वाला अन्यथा पथ।

शाखा के लिए हमेशा एक स्पष्ट अन्यथा पथ चाहिए। कैच-ऑल (वह पथ जो तब लिया जाता है जब कोई शर्त मेल न खाए) एक ऐसी शाखा होनी चाहिए जिसके rules खाली हों, उदाहरण के लिए { "id": "else", "rules": [], "goto": "<liveness>" }। यह शाखा नोड का सादा next नहीं होना चाहिए। MCP (और बैकएंड) शाखा नोड के next को स्वतः एक अन्यथा शाखा में बदल देते हैं, ताकि कोई शाखा बिना दिखाई देने वाले अन्यथा पथ के अस्पष्ट edge के रूप में प्रस्तुत न हो।

शुरू से नया वर्कफ़्लो बनाने के लिए didit_workflow_validate_graph और फिर didit_workflow_set_graph (पूरा ग्राफ़) का उपयोग करें। या didit_workflow_build_graph को एक सादे feature spec से पूरा ग्राफ़ बनाने दें, बिना सहेजे। यहाँ तक कि सामान्य didit_workflow_create भी इसी node graph के रूप में सहेजा जाता है। MCP आपकी features सूची को chained सुविधा नोड्स में बदलता है, जो एक auto-decide status पर समाप्त होते हैं, ताकि सुविधाएँ वास्तव में चलें। यह डिफ़ॉल्ट रूप से प्रकाशित करता है, और इसे अप्रकाशित रखने के लिए status: "draft" पास करें। पूरा JSON रूप देखने के लिए वर्कफ़्लो बनाएँ → शाखा और नोड-आधारित वर्कफ़्लो देखें।

NFC skip-reason शाखाएँ MCP के साथ

नए ग्राफ़ के लिए, यह पूछें:

“पहचान सत्यापन के बाद NFC वाला एक draft वर्कफ़्लो बनाएँ। यदि nfc.skip_reason DEVICE_WITHOUT_NFC या DOCUMENT_WITHOUT_CHIP है, तो सत्र को समीक्षाधीन स्थिति में भेजें; अन्यथा उसे स्वीकृत करें। एक स्पष्ट अन्यथा शाखा रखें और सहेजने से पहले ग्राफ़ को सत्यापित करें।”

एजेंट को didit_workflow_get_field_definitions, didit_workflow_validate_graph और फिर didit_workflow_set_graph कॉल करना चाहिए। किसी मौजूदा वर्कफ़्लो के लिए, यह पूछें:

“वर्कफ़्लो 26d33c04… संपादित करें: उसके NFC नोड के बाद, ज्ञात nfc.skip_reason के सात मानों में से कोई भी मान समीक्षाधीन की ओर रूट करें, और मौजूदा सफल-NFC पथ को स्पष्ट अन्यथा के रूप में बनाए रखें। एक draft सहेजें; उसे प्रकाशित न करें।”

एजेंट को didit_workflow_search, didit_workflow_get_graph, didit_workflow_get_field_definitions और फिर didit_workflow_edit_graph कॉल करना चाहिए। संपादन टूल छोटे ऑपरेशन को सर्वर-साइड पर लागू करता है, इसलिए वह असंबंधित नोड्स और बड़ी allow-lists को सुरक्षित रखता है। सात मानों, equals/in नियमों, null व्यवहार और एक पूरे क्रमबद्ध ग्राफ़ के लिए वर्कफ़्लो बनाएँ → NFC क्यों नहीं चला, इस पर शाखा बनाएँ देखें।

सुविधा कॉन्फ़िगरेशन और allow-lists

सुविधा नोड का config यह सीमित करता है कि वह क्या स्वीकार करता है। didit_workflow_get_feature_config_schema हर feature द्वारा लिए जाने वाली हर key को उसके प्रकारों और डिफ़ॉल्ट मानों के साथ लौटाता है। दो catalog टूल (didit_workflow_get_id_verification_methods_catalog और didit_workflow_get_kyb_registry_catalog) उन सर्वर-संचालित प्रश्नों के उत्तर देते हैं जिन पर कोई config निर्भर करता है। मानक OCR allow-list प्रति-देश, फिर प्रति-दस्तावेज़, फिर object के क्रम में है: { "<ISO3>": { "<CODE>": { "enabled": 1 } } } (उदाहरण: { "ESP": { "P": { "enabled": 1 } } })। MCP वैलिडेट करने से पहले अधिक सरल रूपों को सामान्यीकृत करता है, ताकि आपको यह संरचना हाथ से न लिखनी पड़े:

आप यह पास कर सकते हैं	इसमें सामान्यीकृत किया जाता है
एक दस्तावेज़-प्रकार का array — `["PASSPORT"]`	हर देश के लिए वही दस्तावेज़ (दुनिया भर में केवल पासपोर्ट)
दस्तावेज़ के नाम या कोड — `PASSPORT`/`P`, `NATIONAL_ID`/`ID`, `DRIVER_LICENSE`/`DL`, `RESIDENCE_PERMIT`/`RP` (साथ ही `SSC`, `HIC`, `TC`)	मानक कोड
एक `"ALL"` देश key — `{ "ALL": { "P": 1 } }`	हर देश पर लागू
सरल flags — `{ "ESP": { "P": 1 } }`	`{ "ESP": { "P": { "enabled": 1 } } }`
पूरी तरह से छोड़ा गया	सभी दस्तावेज़, सभी देश

PROOF_OF_ADDRESS का poa_languages_allowed उसी विचार पर आधारित है। इसमें एक भाषा array (["es"]) या एक map ({ "es": 1 }) पास करें। ये सुविधाएँ हर उस जगह लागू होती हैं जहाँ आप MCP को सुविधा कॉन्फ़िगरेशन देते हैं: didit_workflow_create की features, और set_graph, edit_graph तथा validate_graph में नोड configs।

रिस्पॉन्स का आकार (V3 अनुबंध)

हर टूल REST endpoint का मूल JSON ज्यों का त्यों लौटाता है। इन दो बातों को जानना ज़रूरी है:

सिंक्रोनस टूल्स (वर्कफ़्लो, बिलिंग, अकेले verify_*, सूची प्रबंधन) अपना अंतिम परिणाम इनलाइन लौटाते हैं। उसी टर्न में उस पर कार्रवाई करें।
सत्र बनाना असिंक्रोनस है: didit_session_create एक url लौटाता है जिस पर उपयोगकर्ता को प्रक्रिया पूरी करनी होती है; निर्णय webhook से आता है या didit_session_get_decision से मिलता है।

निर्णय की keys हमेशा बहुवचन ऐरे होती हैं, और हर प्रविष्टि के साथ एक node_id होता है (id_verifications[], liveness_checks[], face_matches[], aml_screenings[], poa_verifications[], phone_verifications[], email_verifications[], database_validations[], reviews[], और KYB के लिए registry_checks[], document_verifications[], key_people_checks[])। देखें डेटा मॉडल और सत्यापन स्थितियाँ।

webhook को संभालना

एजेंट से पोल करने के बजाय, अंतिम निर्णय सीधे अपने बैकएंड तक webhook के ज़रिए पहुँचाएँ:

एजेंट didit_webhook_create को एक बार कॉल करता है, जिसमें label, आपका सार्वजनिक HTTPS url, webhook_version: "v3" और subscribed_events (आम तौर पर ["status.updated", "data.updated"]) होते हैं। रिस्पॉन्स में, और didit_webhook_get व didit_webhook_list में भी, साइनिंग सीक्रेट छिपा रहता है। इसे कंसोल में Webhooks से कॉपी करें और DIDIT_WEBHOOK_SECRET के रूप में सेव करें।
आपका बैकएंड हर डिलीवरी पर कैनोनिकल X-Signature-V2 हेडर सत्यापित करता है: shortenFloats → sortKeys → JSON.stringify (अन-एस्केप्ड यूनिकोड) → HMAC-SHA256 → timingSafeEqual। यदि abs(now − X-Timestamp) > 300 सेकंड हो, तो अस्वीकार करें।
event_id के आधार पर डुप्लिकेट हटाएँ। 5 सेकंड के भीतर 2xx लौटाएँ; भारी काम को कतार में भेजें।
Didit 5xx / 404 पर 2 बार तक पुनः प्रयास करता है (पहले ~1 मिनट, फिर ~4 मिनट के बाद), फिर डिलीवरी छोड़ देता है। असफल डिलीवरी को कंसोल के डिलीवरी टैब से रीप्ले करें।

एजेंट को केवल रिसीवर जोड़ना होता है; वह स्वयं सुनता नहीं है। पूरा अनुबंध: webhooks।

ट्रांसपोर्ट और endpoints

Endpoint	उद्देश्य
`POST https://mcp.didit.me/mcp`	MCP endpoint (Streamable HTTP)। `GET` और `DELETE` `405` लौटाते हैं: सर्वर stateless है, हर request के लिए नया server instance बनाता है, और कोई server-initiated stream या session नहीं रखता जिसे बंद करना पड़े।
`GET https://mcp.didit.me/healthz`	स्थिति जाँच: `{ "status": "ok", "service": "didit-mcp-server", "version": "5.1.1" }`।
`GET https://mcp.didit.me/.well-known/oauth-protected-resource/mcp`	RFC 9728 protected-resource metadata (origin root पर भी उपलब्ध)।

यह endpoint दो दौर को सपोर्ट करता है: जो क्लाइंट हर संदेश पर 2026-07-28 या उसके बाद का प्रोटोकॉल संस्करण पिन करते हैं, वे initialize handshake छोड़ सकते हैं और server/discover को कॉल कर सकते हैं; उससे पहले के हर क्लाइंट (Claude Code, Cursor, SDK-based clients) standard Streamable HTTP handshake को बिना बदलाव इस्तेमाल करते हैं। CORS खुला है, इसलिए browser-based clients (Claude web connector, MCP Inspector) cross-origin /mcp और discovery documents तक पहुँच सकते हैं। JSON body की सीमा 25 MB है, जो 15 MB के base64 file input के लिए काफ़ी है।

समस्या निवारण

एजेंट कोई टूल कॉल करता है और 403 या missing_scope मिलता है

उस संगठन में आपकी भूमिका के पास उस टूल के लिए ज़रूरी अनुमति नहीं है (जैसे READER द्वारा write करने की कोशिश); missing_scope error उसका नाम बताता है। यदि हर टूल विफल हो, तो reconnect करें या Log in with Didit फिर से चलाएँ। (MCP केवल Bearer/OAuth स्वीकार करता है: x-api-key को हर टूल reject करता है, इसलिए API कुंजी से 403 ठीक नहीं होगा।)

लिखने या हटाने की कार्रवाई नहीं हुई

विनाशकारी टूल के लिए आपके क्लाइंट में पुष्टि आवश्यक है। कॉल को स्वीकृत करें, या जाँचें कि टूल का पुष्टि प्रॉम्प्ट अपने-आप अस्वीकृत तो नहीं हो रहा। didit_session_delete, didit_session_batch_delete और didit_org_reveal_application_api_key को इसके अलावा tool arguments में confirm: true चाहिए; इसके बिना कॉल कुछ चलने से पहले ही reject हो जाती है।

'organization_id is required' या कोई परिणाम नहीं

संभवतः आपके पास कई एप्लिकेशन हैं। किसी *_search टूल का उपयोग करें (जो सब कुछ खंगालता है) या didit_context_get चलाएँ और जो organization_id / application_id चाहिए उसे पास करें।

कुछ clients (Windsurf, Zed) mcp-remote bridge के ज़रिए कनेक्ट होते हैं, इसलिए सुनिश्चित करें कि config में npx -y mcp-remote@latest https://mcp.didit.me/mcp है। OAuth handshake फिर से शुरू करने के लिए client को दोबारा खोलें।

टूल क्लाइंट में दिखाई नहीं देते

पुष्टि करें कि server कनेक्ट हुआ है (ज़्यादातर clients status dot दिखाते हैं) और आपने Log in with Didit पूरा किया है। MCP host की config बदलने के बाद उसे restart करें। didit_org_top_up और didit_org_reveal_application_api_key hosted connector पर कभी सूचीबद्ध नहीं होते।

VS Code (या कोई अन्य client) OAuth की खोज नहीं कर पाता / browser कभी नहीं खुलता

सुनिश्चित करें कि आप https://mcp.didit.me/mcp की ओर इशारा कर रहे हैं, न कि bare https://mcp.didit.me origin की ओर। Resource metadata /.well-known/oauth-protected-resource/mcp पर उसी path तक सीमित रूप से उपलब्ध है (और उन clients के लिए origin root पर एक copy है जो वहाँ probe करते हैं)। यदि आप self-host कर रहे हैं, तो इसका आम तौर पर मतलब है कि MCP_RESOURCE_URI को पूरे transport URL के बजाय origin पर सेट किया गया है; देखें Self-hosting।

फ़ाइल अपलोड अस्वीकार हो गई

Hosted endpoint पर फ़ाइल को *_base64 के रूप में भेजें (रॉ base64 या data: URL); *_path केवल स्थानीय stdio सर्वर पर काम करता है। फ़ाइलें 15 MB तक सीमित हैं और उनकी सामग्री के अनुसार PNG, JPG, WebP, GIF, BMP, ICO या PDF होनी चाहिए, केवल extension से नहीं।

सुरक्षा

MCP आपकी असली अनुमतियों के साथ काम करता है और लाइव संसाधनों में बदलाव कर सकता है। अपने क्लाइंट में “चलाने से पहले टूल कॉल की समीक्षा करें” चालू रखें, खासकर राइट और विनाशकारी टूल के लिए। MCP स्वयं आपकी कॉन्फ़िगरेशन में कोई सीक्रेट संग्रहीत नहीं करता (यह Didit के साथ लॉग इन करें का उपयोग करता है)। यह टूल आउटपुट में API कुंजियों और webhook साइनिंग सीक्रेट को रेडैक्ट करता है, होस्टेड कैटलॉग से टॉप-अप और रॉ-की टूल छिपाता है, और रिमोट सर्वर पर खाते के क्रेडेंशियल्स को कभी टूल आर्गुमेंट के रूप में स्वीकार नहीं करता। हर टूल कॉल सर्वर के ऑडिट लॉग में कॉलर, टूल और अनुमति के निर्णय के साथ दर्ज की जाती है।

प्रॉम्प्ट इंजेक्शन

Didit टूल वही लौटाते हैं जो आपके उपयोगकर्ताओं ने टाइप किया या अपलोड किया, जैसे नाम, दस्तावेज़ का टेक्स्ट और प्रश्नावली के उत्तर। सत्यापित हो रहा व्यक्ति उस टेक्स्ट को नियंत्रित करता है, इसलिए वह नाम या दस्तावेज़ में आपके एजेंट के लिए निर्देश लिख सकता है, और सर्वर वे फ़ील्ड कैप्चर किए गए रूप में ही लौटाता है। एजेंट इस टेक्स्ट को आपके अपने निर्देशों से भरोसेमंद रूप से अलग नहीं कर सकता, इसलिए हर टूल परिणाम को डेटा मानें:

राइट और विनाशकारी टूल के लिए टूल अनुमोदन चालू रखें, और मंज़ूरी देने से पहले पढ़ें कि एजेंट क्या करने वाला है।
ऐसे सदस्य के रूप में साइन इन करें जिसकी भूमिका काम के अनुरूप हो। जो एजेंट केवल सत्र पढ़ता है, वह READER सदस्य का उपयोग कर सकता है, और एजेंट चाहे कुछ भी करे, बैकएंड उसके लिखने के अनुरोध अस्वीकार कर देता है।
किसी नए एजेंट या प्रॉम्प्ट को पहले सैंडबॉक्स एप्लिकेशन पर आज़माएँ।
किसी सत्यापन को उस सत्यापन के भीतर लिखे टेक्स्ट के कहने पर कभी स्वीकृत या अस्वीकृत न करें। निर्णय, उसकी चेतावनियों और अपनी समीक्षा पर भरोसा करें।

व्यक्तिगत डेटा

टूल परिणामों में नाम, जन्म तिथि, दस्तावेज़ नंबर और छवियों के लिंक जैसा व्यक्तिगत डेटा शामिल हो सकता है, और आपका MCP क्लाइंट उसे उपयोग किए जा रहे मॉडल को भेजता है। किसी लाइव एप्लिकेशन को जोड़ने से पहले जाँच लें कि AI प्रदाता के साथ आपका समझौता इस डेटा को कवर करता है, या सैंडबॉक्स एप्लिकेशन पर काम करें।

सेल्फ़-होस्टिंग

होस्टेड सर्वर github.com/didit-protocol/mcp (MIT) से बनाया गया है। इसे क्लोन करें और Docker या Node से चलाएँ। यह हमेशा Didit उपयोगकर्ता के रूप में प्रमाणीकरण करता है (कोई API कुंजी मोड नहीं है), किसी भी ट्रांसपोर्ट में। सेटअप के चरण इंस्टॉलेशन → सेल्फ़-होस्टिंग पर दिए गए हैं।

git clone https://github.com/didit-protocol/mcp.git && cd mcp

# Docker (recommended) — serves /mcp + /healthz on port 3000
docker build -t didit-mcp . && docker run -p 3000:3000 --env-file .env didit-mcp

# …or with Node
npm install && npm run build
node dist/http.js                                          # hosted HTTP/OAuth
DIDIT_ACCESS_TOKEN=<user-access-token> node dist/index.js  # stdio (headless)

एनवायरनमेंट वेरिएबल

चर	मोड	उद्देश्य
`DIDIT_ACCESS_TOKEN`	stdio	हेडलेस रन के लिए उपयोगकर्ता का Bearer एक्सेस टोकन।
`DIDIT_API_BASE_URL`	दोनों	सत्यापन API का बेस (डिफ़ॉल्ट `https://verification.didit.me/v3`)।
`DIDIT_AUTH_BASE_URL`	दोनों	प्रमाणीकरण API का बेस (डिफ़ॉल्ट `https://apx.didit.me/auth/v2`)।
`MCP_PORT`	होस्टेड	HTTP लिसन पोर्ट (डिफ़ॉल्ट `3000`)।
`MCP_RESOURCE_URI`	होस्टेड	ट्रांसपोर्ट का सार्वजनिक URL, पाथ सहित (उदाहरण के लिए `https://mcp.example.com/mcp`)। RFC 9728 मेटाडेटा URL इसी से बनता है।
`MCP_AUTHORIZATION_SERVER_ORIGIN`	होस्टेड	ऑथराइज़ेशन सर्वर का ओरिजिन (डिफ़ॉल्ट `https://business.didit.me`)।
`MCP_TOKEN_VERIFY_MODE`	होस्टेड	`introspection` (डिफ़ॉल्ट; अपारदर्शी टोकन) या `jwks` (JWT एक्सेस टोकन)।
`MCP_OAUTH_INTROSPECT_URL`	होस्टेड	RFC 7662 इंट्रोस्पेक्शन endpoint।
`MCP_OAUTH_CLIENT_ID` / `MCP_OAUTH_CLIENT_SECRET`	होस्टेड	बेसिक-ऑथ क्रेडेंशियल्स, जिनसे रिसोर्स सर्वर इंट्रोस्पेक्शन को कॉल करता है। इन्हें किसी सीक्रेट मैनेजर से दें।
`MCP_SCOPES_SUPPORTED`	होस्टेड	मेटाडेटा में विज्ञापित स्कोप (डिफ़ॉल्ट `didit:management didit:verification`)।
`MCP_DEFAULT_ORG` / `MCP_DEFAULT_APP`	दोनों	सिंगल-टेनेंट डिप्लॉयमेंट के लिए स्कोप अपने-आप भरें।
`DIDIT_AUTH_ISSUER`, `DIDIT_OIDC_DISCOVERY_URL`, `DIDIT_OIDC_AUTHORIZE_URL`, `DIDIT_OIDC_TOKEN_URL`, `DIDIT_OIDC_REGISTRATION_URL`	होस्टेड	ऑथराइज़ेशन सर्वर के मेटाडेटा के लिए ओवरराइड; केवल तब चाहिए जब वह अपने endpoint ओरिजिन के डिफ़ॉल्ट से अलग जगह प्रकाशित करता हो।
`DIDIT_JWKS_URL`	होस्टेड	`MCP_TOKEN_VERIFY_MODE=jwks` होने पर उपयोग किया जाने वाला JWKS।
`MCP_PERMISSION_MODE`	दोनों	हर टूल के लिए अनुमति की पूर्व-जाँच: `shadow` (डिफ़ॉल्ट), `enforce` या `off`।
`MCP_JSON_BODY_LIMIT`	होस्टेड	JSON-RPC बॉडी की सीमा (डिफ़ॉल्ट `25mb`)।

रिपॉज़िटरी में .env.example एक कॉपी करने योग्य टेम्पलेट है, और ARCHITECTURE.md रिसोर्स-सर्वर और ऑथराइज़ेशन-सर्वर के विभाजन को समझाता है। बूट के समय HTTP सर्वर ऑथराइज़ेशन सर्वर का डिस्कवरी दस्तावेज़ लाता है, और यदि वह पहुँच में न हो तो कॉन्फ़िगर किए गए URL पर लौट आता है।

टूल संदर्भ

क्षेत्र के अनुसार समूहित हर टूल।

उदाहरण

प्रॉम्प्ट और पूरी बातचीत के उदाहरण।

गाइड

प्रमाणीकरण

Model Context Protocol (MCP)

वेब SDK

नेटिव SDK

सर्वर SDK

इंटीग्रेशन

Didit MCP: उन्नत विषय, समस्या निवारण और सेल्फ़-होस्टिंग

स्कोप और भूमिका अनुमतियाँ

क्रॉस-एप्लिकेशन और संगठन निर्धारण

हॉस्टेड कैटलॉग में क्या है

शाखा वाले वर्कफ़्लो

मौजूदा वर्कफ़्लो को संपादित करना (अनुशंसित)

NFC skip-reason शाखाएँ MCP के साथ

सुविधा कॉन्फ़िगरेशन और allow-lists

रिस्पॉन्स का आकार (V3 अनुबंध)

webhook को संभालना

ट्रांसपोर्ट और endpoints

समस्या निवारण

सुरक्षा

प्रॉम्प्ट इंजेक्शन

व्यक्तिगत डेटा

सेल्फ़-होस्टिंग

एनवायरनमेंट वेरिएबल

टूल संदर्भ

उदाहरण

​स्कोप और भूमिका अनुमतियाँ

​क्रॉस-एप्लिकेशन और संगठन निर्धारण

​हॉस्टेड कैटलॉग में क्या है

​शाखा वाले वर्कफ़्लो

​मौजूदा वर्कफ़्लो को संपादित करना (अनुशंसित)

​NFC skip-reason शाखाएँ MCP के साथ

​सुविधा कॉन्फ़िगरेशन और allow-lists

​रिस्पॉन्स का आकार (V3 अनुबंध)

​webhook को संभालना

​ट्रांसपोर्ट और endpoints

​समस्या निवारण

​सुरक्षा

​प्रॉम्प्ट इंजेक्शन

​व्यक्तिगत डेटा

​सेल्फ़-होस्टिंग

​एनवायरनमेंट वेरिएबल

टूल संदर्भ

उदाहरण

स्कोप और भूमिका अनुमतियाँ

क्रॉस-एप्लिकेशन और संगठन निर्धारण

हॉस्टेड कैटलॉग में क्या है

शाखा वाले वर्कफ़्लो

मौजूदा वर्कफ़्लो को संपादित करना (अनुशंसित)

NFC skip-reason शाखाएँ MCP के साथ

सुविधा कॉन्फ़िगरेशन और allow-lists

रिस्पॉन्स का आकार (V3 अनुबंध)

webhook को संभालना

ट्रांसपोर्ट और endpoints

समस्या निवारण

सुरक्षा

प्रॉम्प्ट इंजेक्शन

व्यक्तिगत डेटा

सेल्फ़-होस्टिंग

एनवायरनमेंट वेरिएबल