> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Didit MCP: उन्नत विषय, समस्या निवारण और सेल्फ़-होस्टिंग > Didit MCP की भूमिकाएँ और अनुमतियाँ, क्रॉस-एप्लिकेशन व्यवहार, होस्टेड कैटलॉग, वर्कफ़्लो, webhooks, समस्या निवारण और सेल्फ़-होस्टिंग। ## स्कोप और भूमिका अनुमतियाँ कनेक्टर `didit:management` और `didit:verification` स्कोप के तहत काम करता है। एक तीसरा स्कोप, `didit:staff`, भी विज्ञापित है, लेकिन वह केवल Didit स्टाफ़ खातों के लिए मायने रखता है। दोनों सीमाएँ हर कॉल पर लागू होती हैं: token में वही स्कोप होते हैं जिन्हें आपने स्वीकृत किया है, और **इन स्कोप के भीतर आपकी कंसोल भूमिका तय करती है कि आप क्या कर सकते हैं**। प्रभावी पहुँच दोनों का प्रतिच्छेदन है। इसलिए केवल `didit:verification` स्वीकृत करने पर प्रबंधन सतह बंद रहती है, भले ही आप `OWNER` हों। हर टूल एक बैकएंड अनुमति से मैप होता है (जैसे `read:sessions`, `write:workflows`, `delete:lists`; हर टूल के लिए यह [टूल संदर्भ](https://docs.didit.me/hi/integration/mcp/tools.md) में सूचीबद्ध है)। सर्वर 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 सूचियाँ और फ़ोन-देश सूचियाँ भी होती हैं। इसलिए पूरा ग्राफ़ **न** पढ़ें और उसे दोबारा न भेजें। इसके बजाय छोटे **ऑपरेशन** से संपादित करें: **1. खोजें और निरीक्षण करें** `didit_workflow_search { workflow_id }` आपके सभी ऐप्स में वर्कफ़्लो को खोजता है। `didit_workflow_get_graph` संरचना लौटाता है, जिसमें बड़े configs **सारांशित** होते हैं (यह कभी ओवरफ़्लो नहीं होता; कच्चे मान पाने के लिए `include_config: true` पास करें)। `didit_workflow_get_field_definitions` शाखा-योग्य फ़ील्ड और मान्य ऑपरेटरों की सूची देता है। **2. ops से संपादित करें** `didit_workflow_edit_graph` कुछ छोटे ops लेता है: `set_next`, `set_node`, `set_branches`, `merge_node_config`। MCP सर्वर-साइड पर **पूरा ग्राफ़** लाता है, उन्हें लागू करता है, सत्यापित करता है, स्वतः एक **draft** बनाता है और उसे सहेजता है। आपकी allow-lists **बाइट-दर-बाइट** सुरक्षित रहती हैं और अनुरोध से होकर कभी नहीं गुज़रतीं। सत्यापन विफल होने पर `applied: false` लौटता है, और कुछ भी सहेजा नहीं जाता। **3. समीक्षा और प्रकाशित करें** यह तब तक समीक्षा योग्य 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` धन का प्रमाण नोड → और पाइपलाइन में वापस जाने वाला **अन्यथा** पथ। > [!NOTE] > > **शाखा के लिए हमेशा एक स्पष्ट अन्यथा पथ चाहिए।** कैच-ऑल (वह पथ जो तब लिया जाता है जब कोई शर्त मेल न खाए) एक ऐसी शाखा होनी चाहिए जिसके `rules` खाली हों, उदाहरण के लिए `{ "id": "else", "rules": [], "goto": "" }`। यह शाखा नोड का सादा `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 रूप देखने के लिए [वर्कफ़्लो बनाएँ → शाखा और नोड-आधारित वर्कफ़्लो](https://docs.didit.me/hi/management-api/workflows/create.md) देखें। ### 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 क्यों नहीं चला, इस पर शाखा बनाएँ](https://docs.didit.me/hi/management-api/workflows/create.md#जानें-कि-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 के क्रम में है: `{ "": { "": { "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` में नोड `config`s। ## रिस्पॉन्स का आकार (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[]`)। देखें [डेटा मॉडल](https://docs.didit.me/hi/reference/data-models.md) और [सत्यापन स्थितियाँ](https://docs.didit.me/hi/integration/verification-statuses.md)। *** ## webhook को संभालना एजेंट से पोल करने के बजाय, अंतिम निर्णय सीधे अपने बैकएंड तक webhook के ज़रिए पहुँचाएँ: 1. एजेंट `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` के रूप में सेव करें। 2. आपका बैकएंड हर डिलीवरी पर कैनोनिकल **X-Signature-V2** हेडर सत्यापित करता है: `shortenFloats` → `sortKeys` → `JSON.stringify` (अन-एस्केप्ड यूनिकोड) → HMAC-SHA256 → `timingSafeEqual`। यदि `abs(now − X-Timestamp) > 300` सेकंड हो, तो अस्वीकार करें। 3. `event_id` के आधार पर डुप्लिकेट हटाएँ। **5 सेकंड** के भीतर `2xx` लौटाएँ; भारी काम को कतार में भेजें। 4. Didit `5xx` / `404` पर **2 बार** तक पुनः प्रयास करता है (पहले \~1 मिनट, फिर \~4 मिनट के बाद), फिर डिलीवरी छोड़ देता है। असफल डिलीवरी को कंसोल के **डिलीवरी** टैब से रीप्ले करें। एजेंट को केवल रिसीवर *जोड़ना* होता है; वह स्वयं *सुनता* नहीं है। पूरा अनुबंध: [webhooks](https://docs.didit.me/hi/integration/webhooks.md)। *** ## ट्रांसपोर्ट और 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 के लिए काफ़ी है। *** ## समस्या निवारण > [accordion] एजेंट कोई टूल कॉल करता है और 403 या missing\_scope मिलता है > > उस संगठन में आपकी **भूमिका** के पास उस टूल के लिए ज़रूरी अनुमति नहीं है (जैसे `READER` द्वारा write करने की कोशिश); `missing_scope` error उसका नाम बताता है। यदि हर टूल विफल हो, तो reconnect करें या *Log in with Didit* फिर से चलाएँ। (MCP केवल Bearer/OAuth स्वीकार करता है: `x-api-key` को हर टूल reject करता है, इसलिए API कुंजी से 403 ठीक नहीं होगा।) > [accordion] लिखने या हटाने की कार्रवाई नहीं हुई > > विनाशकारी टूल के लिए आपके क्लाइंट में पुष्टि आवश्यक है। कॉल को स्वीकृत करें, या जाँचें कि टूल का पुष्टि प्रॉम्प्ट अपने-आप अस्वीकृत तो नहीं हो रहा। `didit_session_delete`, `didit_session_batch_delete` और `didit_org_reveal_application_api_key` को इसके अलावा tool arguments में `confirm: true` चाहिए; इसके बिना कॉल कुछ चलने से पहले ही reject हो जाती है। > [accordion] 'organization\_id is required' या कोई परिणाम नहीं > > संभवतः आपके पास कई एप्लिकेशन हैं। किसी `*_search` टूल का उपयोग करें (जो सब कुछ खंगालता है) या `didit_context_get` चलाएँ और जो `organization_id` / `application_id` चाहिए उसे पास करें। > [accordion] Sign-in के लिए browser नहीं खुला (hosted) > > कुछ clients (Windsurf, Zed) `mcp-remote` bridge के ज़रिए कनेक्ट होते हैं, इसलिए सुनिश्चित करें कि config में `npx -y mcp-remote@latest https://mcp.didit.me/mcp` है। OAuth handshake फिर से शुरू करने के लिए client को दोबारा खोलें। > [accordion] टूल क्लाइंट में दिखाई नहीं देते > > पुष्टि करें कि server कनेक्ट हुआ है (ज़्यादातर clients status dot दिखाते हैं) और आपने *Log in with Didit* पूरा किया है। MCP host की config बदलने के बाद उसे restart करें। `didit_org_top_up` और `didit_org_reveal_application_api_key` hosted connector पर कभी सूचीबद्ध नहीं होते। > [accordion] 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](#सेल्फ़-होस्टिंग)। > [accordion] फ़ाइल अपलोड अस्वीकार हो गई > > 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` सदस्य का उपयोग कर सकता है, और एजेंट चाहे कुछ भी करे, बैकएंड उसके लिखने के अनुरोध अस्वीकार कर देता है। * किसी नए एजेंट या प्रॉम्प्ट को पहले [सैंडबॉक्स एप्लिकेशन](https://docs.didit.me/hi/integration/sandbox-testing.md) पर आज़माएँ। * किसी सत्यापन को उस सत्यापन के भीतर लिखे टेक्स्ट के कहने पर कभी स्वीकृत या अस्वीकृत न करें। निर्णय, उसकी चेतावनियों और अपनी समीक्षा पर भरोसा करें। ### व्यक्तिगत डेटा टूल परिणामों में नाम, जन्म तिथि, दस्तावेज़ नंबर और छवियों के लिंक जैसा व्यक्तिगत डेटा शामिल हो सकता है, और आपका MCP क्लाइंट उसे उपयोग किए जा रहे मॉडल को भेजता है। किसी लाइव एप्लिकेशन को जोड़ने से पहले जाँच लें कि AI प्रदाता के साथ आपका समझौता इस डेटा को कवर करता है, या सैंडबॉक्स एप्लिकेशन पर काम करें। *** ## सेल्फ़-होस्टिंग होस्टेड सर्वर [github.com/didit-protocol/mcp](https://github.com/didit-protocol/mcp) (MIT) से बनाया गया है। इसे क्लोन करें और **Docker** या Node से चलाएँ। यह हमेशा Didit **उपयोगकर्ता** के रूप में प्रमाणीकरण करता है (कोई API कुंजी मोड नहीं है), किसी भी ट्रांसपोर्ट में। सेटअप के चरण [इंस्टॉलेशन → सेल्फ़-होस्टिंग](https://docs.didit.me/hi/integration/mcp/installation.md#सेल्फ़-होस्टिंग) पर दिए गए हैं। ```bash theme={null} 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= 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 पर लौट आता है। *** > [card] [टूल संदर्भ](https://docs.didit.me/hi/integration/mcp/tools.md) > > क्षेत्र के अनुसार समूहित हर टूल। > [card] [उदाहरण](https://docs.didit.me/hi/integration/mcp/examples.md) > > प्रॉम्प्ट और पूरी बातचीत के उदाहरण। This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.