Debugg AI

ทางการ

เปิดให้เอเจนต์สร้างโค้ดของคุณสามารถสร้างและรันการทดสอบแบบ end-to-end ที่ไม่ต้องกำหนดค่าใดๆ กับการเปลี่ยนแปลงโค้ดใหม่ในเบราว์เซอร์ระยะไกลผ่านแพลตฟอร์มทดสอบของ Debugg AI

GitHub
68
ลองใช้ MCP นี้ผู้สนับสนุน

คุณทำอะไรได้บ้างด้วย Debugg AI MCP?

  • รันการทดสอบ AI บนเบราว์เซอร์ — ขอให้ผู้ช่วย check_app_in_browser กับ URL ใดๆ หรือ localhost โดยอธิบายสิ่งที่ต้องการทดสอบเป็นภาษาธรรมชาติ และรับผลผ่าน/ไม่ผ่านพร้อมภาพหน้าจอ
  • ตรวจสอบหลายเพจอย่างรวดเร็ว — ใช้ probe_page เพื่อตรวจสอบแบบกลุ่ม 1–20 URL สำหรับข้อผิดพลาดคอนโซล ปัญหาเครือข่าย และสถานะการเรนเดอร์ โดยไม่มีค่าใช้จ่าย LLM หรือลูปเอเจนต์
  • เรียกใช้การรวบรวมความรู้กราฟ — เรียก trigger_crawl เพื่อเริ่มการรวบรวมข้อมูลฝั่งเซิร์ฟเวอร์ด้วยเบราว์เซอร์เอเจนต์ ซึ่งเติมข้อมูลลงในความรู้กราฟของโปรเจกต์ด้วยอาร์ติแฟกต์ HAR และบันทึกคอนโซล
  • จัดการชุดทดสอบและกรณีทดสอบ — สร้าง รัน และตรวจสอบผลลัพธ์สำหรับเอนทิตี test_suite และ test_case พร้อมผลลัพธ์ต่อการทดสอบและอัตราผ่าน
  • ตรวจสอบอาร์ติแฟกต์การดำเนินการ — ดึงรายละเอียดการดำเนินการทั้งหมดผ่าน executions รวมถึงภาพหน้าจอ ร่องรอยเครือข่าย HAR และบันทึกคอนโซลเพื่อดีบักปัญหาที่เกิดขึ้นระหว่างรันไทม์
  • จัดการสภาพแวดล้อมและเซสชัน — สร้างหรืออัปเดตสภาพแวดล้อมด้วยข้อมูลรับรองผ่าน environment และใช้ sessions/clearSessions เพื่อควบคุมการนำเซสชันล็อกอินแบบอุ่นกลับมาใช้ใหม่

เอกสาร

Debugg AI — MCP Server

การทดสอบเบราว์เซอร์ที่ขับเคลื่อนด้วย AI ผ่าน Model Context Protocol ชี้ไปที่ URL ใดก็ได้ (หรือ localhost) และอธิบายสิ่งที่ต้องการทดสอบ — เอเจนต์ AI จะเรียกดูแอปของคุณและส่งคืนผลผ่าน/ไม่ผ่านพร้อมภาพหน้าจอ

Debugg AI MCP server

การตั้งค่า

ต้องใช้ Node.js 20.20.0 หรือใหม่กว่า (ข้อกำหนดที่สืบทอดมาจาก posthog-node@^5.26.0)

การทดสอบ URL ของ http://localhost:... ต้องใช้ไบนารี caddycheck_app_in_browser, probe_page, และ trigger_crawl ทันเนลเป้าหมาย localhost ผ่านพร็อกซีรีเวิร์ส Caddy ในเครื่อง สิ่งนี้ติดตั้งโดยอัตโนมัติ: การพึ่งพา npm ของ @radically-straightforward/caddy จะดาวน์โหลด Caddy รุ่นที่ปักหมุดไว้สำหรับแพลตฟอร์มของคุณระหว่าง npm install/npx เช่นเดียวกับที่โปรเจกต์นี้ ทำกับไบนารี ngrok อยู่แล้ว — ไม่ต้องติดตั้งอะไรด้วยตัวเองในกรณีปกติ หากการดาวน์โหลดนั้น ไม่เคยทำงาน (npm install --ignore-scripts, การติดตั้งแบบออฟไลน์/แยกเครือข่าย) ให้ชี้ CADDY_BIN ไปที่ การติดตั้งของคุณเอง (brew install caddy / apt install caddy / ดู caddyserver.com/docs/install) — การขาดมันจะแสดงเป็น ข้อผิดพลาดที่ชัดเจนในการเรียก URL localhost ครั้งแรก ไม่ใช่การค้างเงียบ ๆ การเรียก URL สาธารณะ เครื่องมือที่ไม่ใช่เบราว์เซอร์ทุกตัว และ test_suite {action:"run"} (ซึ่งใช้ทันเนลเฉพาะของตัวเองและ บายพาส Caddy ทั้งหมด) ไม่จำเป็นต้องใช้มันไม่ว่าจะกรณีใด

รับคีย์ API ที่ debugg.ai จากนั้นเพิ่มลงในการกำหนดค่า MCP client ของคุณ:

{
  "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

ขั้นตอน npm install ของ Dockerfile จะดึง caddy ด้วยวิธีอัตโนมัติเดียวกันกับการติดตั้งในเครื่อง ในหลักการ — แต่ ณ เวลาที่เขียนนี้ Dockerfile ไม่ได้ COPY หลายไดเรกทอรีที่ การ build ต้องการตอนนี้ (handlers, tools, types, config) และยังอ้างอิงไดเรกทอรี tunnels/ ที่ไม่มีอยู่อีกต่อไป ดังนั้นการ build ใหม่จึงอาจล้มเหลวก่อนที่เรื่องนั้นจะสำคัญ นั่นคือ ช่องว่างที่มีอยู่ก่อนแล้ว ไม่เกี่ยวข้องกับ Caddy อิมเมจ quinnosha/debugg-ai-mcp ที่ เผยแพร่ในปัจจุบัน มีมาก่อนการพึ่งพา Caddy ไม่ว่าจะกรณีใด — การเรียก URL localhost ไปยัง check_app_in_browser/probe_page/trigger_crawl จะล้มเหลวด้วย CaddyBinaryNotFoundError ภายในอิมเมจนั้นจนกว่าจะ build ใหม่ (แก้ไข 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 กับแอปของคุณ เอเจนต์จะนำทาง โต้ตอบ และรายงานกลับพร้อมภาพหน้าจอ URL localhost จะถูกทันเนลอัตโนมัติผ่าน ngrok

พารามิเตอร์ชนิดคำอธิบาย
descriptionstring จำเป็นสิ่งที่ต้องการทดสอบ (ภาษาธรรมชาติ)
urlstring จำเป็นURL เป้าหมาย — http://localhost:3000 ถูกทันเนลอัตโนมัติ
environmentIdstringUUID ของสภาพแวดล้อมเฉพาะ
credentialIdstringUUID ของข้อมูลประจำตัวเฉพาะ
credentialRolestringเลือกข้อมูลประจำตัวตามบทบาท (เช่น admin, guest)
usernamestringชื่อผู้ใช้สำหรับเข้าสู่ระบบ (ชั่วคราว — ไม่ถูกบันทึก)
passwordstringรหัสผ่านสำหรับเข้าสู่ระบบ (ชั่วคราว — ไม่ถูกบันทึก)
loginCredentialsarrayบัญชีสำหรับการเข้าสู่ระบบที่เอเจนต์พบ ระหว่าง งาน — [{username, password, label?}]
useEnvironmentCredentialsbooleanค่าเริ่มต้น true false ห้ามการกรอกอัตโนมัติของข้อมูลประจำตัวที่เก็บไว้ของสภาพแวดล้อม; หากไม่มีบัญชีที่ระบุหมายความว่า อย่าเข้าสู่ระบบเลย
freshSessionbooleanค่าเริ่มต้น false true บังคับให้เข้าสู่ระบบจริงแทนการใช้เซสชันอุ่นที่เก็บไว้สำหรับบัญชีนั้น
authobjectเงื่อนไขก่อนการตรวจสอบสิทธิ์ — {precondition, entryUrl, deepUrl, environmentId, username, password}
repoNamestringแทนที่ชื่อ repo 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 พร้อมกับภาพหน้าจอ — URL S3 ที่ลงนามล่วงหน้าสำหรับ HAR ที่จับได้ (ร่องรอยเครือข่ายเต็ม) และ บันทึกคอนโซล (ทุกข้อความ JS console) ใช้เพื่อตรวจจับลูปการดึงข้อมูลซ้ำ ข้อผิดพลาด hydration และปัญหารันไทม์อื่น ๆ ที่ผ่านการตรวจสอบชนิดและหน่วยทดสอบ:

"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 เพราะการอัปโหลดจับเกิดขึ้นแบบอะซิงโครนัสหลังจากเอเจนต์เสร็จ — โพล executions {action:"get", uuid: executionId} จนกว่าสถานะจะถึง 'downloaded' ส่วนหัว Authorization / Cookie / token/secret/api_key ถูกกำจัดฝั่งเซิร์ฟเวอร์ก่อนที่อาร์ติแฟกต์จะถูกบันทึก

trigger_crawl

ยิงการรวบรวมข้อมูลเอเจนต์เบราว์เซอร์ฝั่งเซิร์ฟเวอร์เพื่อเติมกราฟความรู้ของโปรเจกต์ URL localhost ถูกทันเนลอัตโนมัติ ส่งคืน {executionId, status, targetUrl, durationMs, outcome?, crawlSummary?, knowledgeGraph?, browserSession?} ด้วย knowledgeGraph.imported === true ในการรับข้อมูลที่สำเร็จ บล็อก browserSession (URL HAR + บันทึกคอนโซล รูปแบบเดียวกับด้านบน) ก็มีอยู่ในการรวบรวมข้อมูลที่เสร็จสมบูรณ์

probe_page

การตรวจสอบหน้าแบบกลุ่มที่ไม่มี LLM และมีน้ำหนักเบา ส่ง 1-20 URL; แต่ละรายการนำทาง รอให้เนื้อหาคงที่ (DOM เงียบลง จำกัดขอบเขต — ไม่เคยรอความเงียบของเครือข่าย ซึ่งแอปสดไม่มีวันถึง) และส่งคืนสถานะที่เรนเดอร์ — ภาพหน้าจอ + เมตาดาต้าหน้า + ข้อผิดพลาดคอนโซลที่มีโครงสร้าง + สรุปเครือข่าย ไม่มีลูปเอเจนต์ ไม่มีค่าใช้จ่าย LLM ไม่มีการยืนยันสถานการณ์ ใช้สำหรับ "ฉันเพิ่งทำ /settings/ พังหรือเปล่า?", การตรวจสอบหลายเส้นทางหลังการรีแฟกเตอร์, การกวาด CI ต่อ PR และการตรวจสอบว่าเว็บขึ้นหรือไม่ที่ลูปเอเจนต์ 60-150 วินาทีของ check_app_in_browser มากเกินไป

พารามิเตอร์ชนิดคำอธิบาย
targetsarray จำเป็น1-20 รายการ: [{url, waitForSelector?, waitForLoadState?, timeoutMs?}]
targets[].urlstring จำเป็นURL สาธารณะหรือ localhost (ทันเนลอัตโนมัติ)
targets[].waitForLoadStateenum'domcontentloaded' (ค่าเริ่มต้น + การรอเนื้อหาคงที่แบบจำกัด) / 'load' (ยังบล็อก embeds ของบุคคลที่สาม) / 'networkidle' (ยอมรับ ไม่เคยออก — เครือข่ายของเว็บสดไม่เคยว่าง)
targets[].waitForSelectorstringตัวเลือก CSS selector ที่จะรอหลังการนำทาง
targets[].timeoutMsnumberหมดเวลาต่อ URL, 1000-30000 (ค่าเริ่มต้น 10000)
includeHtmlbooleanส่งคืน HTML ดิบในแต่ละผลลัพธ์ (ค่าเริ่มต้น false)
captureScreenshotsbooleanส่งคืน PNG หนึ่งตัวต่อเป้าหมาย (ค่าเริ่มต้น true)

เป้าหมายทั้งหมดในชุดใช้ทันเนลเซสชันเดียวร่วมกัน แต่ชุดที่พอร์ตเดียวกันเท่านั้น (หรือสาธารณะทั้งหมด) ใช้การรันแบ็กเอนด์ เดียว ร่วมกัน — 5 URL บนพอร์ตเดียวในการเรียกเดียวเร็วกว่าการเรียก URL เดียว 5 ครั้งแบบขนานอย่างมาก ชุดที่ผสมพอร์ต local หลายพอร์ตจะแยกเป็นการรันแบ็กเอนด์ตามลำดับหนึ่งครั้งต่อกลุ่มพอร์ต (ยังเป็นการเรียกเดียว ยังเป็น results[] ที่รวมกันหนึ่งรายการในลำดับเดิมของคุณ แต่มีการไปกลับแบ็กเอนด์ N ครั้งแทนหนึ่งครั้ง — ช้ากว่า ไม่ถูกปฏิเสธ) ฟิลด์ error ต่อ URL รักษาความยืดหยุ่นของชุด: เป้าหมายเดียวที่ล้มเหลวไม่ทำให้ตัวอื่นล้มเหลว

คีย์การรวม networkSummary คือ origin + pathname — ลูปการดึงข้อมูลซ้ำ (?n=0..4 ตี endpoint เดียวกันซ้ำ ๆ) ยุบเป็นรายการเดียวพร้อมจำนวน ดังนั้น /api/poll ที่ปรากฏด้วย count: 47 คือสัญญาณ "ลูปการดึงข้อมูลซ้ำไม่สิ้นสุด" ที่ผู้ใช้ขอไว้แต่แรก

งบประมาณประสิทธิภาพ: <10 วินาทีสำหรับ 1 URL, <25 วินาทีสำหรับ 20 พอร์ตที่ตายของ localhost ส่งคืน LocalServerUnreachable ใน <2 วินาทีโดยไม่เผาการรันเวิร์กโฟลว์

project

การกระทำพารามิเตอร์ผลลัพธ์
get{uuid}รายละเอียดโปรเจกต์ที่คัดสรร
list{q?, page?, pageSize?}สรุปแบบแบ่งหน้า
create{name, platform, (teamUuid|teamName), (repoUuid|repoName)}โปรเจกต์ที่สร้าง

ทีมและ repo ถูกแก้โดย 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 จัดการเซสชันที่รับรองความถูกต้องแบบอุ่นที่แบ็กเอนด์นำกลับมาใช้ใหม่เพื่อข้ามการเข้าสู่ระบบ (ดู การนำเซสชันกลับมาใช้ใหม่) เนื้อหาเซสชันจะไม่ถูกส่งคืน — คุกกี้เซสชันคือข้อมูลประจำตัวแบบ bearer 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) ถูกตัดออกจากการตอบสนองของเอเจนต์เบราว์เซอร์ทั้งหมด รวมถึงข้อความที่เอเจนต์เขียน
  • 404 จากแบ็กเอนด์แสดงเป็น isError: true พร้อม {error: 'NotFound', ...} ไม่ใช่ข้อยกเว้นที่ถูกโยน
  • การขาด DEBUGGAI_API_KEY แสดงเป็นข้อผิดพลาดเครื่องมือที่มีโครงสร้างในการเรียกครั้งแรก — เซิร์ฟเวอร์ยังคงลงทะเบียนและแสดงรายการเครื่องมือตามปกติ

การย้ายไปยัง v3.0.0 (เครื่องมือแบบการดำเนินการ)

v3 รวมเครื่องมือ 20 รายการต่อคำกริยาเป็นเครื่องมือแบบการดำเนินการ 8 รายการ เครื่องมือเก่า → tool {action} ใหม่:

ถูกลบสิ่งแทนที่
search_projectsproject {action:"get"} / project {action:"list"}
create_projectproject {action:"create"}
update_project, delete_projectถูกลบ — ใช้เว็บแอป DebuggAI
search_environmentsenvironment {action:"get"} / {action:"list"}
create_environment / update_environment / delete_environmentenvironment {action:"create"|"update"|"delete"}
create_test_suite / search_test_suites / run_test_suite / get_test_suite_results / delete_test_suitetest_suite {action:"create"|"list"|"run"|"results"|"delete"}
create_test_case / update_test_case / delete_test_casetest_case {action:"create"|"update"|"delete"}
search_executionsexecutions {action:"get"|"list"}
trigger_crawl พารามิเตอร์ headlessถูกลบ — เป็นแบบ headless เสมอ

การดำเนินการ delete ต้องยืนยันแล้ว (พรอมต์การสอบถาม หรือ confirm: true) ไคลเอนต์รับพื้นผิวใหม่เมื่อรีสตาร์ท MCP

การย้ายจาก v1.x (การเปลี่ยนแปลงที่ทำลายใน v2.0.0)

v2 รวมพื้นผิว 22 เครื่องมือเป็น 11 รายการ การแมปเครื่องมือเก่า → เครื่องมือใหม่:

ถูกลบสิ่งแทนที่
list_projects, get_projectsearch_projects (โหมด uuid เทียบกับโหมดตัวกรอง)
list_environments, get_environmentsearch_environments
list_credentials, get_credentialsearch_environments — ข้อมูลประจำตัวแบบอินไลน์ในแต่ละสภาพแวดล้อม
create_credentialcreate_environment({credentials: [...]}) seed หรือ update_environment({addCredentials: [...]})
update_credentialupdate_environment({updateCredentials: [{uuid, ...patch}]})
delete_credentialupdate_environment({removeCredentialIds: [uuid]})
list_teams, list_reposcreate_project({teamName, repoName}) — การแก้ไขชื่อพร้อมการจัดการความคลุมเครือ
list_executions, get_executionsearch_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 เวิร์กโฟลว์ App Evaluation ที่ check_app_in_browser ส่งไป ค่าเริ่มต้นคือ flow/e2es/app-eval การส่งจะยึดกับ slug นี้เพื่อให้การเปลี่ยนชื่อเทมเพลตแบ็กเอนด์ไม่ทำให้เสียหาย
LOG_LEVELไม่error / warn / info (ค่าเริ่มต้น) / debug
POSTHOG_API_KEYไม่แทนที่คีย์โปรเจกต์เทเลเมทรีที่ฝังไว้ (เช่น fork ส่วนตัว)
DEBUGGAI_TELEMETRY_DISABLEDไม่ตั้งเป็น 1 / true / yes / on เพื่อปิดเทเลเมทรีทั้งหมด
DEBUGGAI_API_KEY=your_api_key

การขนส่งระยะไกล / HTTP (ไม่บังคับ)

โดยค่าเริ่มต้น เซิร์ฟเวอร์พูด stdio (npx ในเครื่อง) สามารถรันเป็น MCP ระยะไกลแบบผู้ใช้หลายคนที่โฮสต์ผ่าน Streamable HTTP แบบไร้สถานะ + OAuth:

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

เป็น OAuth Resource Server: ทุก POST /mcp ต้องมี Authorization: Bearer <token>; โทเค็นที่ขาด/ไม่ถูกต้องจะได้รับ 401 พร้อม WWW-Authenticate ชี้ไปที่เมตาดาต้า RFC 9728 และไคลเอนต์รันโฟลว์ OAuth กับเซิร์ฟเวอร์อนุญาตที่โฆษณา bearer เป็นแบบขอบเขตคำขอ — api.debugg.ai ตรวจสอบ

ปลายทางวัตถุประสงค์
POST /mcpMCP Streamable HTTP (ป้องกันด้วย bearer)
GET /.well-known/oauth-protected-resourceเมตาดาต้า RFC 9728 (การค้นพบเซิร์ฟเวอร์อนุญาต)
GET /healthการตรวจสอบสุขภาพโหลดบาลานเซอร์ / ECS
ตัวแปรสภาพแวดล้อมค่าเริ่มต้นวัตถุประสงค์
DEBUGGAI_MCP_TRANSPORTstdioตั้งเป็น http สำหรับการขนส่งระยะไกล
PORT3000พอร์ตฟัง HTTP
DEBUGGAI_MCP_PUBLIC_URLhttps://mcp.debugg.aiURL ทรัพยากรสาธารณะของเซิร์ฟเวอร์นี้ (RFC 9728 resource)
DEBUGGAI_OAUTH_ISSUERhttps://auth.debugg.aiเซิร์ฟเวอร์อนุญาตที่โฆษณาให้ไคลเอนต์
DEBUGGAI_TOKEN_TYPEtokenตั้งเป็น bearer เพื่อให้โทเค็น OAuth ส่งต่อเป็น Authorization: Bearer

การติดตั้ง stdio ไม่จำเป็นต้องใช้สิ่งเหล่านี้

การปรับใช้หลายเรพลิกา (go/no-go ก่อนเปิดตัว): สถานะอุโมงค์ (เซสชันอุโมงค์ ngrok, อินสแตนซ์ Caddy และล็อกพอร์ต-รูท) อยู่ในกระบวนการ คีย์ต่อผู้เรียกโดยแฮชของ โทเค็น bearer — ไม่มีการประสานงานข้ามกระบวนการ การรันหลายเรพลิกาหลังโหลดบาลานเซอร์ แบบ round-robin ธรรมดาหมายความว่าการเรียกของผู้เรียกหนึ่งรายอาจไปยังเรพลิกาต่างกันและสร้างอุโมงค์ ต่อเรพลิกาที่พวกเขาเข้าถึง แทนที่จะเป็นหนึ่งสำหรับทั้งเซสชัน (ค่าใช้จ่าย ngrok เพิ่มเติม จำกัดด้วย จำนวนเรพลิกา รักษาตัวเองผ่านการปิดอัตโนมัติเมื่อไม่ได้ใช้งาน 55 นาที — ไม่เคยเป็นบั๊กความถูกต้อง ข้ามเซสชัน เนื่องจากการเรียกเครื่องมือใด ๆ อยู่บนเรพลิกาเดียวตลอดระยะเวลา) เพื่อให้ได้ พฤติกรรม "หนึ่งอุโมงค์ต่อเซสชัน" ที่ตั้งใจไว้บนการปรับใช้ HTTP หลายเรพลิกา กำหนดค่า การกำหนดเส้นทางแบบยึดเซสชัน ที่โหลดบาลานเซอร์ (sticky/consistent-hash คีย์บนข้อมูลประจำตัวเดียวกัน ที่ getSessionKey() อนุมาน — ในทางปฏิบัติ โทเค็น bearer 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 เพื่อเลือกไม่ใช้ทั้งหมด (แก้เป็นผู้ให้บริการ no-op ไม่มีเหตุการณ์ออกจากกระบวนการ)

โหมดที่ใช้งานจะถูกบันทึกที่บูต:

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 คือที่เก็บนี้

โปรเจกต์อื่นของคุณควรใช้การลงทะเบียน debugg-ai ขอบเขตผู้ใช้ ที่ดึงจากแพ็กเกจ npm ที่เผยแพร่:

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