Debugg AI

Debugg AI — MCP सर्वर

Model Context Protocol के माध्यम से 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 के दौरान डाउनलोड करती है — सामान्य मामले में आपको स्वयं कुछ इंस्टॉल करने की आवश्यकता नहीं है। यह अब इस पैकेज द्वारा डाउनलोड की जाने वाली एकमात्र बाइनरी है; टनल क्लाइंट स्वयं शुद्ध TypeScript है — इसने ngrok पैकेज को बदल दिया, जो 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 स्वचालित रूप से debugg टनल सर्वर के माध्यम से टनल किए जाते हैं।

पैरामीटर	प्रकार	विवरण
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 सेट करें जब डिफ़ॉल्ट परीक्षण उपयोगकर्ता के लिए मौन फ़ॉलबैक जांच को अमान्य कर देगा।

क्रॉस-डोमेन SSO? एक रन केवल ऐप के अपने होस्ट और उसके सबडोमेन पर क्रेडेंशियल टाइप करता है; किसी अन्य डोमेन पर साइन-इन पेज को offscope_host के रूप में अस्वीकार कर दिया जाता है। पहचान प्रदाता के होस्ट को वातावरण के authorizedCredentialHosts में जोड़ें (देखें environment)।

ऐसा पेज जांच रहे हैं जिसे किसी लॉगिन की आवश्यकता नहीं है? 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 },
  { "username": "qatest123@example.com", "source": "env_default", "submitted": false, "authenticated": false,
    "reason": "offscope_host", "detail": "refused to enter credentials on auth.idp.example: not part of this run's scope …" }
],
"credentialWarning": {
  "requested": "qa+invitefix@example.com",
  "used": ["qatest123@example.com"]
}

source है task | explicit | credential_id (एक खाता जिसे आपने नाम दिया) या env | env_default (वातावरण का संग्रहीत खाता)। submitted केवल तभी सत्य है जब क्रेडेंशियल वास्तव में टाइप और सबमिट किए गए थे; reason बताता है कि क्या हुआ (जैसे offscope_host, restored_session), और detail, जब मौजूद हो, इसकी मानव-पठनीय व्याख्या है — offscope_host अस्वीकृति के लिए यह होस्ट का नाम और इसे अधिकृत करने का तरीका बताता है। 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.skipped === false के साथ {executionId, status, targetUrl, durationMs, outcome?, crawlSummary?, knowledgeGraph?, browserSession?} लौटाता है। crawlSummary और knowledgeGraph केवल उन कुंजियों को ले जाते हैं जिन्हें बैकएंड के क्रॉल / आयात नोड्स ने रिपोर्ट किया — एक लापता गिनती अनुपस्थित है, कभी भी भरा हुआ 0 नहीं। 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 लौटाएं (डिफ़ॉल्ट गलत)
captureScreenshots	बूलियन	प्रति लक्ष्य एक PNG लौटाएं (डिफ़ॉल्ट सत्य)

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

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

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?, authorizedCredentialHosts?}	निर्मित एनवी (वैकल्पिक रूप से क्रेडेंशियल्स सीड करता है)
update	{uuid, name?, url?, description?, addCredentials?, updateCredentials?, removeCredentialIds?, authorizedCredentialHosts?}	पैच किया गया एनवी; क्रेडेंशियल ऑपरेशन हटाएं → अपडेट करें → जोड़ें क्रम में चलते हैं
delete	{uuid, projectUuid?, confirm?}	एनवी हटाता है (क्रेडेंशियल्स कैस्केड करता है) — पुष्टि आवश्यक
sessions	{uuid, username?, credentialId?}	एनवी द्वारा धारित कैप्चर किए गए लॉगिन सत्र, प्रति खाता, प्रत्येक का अपना isUsable
clearSessions	{uuid, username?, credentialId?, confirm?}	उन्हें अमान्य करता है ताकि अगला रन वास्तव में लॉगिन करे — असीमित क्लियर के लिए पुष्टि आवश्यक

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

authorizedCredentialHosts उन होस्टों को सूचीबद्ध करता है जहां एक रन ऐप के अपने होस्ट के अलावा इस वातावरण के क्रेडेंशियल्स में प्रवेश कर सकता है — क्रॉस-डोमेन SSO के लिए, IdP होस्ट यहां जोड़ें (जैसे ["auth.example.com"])। केवल बेयर होस्टनाम: कोई स्कीम, पथ, पोर्ट या वाइल्डकार्ड नहीं (ऐप के होस्ट के सबडोमेन पहले से ही दायरे में हैं)। update पर यह सूची को प्रतिस्थापित करता है; [] इसे साफ़ करता है। get/list इसे लौटाते हैं जब सर्वर इसका समर्थन करता है। प्रतिक्रिया सहेजी गई सूची को प्रतिध्वनित करती है; यदि सर्वर ने इसे बनाए नहीं रखा (पुराने सर्वर फ़ील्ड को अनदेखा करते हैं), तो परिणाम मौन सफलता के बजाय authorizedCredentialHostsWarning: {requested, returned} ले जाता है।

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} के साथ सतह पर आता है। क्रेडेंशियल्स हमेशा पासवर्ड के बिना लौटाए जाते हैं।

पृष्ठांकन

हर list प्रतिक्रिया पृष्ठांकित है। प्रतिक्रिया आकार:

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

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

एक get अपने एकवचन नाम के तहत एक वस्तु लौटाता है — {project}, {execution}, {project, environment} — बिना किसी pageInfo के।

संसाधन

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

v6.0.0 में प्रवासन (बैकएंड निर्णय, कोई MCP-लेखित पाठ नहीं)

एक रन निर्णय pass | fail | error है, बैकएंड के reason के साथ शब्दशः रिले किया गया। एक रन जिसने कभी परीक्षण का प्रयास नहीं किया वह outcome: null, skipped: true, skipReason पढ़ता है।

हटाया गया	प्रतिस्थापन
success	outcome
failureCategory	outcome + reason
stepsTaken / stepsBudget / stepsRemaining	budget: {maxSteps, usedSteps}
failedNode	errorInfo
get → projects[0] / executions[0] / environments[0] + pageInfo + filter	{project} / {execution} / {project, environment}
message / note चेतावनियों और परिणामों पर	केवल संरचित फ़ील्ड

पूरी सूची: CHANGELOG.md 6.0.0।

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	नहीं	ऐप मूल्यांकन वर्कफ़्लो 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 मिलता है जिसमें RFC 9728 मेटाडेटा की ओर इशारा करते हुए WWW-Authenticate होता है, और क्लाइंट विज्ञापित प्राधिकरण सर्वर के खिलाफ 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 इंस्टॉल को इनमें से किसी की आवश्यकता नहीं है।

बहु-प्रतिकृति तैनाती (रोलआउट से पहले जाओ/नहीं-जाओ): टनल स्थिति (सत्र टनल, इसका Caddy उदाहरण, और इसका पोर्ट-रूट लॉक) इन-प्रोसेस है, प्रति कॉलर बेयरर टोकन के हैश द्वारा कुंजीबद्ध — कोई क्रॉस-प्रोसेस समन्वय नहीं है। एक सादे राउंड-रॉबिन लोड बैलेंसर के पीछे कई प्रतिकृति चलाने का मतलब है कि एक कॉलर के कॉल विभिन्न प्रतिकृति पर उतर सकते हैं और पूरे सत्र के लिए एक के बजाय प्रति प्रतिकृति जो वे हिट करते हैं एक टनल बना सकते हैं (प्रतिकृति गिनती से बाध्य, मौजूदा 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 का अगला आह्वान आपके परिवर्तनों को उठा सके।

लिंक

Dashboard · Docs · Issues · Discord

---

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