Debugg AI

Debugg AI — MCP सर्वर

मॉडल कॉन्टेक्स्ट प्रोटोकॉल के माध्यम से AI-संचालित ब्राउज़र परीक्षण। इसे किसी भी URL (या localhost) पर इंगित करें और बताएं कि क्या परीक्षण करना है — एक AI एजेंट आपके ऐप को ब्राउज़ करता है और स्क्रीनशॉट के साथ पास/फेल लौटाता है।

सेटअप

Node.js 20.20.0 या बाद का संस्करण आवश्यक है (posthog-node@^5.26.0 से ट्रांज़िटिव आवश्यकता)।

http://localhost:... URL का परीक्षण करने के लिए caddy बाइनरी आवश्यक है — check_app_in_browser, probe_page, और trigger_crawl localhost लक्ष्यों को स्थानीय Caddy रिवर्स प्रॉक्सी के माध्यम से टनल करते हैं। यह स्वचालित रूप से इंस्टॉल होता है: @radically-straightforward/caddy npm निर्भरता आपके प्लेटफ़ॉर्म के लिए एक पिन किया गया Caddy रिलीज़ डाउनलोड करती है npm install/npx के दौरान, उसी तरह जैसे यह प्रोजेक्ट पहले से ही ngrok बाइनरी के लिए करता है — सामान्य मामले में आपको स्वयं कुछ इंस्टॉल करने की आवश्यकता नहीं है। यदि वह डाउनलोड कभी नहीं चला (npm install --ignore-scripts, एक ऑफ़लाइन/एयर-गैप्ड इंस्टॉल), तो CADDY_BIN को अपने स्वयं के इंस्टॉल पर इंगित करें (brew install caddy / apt install caddy / देखें caddyserver.com/docs/install) — इसकी अनुपस्थिति पहले localhost-URL कॉल पर एक स्पष्ट त्रुटि के रूप में सामने आती है, मौन हैंग के रूप में नहीं। पब्लिक-URL कॉल, हर गैर-ब्राउज़र टूल, और test_suite {action:"run"} (जो अपना स्वयं का समर्पित टनल उपयोग करता है और Caddy को पूरी तरह से बायपास करता है) को किसी भी तरह से इसकी आवश्यकता नहीं है।

debugg.ai पर API कुंजी प्राप्त करें, फिर अपने MCP क्लाइंट कॉन्फ़िग में जोड़ें:

{
  "mcpServers": {
    "debugg-ai": {
      "command": "npx",
      "args": ["-y", "@debugg-ai/debugg-ai-mcp"],
      "env": {
        "DEBUGGAI_API_KEY": "your_api_key_here"
      }
    }
  }
}

या Docker के साथ:

docker run -i --rm --init -e DEBUGGAI_API_KEY=your_api_key quinnosha/debugg-ai-mcp

Dockerfile का npm install चरण caddy को उसी स्वचालित तरीके से उठाएगा जैसे स्थानीय इंस्टॉल सिद्धांत रूप में करते हैं — लेकिन इस लेखन के समय Dockerfile कई निर्देशिकाओं को COPY नहीं करता है जिनकी बिल्ड को अब आवश्यकता है (handlers, tools, types, config) और अभी भी एक tunnels/ निर्देशिका को संदर्भित करता है जो अब मौजूद नहीं है, इसलिए एक नया बिल्ड संभवतः उससे पहले विफल हो जाता है। यह एक पूर्व-मौजूदा अंतर है, Caddy से असंबंधित। वर्तमान में प्रकाशित quinnosha/debugg-ai-mcp इमेज Caddy निर्भरता से पहले की है — localhost-URL कॉल check_app_in_browser/probe_page/trigger_crawl पर उस इमेज के अंदर CaddyBinaryNotFoundError के साथ विफल होंगे जब तक इसे पुनर्निर्मित (Dockerfile ठीक) और पुनः प्रकाशित नहीं किया जाता, या CADDY_BIN एक अलग से बेक किए गए एक पर इंगित नहीं करता। पब्लिक-URL कॉल, गैर-ब्राउज़र टूल, और test_suite {action:"run"} किसी भी तरह से अप्रभावित हैं।

टूल्स

सर्वर 8 टूल प्रदर्शित करता है: तीन ब्राउज़र टूल साथ ही प्रत्येक प्रबंधित इकाई के लिए एक एक्शन-आधारित टूल। मुख्य टूल check_app_in_browser (पूर्ण AI एजेंट) और probe_page (हल्का नो-LLM पेज प्रोब) हैं। बाकी — project, environment, test_suite, test_case, executions — प्रत्येक एक action डिस्क्रिमिनेटर लेते हैं (जैसे {"action":"list"}) जो ऑपरेशन का चयन करता है। विनाशकारी delete क्रियाओं के लिए पुष्टि आवश्यक है (जहां समर्थित है वहां एक एलिसिटेशन प्रॉम्प्ट, अन्यथा confirm: true)।

ब्राउज़र

check_app_in_browser

आपके ऐप के विरुद्ध एक AI ब्राउज़र एजेंट चलाता है। एजेंट नेविगेट करता है, इंटरैक्ट करता है, और स्क्रीनशॉट के साथ रिपोर्ट करता है। Localhost URL स्वचालित रूप से ngrok के माध्यम से टनल किए जाते हैं।

पैरामीटर	प्रकार	विवरण
description	स्ट्रिंग आवश्यक	क्या परीक्षण करना है (प्राकृतिक भाषा)
url	स्ट्रिंग आवश्यक	लक्ष्य URL — http://localhost:3000 स्वचालित रूप से टनल किया जाता है
environmentId	स्ट्रिंग	किसी विशिष्ट वातावरण का UUID
credentialId	स्ट्रिंग	किसी विशिष्ट क्रेडेंशियल का UUID
credentialRole	स्ट्रिंग	भूमिका द्वारा क्रेडेंशियल चुनें (जैसे admin, guest)
username	स्ट्रिंग	लॉगिन के लिए उपयोगकर्ता नाम (अस्थायी — संग्रहीत नहीं)
password	स्ट्रिंग	लॉगिन के लिए पासवर्ड (अस्थायी — संग्रहीत नहीं)
loginCredentials	सरणी	उन लॉगिन के लिए खाते जिन्हें एजेंट कार्य के दौरान हिट करता है — [{username, password, label?}]
useEnvironmentCredentials	बूलियन	डिफ़ॉल्ट true। false वातावरण के संग्रहीत क्रेडेंशियल्स के स्वतः-भरण को रोकता है; नामित खाते के बिना इसका अर्थ है बिल्कुल लॉगिन न करें
freshSession	बूलियन	डिफ़ॉल्ट false। true उस खाते के लिए रखे गए गर्म सत्र को पुनः उपयोग करने के बजाय वास्तविक लॉगिन को बाध्य करता है
auth	ऑब्जेक्ट	प्रमाणीकरण पूर्व-शर्त — {precondition, entryUrl, deepUrl, environmentId, username, password}
repoName	स्ट्रिंग	स्वतः-पहचाने गए git रेपो नाम को ओवरराइड करें (जैसे my-org/my-repo)

प्रति कॉल एक केंद्रित जांच। एजेंट के पास ~25-चरणीय आंतरिक बजट है; व्यापक सुइट्स को कई कॉलों में विभाजित करें।

क्रेडेंशियल्स: उन्हें पैरामीटर के रूप में पास करें, गद्य के रूप में नहीं

केवल description में किसी खाते का नामकरण करने से एजेंट उसका उपयोग नहीं करता — यह वातावरण के संग्रहीत क्रेडेंशियल पर वापस आ जाता है, और गलत खाते की ऐप द्वारा अस्वीकृति एप्लिकेशन विफलता जैसी दिखती है। आप पैरामीटर के रूप में जो कुछ भी पास करते हैं वह रन के हर लॉगिन के लिए वातावरण डिफ़ॉल्ट को हरा देता है, न कि केवल पहले:

• username / password (या credentialId / credentialRole) — रन की पहचान।
• auth.username / auth.password — पूर्व-शर्त लॉगिन को पिन करता है जब आप auth.precondition: "login" का भी उपयोग करते हैं।
• loginCredentials — एक लॉगिन फॉर्म के लिए खाते जिसे एजेंट कार्य के बीच में पहुंचता है। यह उन प्रवाहों के लिए है जैसे पासवर्ड सेट करें → साइन-इन पर वापस जाएं → अभी बनाए गए खाते के रूप में लॉगिन करें, जहां अलग-अलग कॉलों में विभाजित करने से ब्राउज़र स्थिति खो जाएगी।

useEnvironmentCredentials: false सेट करें जब डिफ़ॉल्ट परीक्षण उपयोगकर्ता के लिए मौन फ़ॉलबैक जांच को अमान्य कर देगा।

ऐसा पेज जांच रहे हैं जिसे किसी लॉगिन की आवश्यकता नहीं है? useEnvironmentCredentials: false पास करें और कोई खाता नाम न दें। यह संयोजन ठीक वही कहता है जो इसका अर्थ है — लॉगिन न करें — और रन प्रमाणीकरण को पूरी तरह से छोड़ देता है, लॉगिन फॉर्म की खोज करने के बजाय। इसका उपयोग सार्वजनिक पेजों, मार्केटिंग साइटों, दस्तावेज़ों और प्रमाणीकरण-पूर्व किसी भी चीज़ के लिए करें। यह तेज़ भी है: डिफ़ॉल्ट (auto) पर एजेंट आपके पेज से "लॉग इन" लिंक का अनुसरण करेगा और कुछ भी मूल्यांकन करने से पहले वातावरण के संग्रहीत खाते को आज़माएगा।

सत्र पुनः उपयोग: एक जांच "लॉगिन फॉर्म नहीं" क्यों रिपोर्ट कर सकती है

रन हर बार लॉगिन नहीं करते। सत्यापित लॉगिन के बाद बैकएंड उस खाते का सत्र कैप्चर करता है और उसे समान पहचान के लिए अगले रन पर पुनर्स्थापित करता है, जो लॉगिन को पूरी तरह से छोड़ देता है — यही कारण है कि एक जांच वैध रूप से submitted: false और कोई लॉगिन फॉर्म के साथ वापस आ सकती है: यह पहले से ही साइन इन था। एक पुनर्स्थापित रन स्वयं को logins में reason: "restored_session" के साथ रिपोर्ट करता है, ताकि आप इसे उस रन से अलग बता सकें जिसे वास्तव में कोई फॉर्म नहीं मिला।

सत्र प्रति खाते कुंजीबद्ध होते हैं, इसलिए किसी भिन्न खाते का नामकरण कभी किसी और के सत्र को पुनः उपयोग नहीं करता। पुनः उपयोग को बायपास करने के दो तरीके:

• एकल कॉल पर freshSession: true — इस बार वास्तव में लॉगिन करें, फिर पुनः कैप्चर करें। इसका उपयोग करें जब लॉगिन प्रवाह ही वह है जो आप जांच रहे हैं, जब आपको संदेह है कि संग्रहीत सत्र पुराना है, या जब व्यक्तित्वों के बीच ऐप का एकमात्र मार्ग लॉगआउट है।
• environment टूल, action: "clearSessions" — संग्रहीत सत्रों को अमान्य करें ताकि बाद के रन लॉगिन करें। username / credentialId के साथ संकीर्ण करें; बिना स्कोप के साफ़ करने के लिए पुष्टि की आवश्यकता होती है क्योंकि वातावरण का हर खाता फिर से प्रमाणित होता है।

यह देखने के लिए action: "sessions" का उपयोग करें कि वातावरण वर्तमान में क्या धारण कर रहा है और क्या प्रत्येक का पुनः उपयोग किया जाएगा।

परिणाम वास्तव में उपयोग की गई पहचान की रिपोर्ट करते हैं, इसलिए गलत पहचान टूटे हुए ऐप के रूप में प्रच्छन्न होने के बजाय दिखाई देती है:

"logins": [
  { "username": "qa+invitefix@example.com", "source": "task", "submitted": true, "authenticated": true }
],
"credentialWarning": {
  "requested": "qa+invitefix@example.com",
  "used": ["qatest123@example.com"],
  "message": "This run signed in with an environment default credential even though '…' was specified. …"
}

source है task | explicit | credential_id (एक खाता जिसे आपने नामित किया) या env | env_default (वातावरण का संग्रहीत खाता)। credentialWarning केवल तब दिखाई देता है जब आपने एक खाता नामित किया और वातावरण डिफ़ॉल्ट का उपयोग किया गया। loginError तब दिखाई देता है जब एक नामित खाता हल नहीं हो सका और रन ने भिन्न खाते को प्रतिस्थापित करने से इनकार कर दिया।

प्रत्येक सफल रन स्क्रीनशॉट के साथ एक browserSession ब्लॉक लौटाता है — कैप्चर किए गए HAR (पूर्ण नेटवर्क ट्रेस) और कंसोल लॉग (हर JS कंसोल संदेश) के लिए प्री-साइन किए गए S3 URL। उनका उपयोग रीफ़ेच लूप, हाइड्रेशन त्रुटियों और अन्य रनटाइम मुद्दों का पता लगाने के लिए करें जो टाइप-चेक और यूनिट परीक्षण पास करते हैं:

"browserSession": {
  "harUrl": "https://...session_18139.har?X-Amz-...",
  "consoleLogUrl": "https://...session_18139_console.json?X-Amz-...",
  "recordingUrl": "https://...session_18139_recording.webm?X-Amz-...",
  "harStatus": "downloaded",
  "consoleLogStatus": "downloaded",
  "harRedactionStatus": "redacted",
  "consoleLogRedactionStatus": "redacted"
}

URL अल्पकालिक प्री-साइन किए गए S3 हैं — नवीनीकरण के लिए executions {action:"get", uuid} के माध्यम से मूल निष्पादन को फिर से प्राप्त करें। harStatus / consoleLogStatus 'downloaded' (URL प्राप्त करने योग्य), 'not_available' (पेज ने कुछ भी उत्सर्जित नहीं किया), 'failed' (कैप्चर टूट गया) को असंदिग्ध करते हैं। एक नए रन पर URL आमतौर पर null होते हैं क्योंकि कैप्चर एजेंट के समाप्त होने के बाद एसिंक्रोनस रूप से अपलोड होता है — स्थिति 'downloaded' तक पहुंचने तक executions {action:"get", uuid: executionId} को पोल करें। प्राधिकरण / कुकी / token/secret/api_key हेडर कलाकृतियों को संग्रहीत करने से पहले सर्वर-साइड पर साफ़ किए जाते हैं।

trigger_crawl

प्रोजेक्ट के ज्ञान ग्राफ को आबाद करने के लिए एक सर्वर-साइड ब्राउज़र-एजेंट क्रॉल चलाता है। Localhost URL स्वचालित रूप से टनल होते हैं। सफल अंतर्ग्रहण पर knowledgeGraph.imported === true के साथ {executionId, status, targetUrl, durationMs, outcome?, crawlSummary?, knowledgeGraph?, browserSession?} लौटाता है। browserSession ब्लॉक (HAR + कंसोल-लॉग URL, ऊपर जैसा ही आकार) पूर्ण क्रॉल पर भी मौजूद है।

probe_page

हल्का नो-LLM बैच पेज प्रोब। 1-20 URL पास करें; प्रत्येक नेविगेट करता है, सामग्री पर स्थिर होता है (DOM शांत हो जाता है, सीमित — कभी नेटवर्क मौन पर नहीं, जिसे एक लाइव ऐप कभी नहीं पहुंचता), और प्रदान की गई स्थिति लौटाता है — स्क्रीनशॉट + पेज मेटाडेटा + संरचित कंसोल त्रुटियां + नेटवर्क सारांश। कोई एजेंट लूप नहीं, कोई LLM लागत नहीं, कोई परिदृश्य अभिकथन नहीं। इसका उपयोग "क्या मैंने अभी /settings तोड़ दिया?", रीफैक्टर के बाद मल्टी-रूट स्मोक, CI प्रति-PR स्वीप, और त्वरित is-it-up जांच के लिए करें जहां check_app_in_browser का 60-150s एजेंट लूप अत्यधिक है।

पैरामीटर	प्रकार	विवरण
targets	सरणी आवश्यक	1-20 प्रविष्टियां: [{url, waitForSelector?, waitForLoadState?, timeoutMs?}]
targets[].url	स्ट्रिंग आवश्यक	सार्वजनिक URL या localhost (स्वचालित रूप से टनल)
targets[].waitForLoadState	एनम	'domcontentloaded' (डिफ़ॉल्ट, + एक सीमित सामग्री स्थिरता) / 'load' (थर्ड-पार्टी एम्बेड पर भी रुकता है) / 'networkidle' (स्वीकृत, कभी जारी नहीं — एक लाइव साइट का नेटवर्क निष्क्रिय नहीं होता)
targets[].waitForSelector	स्ट्रिंग	नेविगेशन के बाद प्रतीक्षा करने के लिए वैकल्पिक CSS चयनकर्ता
targets[].timeoutMs	संख्या	प्रति-URL टाइमआउट, 1000-30000 (डिफ़ॉल्ट 10000)
includeHtml	बूलियन	प्रत्येक परिणाम में कच्चा HTML लौटाएं (डिफ़ॉल्ट false)
captureScreenshots	बूलियन	प्रति लक्ष्य एक PNG लौटाएं (डिफ़ॉल्ट true)

एक बैच में सभी लक्ष्य एक सत्र टनल साझा करते हैं, लेकिन केवल समान-पोर्ट (या सभी-सार्वजनिक) बैच एक एकल बैकएंड निष्पादन साझा करते हैं — एक कॉल में एक पोर्ट पर 5 URL समानांतर 5 एकल-URL कॉलों की तुलना में नाटकीय रूप से तेज़ हैं। एक बैच जो कई स्थानीय पोर्ट मिलाता है, प्रति पोर्ट समूह एक अनुक्रमिक बैकएंड निष्पादन में विघटित होता है (अभी भी एक कॉल, अभी भी आपके मूल क्रम में एक विलय results[], लेकिन एक के बजाय N बैकएंड राउंड-ट्रिप — धीमा, अस्वीकृत नहीं)। प्रति-URL error फ़ील्ड बैच लचीलापन संरक्षित करता है: एक विफल लक्ष्य दूसरों को विफल नहीं करता।

networkSummary एकत्रीकरण कुंजी origin + pathname है — रीफ़ेच लूप (?n=0..4 बार-बार एक ही एंडपॉइंट हिट करना) गिनती के साथ एक एकल प्रविष्टि में संक्षिप्त हो जाते हैं, इसलिए /api/poll count: 47 के साथ दिखाई देना कार्रवाई योग्य "अनंत रीफ़ेच लूप" संकेत है जिसके लिए उपयोगकर्ताओं ने मूल रूप से पूछा था।

प्रदर्शन बजट: 1 URL के लिए <10s, 20 के लिए <25s। Localhost मृत-पोर्ट एक कार्यप्रवाह निष्पादन को जलाए बिना <2s में LocalServerUnreachable लौटाता है।

project

क्रिया	पैराम्स	परिणाम
get	{uuid}	क्यूरेटेड प्रोजेक्ट विवरण
list	{q?, page?, pageSize?}	पृष्ठांकित सारांश
create	{name, platform, (teamUuid|teamName), (repoUuid|repoName)}	निर्मित प्रोजेक्ट

टीम और रेपो या तो uuid या नाम से हल होते हैं (केस-असंवेदनशील सटीक मिलान; कोई नहीं होने पर NotFound, कई होने पर AmbiguousMatch)। कोई update/delete नहीं है — DebuggAI वेब ऐप से किसी प्रोजेक्ट का नाम बदलें या हटाएं।

environment

क्रिया	पैरामीटर	परिणाम
get	{uuid, projectUuid?}	क्रेडेंशियल्स के साथ एन्वायरनमेंट (पासवर्ड कभी वापस नहीं किए जाते)
list	{projectUuid?, q?, page?, pageSize?}	पेजिनेटेड एन्वायरनमेंट्स, प्रत्येक में क्रेडेंशियल्स की सूची
create	{name, url, description?, projectUuid?, credentials?}	बनाया गया एन्वायरनमेंट (वैकल्पिक रूप से क्रेडेंशियल्स सीड करता है)
update	{uuid, name?, url?, description?, addCredentials?, updateCredentials?, removeCredentialIds?}	पैच किया गया एन्वायरनमेंट; क्रेडेंशियल ऑपरेशन हटाएँ → अपडेट करें → जोड़ें क्रम में चलते हैं
delete	{uuid, projectUuid?, confirm?}	एन्वायरनमेंट हटाता है (क्रेडेंशियल्स कैस्केड होते हैं) — पुष्टि आवश्यक है
sessions	{uuid, username?, credentialId?}	एन्वायरनमेंट द्वारा रखे गए कैप्चर किए गए लॉगिन सत्र, प्रति खाता, isUsable और एक usableCount के साथ
clearSessions	{uuid, username?, credentialId?, confirm?}	उन्हें अमान्य करता है ताकि अगली बार वास्तविक लॉगिन हो — बिना स्कोप के साफ़ करने के लिए पुष्टि आवश्यक है

projectUuid छोड़े जाने पर git रिपॉजिटरी से स्वतः हल हो जाता है। प्रति-क्रेडेंशियल विफलताएँ credentialWarnings[] में दिखाई देती हैं, बिना एन्वायरनमेंट ऑपरेशन को रोके।

sessions / clearSessions उन गर्म प्रमाणित सत्रों को प्रबंधित करते हैं जिन्हें बैकएंड लॉगिन छोड़ने के लिए पुनः उपयोग करता है (देखें सत्र पुन: उपयोग)। सत्र सामग्री कभी वापस नहीं की जाती — एक सत्र कुकी एक बियरर क्रेडेंशियल है। clearSessions सत्रों को पंक्तियाँ हटाने के बजाय अमान्य चिह्नित करता है, ताकि पुन: उपयोग तुरंत रुक जाए जबकि कैप्चर इतिहास पठनीय रहे।

test_suite

क्रिया	पैरामीटर	परिणाम
list	{projectUuid|projectName, search?, page?, pageSize?}	स्थिति + पास दर के साथ पेजिनेटेड सूट
create	{name, description, projectUuid|projectName}	बनाया गया सूट
run	{suiteUuid|(suiteName+project), targetUrl?}	सभी परीक्षणों को एसिंक्रोनस रूप से ट्रिगर करता है
results	{suiteUuid|(suiteName+project)}	सूट + प्रति-परीक्षण परिणाम
delete	{suiteUuid|(suiteName+project), confirm?}	सॉफ्ट-डिलीट — पुष्टि आवश्यक है

test_case

क्रिया	पैरामीटर	परिणाम
create	{name, description, agentTaskDescription, suiteUuid|(suiteName+project), relativeUrl?, maxSteps?}	बनाया गया परीक्षण मामला (स्वतः-रन नहीं)
update	{testUuid, name?, description?, agentTaskDescription?}	पैच किया गया परीक्षण मामला
delete	{testUuid, confirm?}	सॉफ्ट-डिलीट — पुष्टि आवश्यक है

executions

क्रिया	पैरामीटर	परिणाम
get	{uuid}	पूर्ण विवरण (nodeExecutions + स्थिति + errorInfo) + स्क्रीनशॉट/gif आर्टिफैक्ट
list	{status?, projectUuid?, page?, pageSize?}	पेजिनेटेड सारांश

बैकएंड से 404 isError: true के रूप में {error: 'NotFound', message, uuid} के साथ सामने आता है। क्रेडेंशियल्स हमेशा पासवर्ड के बिना लौटाए जाते हैं।

पेजिनेशन

हर फ़िल्टर-मोड प्रतिक्रिया पेजिनेटेड है। प्रतिक्रिया संरचना:

{
  "filter": { "...echoed query params..." },
  "pageInfo": { "page": 1, "pageSize": 20, "totalCount": 47, "totalPages": 3, "hasMore": true },
  "<items>": [ ... ]
}

वैकल्पिक page (1-अनुक्रमित, डिफ़ॉल्ट 1) और pageSize (डिफ़ॉल्ट 20, अधिकतम 200; अत्यधिक मान क्लैम्प किए जाते हैं) पास करें। कोई भी प्रतिक्रिया कभी चुपचाप छोटी नहीं की जाती।

संसाधन

टूल्स के साथ, सर्वर केवल-पठनीय इकाइयों को MCP संसाधनों के रूप में उजागर करता है ताकि क्लाइंट उन्हें ब्राउज़ कर सकें और संदर्भ के रूप में @-उल्लेख कर सकें:

URI	क्या
debugg-ai://projects	सभी प्रोजेक्ट (पहला पृष्ठ)
debugg-ai://environments	स्वतः-पहचाने गए प्रोजेक्ट के लिए एन्वायरनमेंट्स
debugg-ai://executions	हाल के निष्पादन (पहला पृष्ठ)
debugg-ai://project/{uuid}	एक प्रोजेक्ट, पूर्ण विवरण
debugg-ai://environment/{uuid}	एक एन्वायरनमेंट (क्रेडेंशियल्स इनलाइन, पासवर्ड रिडैक्टेड)
debugg-ai://execution/{uuid}	एक निष्पादन, पूर्ण नोड विवरण + आर्टिफैक्ट लिंक

रीड्स उन्हीं हैंडलर्स को भेजे जाते हैं जैसे project / environment / executions टूल्स, इसलिए डेटा और प्रमाणीकरण समान हैं। संसाधन योगात्मक हैं — संसाधन समर्थन के बिना क्लाइंट टूल्स का उपयोग जारी रखते हैं।

सुरक्षा अपरिवर्तनीयताएँ

• पासवर्ड केवल-लिखने योग्य हैं। वे किसी भी टूल से किसी भी प्रतिक्रिया निकाय में कभी नहीं दिखाई देते।
• टनल URL (*.ngrok.debugg.ai) सभी ब्राउज़र-एजेंट प्रतिक्रियाओं से हटा दिए जाते हैं, जिसमें एजेंट-लेखित पाठ भी शामिल है।
• बैकएंड से 404s isError: true के रूप में {error: 'NotFound', ...} के साथ सामने आते हैं, कभी फेंके गए अपवादों के रूप में नहीं।
• लापता DEBUGGAI_API_KEY पहले आह्वान पर एक संरचित टूल त्रुटि के रूप में सामने आता है — सर्वर अभी भी टूल्स को सामान्य रूप से पंजीकृत और सूचीबद्ध करता है।

v3.0.0 में माइग्रेशन (क्रिया-आधारित टूल्स)

v3 ने 20 प्रति-क्रिया टूल्स को 8 क्रिया-आधारित टूल्स में समेकित किया। पुराना टूल → नया tool {action}:

हटाया गया	प्रतिस्थापन
search_projects	project {action:"get"} / project {action:"list"}
create_project	project {action:"create"}
update_project, delete_project	हटा दिया गया — DebuggAI वेब ऐप का उपयोग करें
search_environments	environment {action:"get"} / {action:"list"}
create_environment / update_environment / delete_environment	environment {action:"create"|"update"|"delete"}
create_test_suite / search_test_suites / run_test_suite / get_test_suite_results / delete_test_suite	test_suite {action:"create"|"list"|"run"|"results"|"delete"}
create_test_case / update_test_case / delete_test_case	test_case {action:"create"|"update"|"delete"}
search_executions	executions {action:"get"|"list"}
trigger_crawl headless पैरामीटर	हटा दिया गया — हमेशा हेडलेस

delete क्रियाओं के लिए अब पुष्टि आवश्यक है (एलिसिटेशन प्रॉम्प्ट, या confirm: true)। क्लाइंट MCP पुनरारंभ पर नई सतह उठाते हैं।

v1.x से माइग्रेशन (v2.0.0 में ब्रेकिंग परिवर्तन)

v2 ने 22-टूल सतह को 11 में समेट दिया। पुराना-टूल → नया-टूल मैपिंग:

हटाया गया	प्रतिस्थापन
list_projects, get_project	search_projects (uuid मोड बनाम फ़िल्टर मोड)
list_environments, get_environment	search_environments
list_credentials, get_credential	search_environments — क्रेडेंशियल्स प्रत्येक एन्वायरनमेंट पर इनलाइन
create_credential	create_environment({credentials: [...]}) सीड, या update_environment({addCredentials: [...]})
update_credential	update_environment({updateCredentials: [{uuid, ...patch}]})
delete_credential	update_environment({removeCredentialIds: [uuid]})
list_teams, list_repos	create_project({teamName, repoName}) — अस्पष्टता हैंडलिंग के साथ नाम समाधान
list_executions, get_execution	search_executions
cancel_execution	हटा दिया गया — बैकएंड स्पिन-डाउन स्वचालित है

प्रतिक्रिया-आकार परिवर्तन: सूची प्रतिक्रियाओं पर नंगे count फ़ील्ड चला गया है — pageInfo.totalCount का उपयोग करें।

कॉन्फ़िगरेशन

एन्वायरनमेंट वेरिएबल	आवश्यक	उद्देश्य
DEBUGGAI_API_KEY	हाँ	बैकएंड API कुंजी। उपनाम: DEBUGGAI_API_TOKEN, DEBUGGAI_JWT_TOKEN।
DEBUGGAI_API_URL	नहीं	बैकएंड बेस URL। डिफ़ॉल्ट https://api.debugg.ai है।
DEBUGGAI_TOKEN_TYPE	नहीं	token (डिफ़ॉल्ट) या bearer।
DEBUGGAI_EVAL_TEMPLATE	नहीं	App Evaluation वर्कफ़्लो slug को ओवरराइड करें जिस पर check_app_in_browser भेजता है। डिफ़ॉल्ट flow/e2es/app-eval है। डिस्पैच इस slug पर पिन करता है ताकि बैकएंड टेम्पलेट नाम बदलने से यह टूट न सके।
LOG_LEVEL	नहीं	error / warn / info (डिफ़ॉल्ट) / debug।
POSTHOG_API_KEY	नहीं	एम्बेडेड टेलीमेट्री प्रोजेक्ट कुंजी ओवरराइड करें (जैसे निजी फोर्क)।
DEBUGGAI_TELEMETRY_DISABLED	नहीं	टेलीमेट्री को पूरी तरह अक्षम करने के लिए 1 / true / yes / on पर सेट करें।

DEBUGGAI_API_KEY=your_api_key

रिमोट / HTTP ट्रांसपोर्ट (वैकल्पिक)

डिफ़ॉल्ट रूप से सर्वर stdio (स्थानीय npx) बोलता है। यह इसके बजाय एक होस्टेड, बहु-उपयोगकर्ता रिमोट MCP के रूप में स्टेटलेस स्ट्रीमेबल HTTP + OAuth पर चल सकता है:

DEBUGGAI_MCP_TRANSPORT=http PORT=3000 DEBUGGAI_TOKEN_TYPE=bearer npx -y @debugg-ai/debugg-ai-mcp@latest

यह एक OAuth संसाधन सर्वर है: हर POST /mcp को Authorization: Bearer <token> चाहिए; लापता/अमान्य टोकन को 401 मिलता है जिसमें एक WWW-Authenticate RFC 9728 मेटाडेटा की ओर इशारा करता है, और क्लाइंट विज्ञापित प्राधिकरण सर्वर के खिलाफ OAuth प्रवाह चलाते हैं। बियरर अनुरोध-स्कोप्ड है — api.debugg.ai इसे मान्य करता है।

एंडपॉइंट	उद्देश्य
POST /mcp	MCP स्ट्रीमेबल HTTP (बियरर-संरक्षित)
GET /.well-known/oauth-protected-resource	RFC 9728 मेटाडेटा (प्राधिकरण सर्वर खोज)
GET /health	लोड-बैलेंसर / ECS स्वास्थ्य जांच

एन्वायरनमेंट वेरिएबल	डिफ़ॉल्ट	उद्देश्य
DEBUGGAI_MCP_TRANSPORT	stdio	रिमोट ट्रांसपोर्ट के लिए http पर सेट करें
PORT	3000	HTTP सुनने का पोर्ट
DEBUGGAI_MCP_PUBLIC_URL	https://mcp.debugg.ai	इस सर्वर का सार्वजनिक संसाधन URL (RFC 9728 resource)
DEBUGGAI_OAUTH_ISSUER	https://auth.debugg.ai	क्लाइंट्स को विज्ञापित प्राधिकरण सर्वर
DEBUGGAI_TOKEN_TYPE	token	bearer पर सेट करें ताकि OAuth टोकन Authorization: Bearer के रूप में आगे बढ़ें

stdio इंस्टॉल को इनमें से किसी की आवश्यकता नहीं है।

बहु-प्रतिकृति तैनाती (रोलआउट से पहले गो/नो-गो): टनल स्थिति (ngrok सत्र टनल, इसका Caddy उदाहरण, और इसका पोर्ट-रूट लॉक) इन-प्रोसेस है, प्रति कॉलर बियरर टोकन के हैश द्वारा कुंजीबद्ध — कोई क्रॉस-प्रोसेस समन्वय नहीं है। एक सादे राउंड-रॉबिन लोड बैलेंसर के पीछे कई प्रतिकृति चलाने का मतलब है कि एक कॉलर के कॉल विभिन्न प्रतिकृतियों पर उतर सकते हैं और पूरे सत्र के लिए एक के बजाय प्रति प्रतिकृति एक टनल बना सकते हैं (अतिरिक्त ngrok लागत, प्रतिकृति संख्या से सीमित, मौजूदा 55-मिनट निष्क्रिय ऑटो-शटऑफ के माध्यम से स्व-उपचार — कभी क्रॉस-सत्र शुद्धता बग नहीं, क्योंकि कोई भी एकल टूल कॉल अपनी पूरी अवधि के लिए एक प्रतिकृति पर रहता है)। बहु-प्रतिकृति HTTP तैनाती पर इच्छित "प्रति सत्र एक टनल" व्यवहार पाने के लिए, लोड बैलेंसर पर सत्र-संबद्ध रूटिंग कॉन्फ़िगर करें (उसी पहचान पर स्टिकी/सुसंगत-हैश कुंजीबद्ध जिससे getSessionKey() प्राप्त होता है — व्यवहार में, कॉलर का Authorization बियरर टोकन)। पूर्ण तर्क और ईमानदार डिग्रेड पथ के लिए docs/local-tunnel-multiplexer-architecture-2026-07-31.md §2.1 देखें यदि यह कॉन्फ़िगर नहीं है।

टेलीमेट्री

MCP सर्वर डिफ़ॉल्ट रूप से सक्षम टेलीमेट्री के साथ आता है — एक एम्बेडेड केवल-लिखने योग्य PostHog प्रोजेक्ट कुंजी (phc_*) ताकि टीम इंस्टॉल बेस में कैश हिट दर, पोल कैडेंस, टनल विश्वसनीयता और अन्य परिचालन मेट्रिक्स का निरीक्षण कर सके। कैप्चर की गई घटनाएँ:

घटना	कब
tool.executed / tool.failed	प्रति टूल कॉल
workflow.executed	प्रति ब्राउज़र-एजेंट निष्पादन (pollCount, durationMs, finalIntervalMs ले जाता है)
tunnel.provisioned / tunnel.provision_retry / tunnel.stopped	प्रति टनल जीवनचक्र घटना
template.lookup / project.lookup	कोल्ड-कॉल पर durationMs के साथ कैश हिट/मिस

गोपनीयता रुख:

• विशिष्ट ID SHA-256(api_key).slice(0, 16) है — कभी कच्ची कुंजी नहीं, कोई PII नहीं।
• phc_* कुंजियाँ PostHog सम्मेलन द्वारा केवल-लिखने योग्य हैं; स्रोत में एम्बेड करना सुरक्षित है।
• पूरी तरह से ऑप्ट आउट करने के लिए DEBUGGAI_TELEMETRY_DISABLED=1 सेट करें (एक नो-ऑप प्रदाता को हल करता है; कोई घटना प्रक्रिया नहीं छोड़ती)।

सक्रिय मोड बूट पर लॉग किया जाता है:

Telemetry enabled (PostHog, DebuggAI default project). Set DEBUGGAI_TELEMETRY_DISABLED=1 to opt out.
Telemetry enabled (PostHog, custom POSTHOG_API_KEY)
Telemetry disabled (DEBUGGAI_TELEMETRY_DISABLED is set)

स्थानीय विकास

npm install
npm run build
npm run test:e2e        # real end-to-end evals against the backend

मूल्यांकन सूट निर्मित MCP सर्वर को एक उपप्रक्रिया के रूप में स्पॉन करता है, वास्तविक बैकएंड के खिलाफ हर टूल का अभ्यास करता है, और प्रति-प्रवाह आर्टिफैक्ट को scripts/evals/artifacts/<timestamp>/ में लिखता है। व्यक्तिगत परिदृश्यों के लिए scripts/evals/flows/ देखें।

MCP पंजीकरण: debugg-ai-local बनाम debugg-ai

यह रिपॉजिटरी एक .mcp.json भेजता है जो debugg-ai-local नामक प्रोजेक्ट-स्कोप्ड सर्वर को node dist/index.js की ओर इशारा करते हुए पंजीकृत करता है — ताज़ा-निर्मित स्थानीय कोड। यह केवल तब सक्रिय होता है जब Claude Code की कार्यशील निर्देशिका यह रिपॉजिटरी हो।

आपके अन्य प्रोजेक्ट्स को प्रकाशित npm पैकेज से खींचने वाले उपयोगकर्ता-स्कोप्ड debugg-ai पंजीकरण का उपयोग करना चाहिए:

npm run mcp:global      # registers debugg-ai in ~/.claude.json to npx -y @debugg-ai/debugg-ai-mcp

यहाँ कोड संपादित करने के बाद, npm run mcp:local चलाएँ (जो केवल पुनर्निर्माण करता है) ताकि debugg-ai-local का अगला आह्वान आपके परिवर्तनों को उठा सके।

लिंक

डैशबोर्ड · दस्तावेज़ · मुद्दे · डिस्कॉर्ड

---

Apache-2.0 लाइसेंस © 2025 DebuggAI