bugAgent

Connect bug Agent เข้ากับ AI client ที่รองรับ MCP ใดก็ได้

จัดการไฟล์ จำแนกประเภท และจัดการบั๊ก คำขอฟีเจอร์ และอื่นๆ ได้โดยตรงจาก AI coding assistant ของคุณ ไม่ต้องสลับบริบท ไม่ต้องคัดลอกและวาง — เพียงอธิบายปัญหา แล้ว bug Agent จะจัดการส่วนที่เหลือให้

MCP clients ภายนอกแยกจาก AI Assistant ใน dashboard ของ bug Agent โดย assistant ใน dashboard ถูกปิดไว้เป็นค่าเริ่มต้นในทุกแผน และต้องเปิดใช้งานอย่างชัดเจนใน workspace; เกต ai_assistant ของมันไม่ได้ปิดการใช้งาน MCP หรือ integrations การรับรองความถูกต้องของ MCP ขอบเขตสิทธิ์ การอนุญาต workspace/project และสิทธิ์เฉพาะเครื่องมือยังคงมีผลบังคับใช้

เริ่มต้นใช้งาน

bug Agent รัน hosted MCP server เพื่อให้ AI clients สามารถสร้าง ค้นหา และจัดการรายงานบั๊ก คำขอฟีเจอร์ การปรับปรุง และอื่นๆ ผ่าน Model Context Protocol Clients เชื่อมต่อโดยตรงกับ hosted Streamable HTTP endpoint

รับ API key ของคุณ

สร้างบัญชีฟรี; เจ้าของ workspace ใหม่จะถูกนำไปที่การตั้งค่า API key โดยตรง ผู้ใช้ที่กลับมาสามารถสร้าง key ได้จาก Settings → Developers → API Keys

กำหนดค่า AI client ของคุณ

เพิ่ม bug Agent เป็น MCP server ในการกำหนดค่าของ client (ดูขั้นตอนการตั้งค่าด้านล่าง)

เริ่มไฟล์บั๊ก

อธิบายบั๊กด้วยภาษาธรรมชาติ แล้ว bug Agent จะจำแนกประเภท เพิ่มข้อมูล และจัดเก็บให้อัตโนมัติ

# Create a bug report
"File a bug: Login button is unresponsive on iOS Safari.
Steps: tap login, nothing happens. Expected: navigate to
dashboard. Severity: high."

# bugAgent auto-classifies as UI bug, severity high

# File a feature request
"Feature request: Add dark mode toggle to the
settings page. Users have asked for this in surveys."

# Auto-classified as feature-request, severity medium

การตั้งค่า

แนะนำ: hosted Streamable HTTP

เชื่อมต่อโดยตรงกับ https://mcp.bugagent.com/mcp ไม่ต้องติดตั้งหรือรันอะไรในเครื่อง เพิ่ม workspace API key ของคุณเป็น bearer token:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

💡

แทนที่ ba_live_YOUR_KEY_HERE ด้วย API key จริงของคุณจาก Settings → Developers

สะพาน stdio (ไม่บังคับ)

ใช้ published bridge เฉพาะเมื่อ client ต้องการ stdio และไม่สามารถเชื่อมต่อกับ remote HTTP server ได้ รันตามความต้องการด้วย npx -y bugagent-mcp:

{
  "mcpServers": {
    "bugagent": {
      "command": "npx",
      "args": ["-y", "bugagent-mcp"],
      "env": {
        "BUGAGENT_API_KEY": "ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

เชื่อมต่อกับเซิร์ฟเวอร์

MCP server ของ bug Agent ทำงานอยู่ที่ https://mcp.bugagent.com/mcp ผ่าน Streamable HTTP transport เชื่อมต่อจากแปด clients ด้านล่าง — เลือกอันที่เหมาะกับขั้นตอนการทำงานของคุณ

สำหรับการกำหนดค่าขนาดเล็กที่พร้อมคัดลอก คำแนะนำเกี่ยวกับ scoped-key และ starter prompts ที่ปลอดภัย ใช้ MCP quickstart สาธารณะ

🔑

รับ API key ของคุณก่อน ลงชื่อเข้าใช้ Settings → Developers คลิก Create API Key เลือกขอบเขตที่ client ของคุณต้องการ แล้วคัดลอกค่า (ขึ้นต้นด้วย ba_live_) คุณจะเห็นมันเพียงครั้งเดียว ดังนั้นวางไว้ในที่ปลอดภัย MCP clients จะแสดงเฉพาะเครื่องมือที่ได้รับอนุญาตตามขอบเขตเหล่านั้น ตัวอย่างการเชื่อมต่อด้านล่างใช้ key นี้; พรอมต์ที่ต้องใช้ OAuth/session แบบโต้ตอบหรือสิทธิ์ตามแผนแบบชำระเงินจะระบุแยกต่างหาก

ตัวเลือก 1 — MCP Inspector (Web UI, แนะนำสำหรับการทดสอบครั้งแรก)

เครื่องมืออย่างเป็นทางการของ Anthropic เปิด web UI ในเครื่องที่คุณสามารถคลิกผ่านทุกเครื่องมือ กรอกพารามิเตอร์ และดูการตอบสนอง ไม่ต้องกำหนดค่า ไม่ต้องใช้ IDE

macOS (Terminal)

npx @modelcontextprotocol/inspector

Windows (PowerShell หรือ CMD)

npx @modelcontextprotocol/inspector

ใน browser UI ที่เปิดขึ้น:

1. Transport Type: เลือก Streamable HTTP
2. URL: https://mcp.bugagent.com/mcp
3. Connection Type: เลือก Proxy (ค่าเริ่มต้น — Inspector พร็อกซีผ่าน local Node process เพื่อเลี่ยง CORS ของเบราว์เซอร์)
4. เปิด Server Settings → Custom Headers และเพิ่ม:
   • Header Name: X-Api-Key
     • Value: ba_live_YOUR_KEY_HERE (ไม่มีคำนำหน้า Bearer)
5. คลิก Connect แผงด้านซ้ายแสดงรายการเครื่องมือ bug Agent ที่อนุญาตตามขอบเขต API key ที่คุณเลือก
6. คลิกเครื่องมือใดก็ได้ (เช่น list_bug_reports) กรอกพารามิเตอร์ คลิก Run Tool การตอบสนองจะแสดงทางด้านขวา

ข้อกำหนดเบื้องต้น: MCP Inspector v2 ต้องใช้ Node.js 22.19 หรือใหม่กว่า ติดตั้ง Node.js เวอร์ชันปัจจุบันจาก nodejs.org หากคุณยังไม่มี

หาก Inspector คืนค่า invalid_client แสดงว่ากำลังพยายามใช้การเชื่อมต่อ OAuth ที่บันทึกไว้แทนการรับรองความถูกต้องด้วย API key ลบเซิร์ฟเวอร์ที่บันทึกไว้ (หรือล้างสถานะ OAuth ที่เก็บไว้) เพิ่มใหม่อีกครั้ง และใช้ custom header X-Api-Key ด้านบน อย่าใส่ key ba_live_ ในฟิลด์ OAuth client_id

ตัวเลือก 2 — Claude Desktop (Mac + Windows)

หากคุณใช้แอป Claude Desktop คุณสามารถเพิ่ม bug Agent เป็น MCP server ถาวรได้ ด้วย workspace API key Claude จะได้รับเฉพาะเครื่องมือที่อนุญาตตามขอบเขตของ key นั้น Delegated OAuth จะแสดงแคตตาล็อกแบบโต้ตอบทั้งหมด

macOS

1. เปิด Claude Desktop → แถบเมนู Claude → Settings → Developer → Edit Config ซึ่งจะเปิด ~/Library/Application Support/Claude/claude_desktop_config.json
2. เพิ่มรายการ bug Agent ภายใต้ mcpServers:

   {
     "mcpServers": {
       "bugagent": {
         "type": "http",
         "url": "https://mcp.bugagent.com/mcp",
         "headers": {
           "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
         }
       }
     }
   }
   

3. บันทึกไฟล์และ ออกจาก Claude Desktop โดยสมบูรณ์ (Cmd+Q ไม่ใช่แค่ปิดหน้าต่าง)
4. เปิด Claude Desktop ใหม่ ไอคอนค้อนเครื่องมือที่ด้านล่างของช่องป้อนแชทควรแสดงเครื่องมือ bug Agent แล้ว
5. ลองใช้: พิมพ์ "List my 5 most recent bug reports" — Claude จะเรียก list_bug_reports โดยอัตโนมัติ

Windows

1. เปิด Claude Desktop → File → Settings → Developer → Edit Config ซึ่งจะเปิด %APPDATA%\Claude\claude_desktop_config.json (โดยทั่วไปคือ C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json)
2. เพิ่มบล็อก JSON เดียวกับที่แสดงในส่วน macOS
3. บันทึกไฟล์และ ออกจาก Claude Desktop โดยสมบูรณ์ จาก system tray (คลิกขวาที่ไอคอน Claude → Quit) แล้วเปิดใหม่
4. ไอคอนค้อนเครื่องมือจะแสดงเครื่องมือ bug Agent

ตัวเลือก 3 — Claude Code (CLI)

หากคุณใช้ Claude Code จากเทอร์มินัล (เวอร์ชัน CLI ของ Claude) ลงทะเบียนเซิร์ฟเวอร์ bug Agent ด้วยคำสั่งเดียว ทำงานเหมือนกันบน macOS, Linux และ Windows

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp \
  --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

จากนั้นรีสตาร์ทเซสชัน Claude Code ของคุณ ตรวจสอบว่ามีการเชื่อมต่อ:

claude mcp list

คุณควรเห็น bugagent ในรายการพร้อมจุดสีเขียว เริ่มต้นด้วยพรอมต์ที่เข้ากันได้กับ API key: "List my 5 most recent open bug reports."

เชื่อมต่อแล้ว แต่เครื่องมือบางอย่างหายไป?

ตรวจสอบจำนวนเครื่องมือของเซิร์ฟเวอร์ใน /mcp ไม่ใช่แค่เครื่องมือที่โหลดในบทสนทนาแล้ว Claude Code สามารถค้นพบเครื่องมือตามความต้องการโดยใช้การค้นหาเครื่องมือ ขอให้ค้นหา bugAgent สำหรับ list_test_cases, list_test_suites หรือ get_test_run_plan ดู เอกสารการค้นหาเครื่องมือของ Claude Code

แคตตาล็อกถูกกรองตามขอบเขต API key การอ่าน test-case ต้องใช้ test_cases:read; การอ่าน suite/run ต้องใช้ test_runs:read ขอเฉพาะ write scopes ที่คุณต้องการจริงๆ เปรียบเทียบ tools/list ที่รับรองความถูกต้องกับ endpoint และ key เดียวกัน กับ client ของคุณ; การค้นพบแบบไม่ระบุตัวตนหรือ key ที่ต่างกันไม่ใช่การเปรียบเทียบที่ถูกต้อง ตรวจสอบการกำหนดค่าระดับโปรเจกต์ที่อาจแทนที่การเชื่อมต่อระดับผู้ใช้ของคุณ จากนั้นเชื่อมต่อใหม่หรือรีสตาร์ทหลังจากการเปลี่ยนแปลงข้อมูลรับรอง

หากแคตตาล็อกเซิร์ฟเวอร์ที่รับรองความถูกต้องมีเครื่องมือ แต่ client ยังไม่สามารถค้นพบได้ ให้บันทึกเวอร์ชัน client เวอร์ชันเซิร์ฟเวอร์ ชื่อ/จำนวนเครื่องมือ และข้อผิดพลาด schema ใดๆ โดยลบข้อมูลรับรองและข้อมูลลูกค้าออก เซสชันที่เริ่มต้นด้วย ENABLE_TOOL_SEARCH=false claude สามารถแยกความแตกต่างระหว่างการค้นพบที่เลื่อนออกไปกับปัญหาการโหลด แต่โหลดคำจำกัดความเครื่องมือทั้งหมดและใช้บริบทมากขึ้น; ใช้เป็นเครื่องมือวินิจฉัยชั่วคราวเท่านั้น อย่าขยายสิทธิ์หรือแยก endpoints เพียงเพื่อเพิ่มจำนวนเครื่องมือ

หากต้องการลบในภายหลัง:

claude mcp remove bugagent

ตัวเลือก 4 — OpenAI Codex CLI

หากคุณใช้ OpenAI Codex CLI ให้ส่งออก API key ของคุณและเพิ่ม bug Agent ไปยัง ~/.codex/config.toml

การลงทะเบียนถาวร (เพิ่มในการกำหนดค่า)

[mcp_servers.bugagent]
url = "https://mcp.bugagent.com/mcp"
bearer_token_env_var = "BUGAGENT_API_KEY"

ตั้งค่า API key

export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

เริ่มหรือรีสตาร์ท Codex จากสภาพแวดล้อมนั้น Codex แก้ไขการเรียกเครื่องมือโดยอัตโนมัติจากพรอมต์ภาษาธรรมชาติของคุณ ลอง: "List my open bugs sorted by severity."

ตัวเลือก 5 — Cursor (Mac + Windows)

Cursor รองรับ MCP ในตัว ด้วย workspace API key ที่มีขอบเขตเหมาะสม AI assistant ภายใน Cursor สามารถไฟล์บั๊ก รายการรายงาน และรันเวิร์กโฟลว์อัตโนมัติที่รองรับได้โดยไม่ต้องออกจากตัวแก้ไข การสแกนความปลอดภัย ประสิทธิภาพ และการสำรวจต้องใช้ delegated OAuth และการเข้าถึงแผนที่เกี่ยวข้อง

1. เปิด Cursor → Settings (Cmd+, บน Mac / Ctrl+, บน Windows) → MCP ในแถบด้านข้างซ้าย
2. คลิก + Add new MCP server
3. เลือกประเภทการขนส่ง HTTP
4. กรอก:
   • Name: bugagent
     • URL: https://mcp.bugagent.com/mcp
     • Header name: Authorization
     • Header value: Bearer ba_live_YOUR_KEY_HERE
5. คลิก Save Cursor จะแสดงตัวบ่งชี้สีเขียวเมื่อเชื่อมต่อ
6. เปิดแชทของ Cursor (Cmd+L / Ctrl+L) และพิมพ์ "Create a bug report titled 'Login broken' with severity high." Cursor จะเรียก create_bug_report

ทางเลือก: Cursor ยังอ่าน ~/.cursor/mcp.json (Mac) หรือ %USERPROFILE%\.cursor\mcp.json (Windows) เพิ่มรูปแบบ JSON เดียวกับที่แสดงในส่วน Claude Desktop

ตัวเลือก 6 — VS Code กับส่วนขยาย Continue (Mac + Windows)

หากคุณชอบ VS Code ส่วนขยาย Continue รองรับ MCP servers โดยกำเนิด

1. ติดตั้งส่วนขยาย Continue จาก VS Code marketplace
2. เปิดการกำหนดค่าของ Continue: Command Palette (Cmd+Shift+P / Ctrl+Shift+P) → Continue: Open config.json ไฟล์อยู่ที่:
   • macOS: ~/.continue/config.json
     • Windows: %USERPROFILE%\.continue\config.json
3. เพิ่มรายการ mcpServers:

   {
     "mcpServers": [
       {
         "name": "bugagent",
         "type": "streamable-http",
         "url": "https://mcp.bugagent.com/mcp",
         "requestOptions": {
           "headers": {
             "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
           }
         }
       }
     ]
   }
   

4. บันทึก Continue จะโหลดซ้ำโดยอัตโนมัติและแสดงเครื่องมือ bug Agent ในแถบด้านข้าง
5. เปิดแผงแชท Continue และลอง: "List my 5 most recent open bug reports."

ส่วนขยาย VS Code อื่นๆ ที่รองรับ MCP: Cline, Roo Code และ Windsurf (fork) ทั้งหมดใช้รูปแบบการกำหนดค่า JSON ที่คล้ายกันกับคีย์ mcpServers และ HTTP transport

ตัวเลือก 7 — โฮสต์ที่รองรับ OAuth (ใช้ Claude.ai web เป็นตัวอย่าง)

โฮสต์ MCP บางตัวรับรองความถูกต้องผ่าน OAuth 2.0 และขอ client_id และ client_secret แบบคงที่ล่วงหน้าแทนที่จะยอมรับ bearer API key สร้างคู่ข้อมูลรับรอง connector จาก dashboard ของ bug Agent และวางลงในแบบฟอร์ม connector ของโฮสต์ คู่นี้ระบุ MCP client; หลังจากการยินยอม การเรียกใช้เครื่องมือจะใช้ผู้ใช้ที่ลงชื่อเข้าใช้และ workspace bug Agent ที่ใช้งานอยู่ของผู้ใช้รายนั้น คำแนะนำด้านล่างใช้แอปเว็บ Claude.ai เป็นตัวอย่างที่พบบ่อยที่สุด

i

OAuth ที่ผูกกับทรัพยากร ตัวระบุทรัพยากรที่ได้รับการป้องกันคือ https://mcp.bugagent.com/mcp โฮสต์ที่เข้าใจมาตรฐานจะค้นพบจาก /.well-known/oauth-protected-resource/mcp และส่งเป็นพารามิเตอร์ RFC 8707 resource bug Agent ออกโทเค็นทึบแสงที่ผูกกับทรัพยากรนั้น OAuth client ผู้ใช้ที่ลงชื่อเข้าใช้ และขอบเขตที่ได้รับ; โทเค็นไม่สามารถเล่นซ้ำกับบริการอื่นหรือแลกโดย client อื่น

1. ใน bug Agent: เปิด Settings → Developers → MCP Connectors คลิก Generate connector ตั้งชื่อที่อธิบายโฮสต์ (เช่น "Claude.ai (work)") วาง redirect URI ที่โฮสต์ MCP ของคุณต้องการ (สำหรับแอปเว็บ Claude.ai คือ https://claude.ai/api/mcp/auth_callback — ตรวจสอบเอกสาร connector ของโฮสต์ของคุณสำหรับรายอื่น) และเลือก Confidential สำหรับวิธีการรับรองความถูกต้อง คัดลอก client_id และ client_secret ที่แสดงครั้งเดียวบนหน้าจอความสำเร็จ
2. ในการตั้งค่า connector / OAuth ของโฮสต์ MCP ของคุณ วาง:
   • Server URL: https://mcp.bugagent.com/mcp
     • Client ID + Client Secret: จากขั้นตอนที่ 1
     • Authorization URL: https://mcp.bugagent.com/authorize
     • Token URL: https://mcp.bugagent.com/token
     • Protected resource / audience เมื่อมีการร้องขอ: https://mcp.bugagent.com/mcp สำหรับ Claude.ai โดยเฉพาะ: ไปที่ claude.ai/customize/connectors และคลิก Add MCP connector
3. บันทึก โฮสต์จะนำคุณไปยัง bug Agent เพื่อลงชื่อเข้าใช้ (Google หรืออีเมล/รหัสผ่าน — วิธีใดก็ตามที่คุณใช้สำหรับ dashboard) และอนุมัติการยินยอม จากนั้นทำ OAuth handshake ให้เสร็จสมบูรณ์
4. จัดการและเพิกถอน connectors ที่สร้างขึ้นจากหน้า Settings เดียวกัน การเพิกถอนจะทันที — คำขอถัดไปจาก connector นั้นจะคืนค่า invalid_client

หมายเหตุ: Claude Code, Cursor, VS Code และ MCP Inspector ไม่จำเป็นต้องใช้ขั้นตอนนี้ — พวกเขาจัดการการลงทะเบียน client แบบไดนามิก (RFC 7591) โดยอัตโนมัติและรับรองความถูกต้องผ่าน API key ตามที่แสดงด้านบน แบบฟอร์ม MCP Connectors มีไว้สำหรับโฮสต์ที่ต้องใช้ข้อมูลรับรอง OAuth แบบคงที่เท่านั้น

ค่า access และ refresh ของ OAuth จะแสดงเฉพาะกับโฮสต์เท่านั้น ค่าเหล่านี้ทึบแสง หมุนเวียนเมื่อรีเฟรช และถูกเก็บโดย bug Agent เป็นแฮชทางเดียวเท่านั้น; ข้อมูลรับรองการรีเฟรชตัวตนต้นทางถูกเข้ารหัสที่เหลือ อย่าคัดลอกโทเค็น OAuth ลงในคำขอ REST API หรือ MCP server อื่น

ตัวเลือก 8 — HTTP โดยตรงด้วย curl (Terminal)

หากคุณต้องการทดสอบเซิร์ฟเวอร์โดยตรงโดยไม่ต้องใช้ไคลเอ็นต์ใดๆ หรือต้องการผสานรวมเข้ากับสคริปต์ คุณสามารถเรียกใช้ HTTP endpoint ด้วย curl โปรโตคอล MCP คือ JSON-RPC 2.0 ผ่าน Streamable HTTP

macOS / Linux

# Set your API key as a variable
export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

# 1. Initialize the MCP connection
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"curl-example","version":"1.0.0"}}}'

# 2. List tools visible to this key
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

# 3. Call a tool — list 5 reports from a specific project
curl -N -s https://mcp.bugagent.com/mcp \
  -H "Authorization: Bearer $BUGAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc":"2.0",
    "id":3,
    "method":"tools/call",
    "params":{
      "name":"list_bug_reports",
      "arguments":{"project":"bugagent","limit":5}
    }
  }'

Windows (PowerShell)

# Set your API key
$env:BUGAGENT_API_KEY = "ba_live_YOUR_KEY_HERE"

# Use Invoke-RestMethod (PowerShell's curl equivalent)
$headers = @{
  "Authorization" = "Bearer $env:BUGAGENT_API_KEY"
  "Content-Type" = "application/json"
  "Accept" = "application/json, text/event-stream"
}

# 1. Initialize
$body = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"powershell-example","version":"1.0.0"}}}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

# 2. List tools visible to this key
$body = '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

# 3. Call list_bug_reports for a specific project
$body = @{
  jsonrpc = "2.0"
  id = 3
  method = "tools/call"
  params = @{
    name = "list_bug_reports"
    arguments = @{ project = "bugagent"; limit = 5 }
  }
} | ConvertTo-Json -Depth 5

Invoke-RestMethod -Uri "https://mcp.bugagent.com/mcp" \`
  -Method Post -Headers $headers -Body $body

การตอบกลับอาจเป็น JSON หรือ Server-Sent Events แต่ละ SSE chunk คือบรรทัดที่นำหน้าด้วย data: ตามด้วยออบเจกต์ JSON ไคลเอ็นต์ที่สอดคล้องกับมาตรฐานควรส่ง Accept: application/json, text/event-stream; bug Agent ปัจจุบันปรับค่า Accept ที่ขาดหายไปหรือไม่สมบูรณ์ให้เป็นมาตรฐานเพื่อความเข้ากันได้

ℹ️

การแก้ไขปัญหา 401 Unauthorized: ตรวจสอบว่าคีย์ API ของคุณยังไม่ถูกเพิกถอนใน Settings → Developers คีย์เริ่มต้นด้วย ba_live_ หากยังติดปัญหาอยู่ ให้สร้างคีย์ใหม่แล้วลองอีกครั้ง

โมเดลการเข้าถึงและขอบเขตสิทธิ์น้อยที่สุด

แคตตาล็อก OAuth ที่สมบูรณ์ประกอบด้วยเครื่องมือ 141 รายการ คีย์ API ของเวิร์กสเปซจะเห็นเฉพาะเครื่องมือที่แมปกับขอบเขตที่เลือกไว้เท่านั้น การค้นพบโดยไม่มีการรับรองความถูกต้องอาจแสดงข้อมูลเมตาของเครื่องมือ แต่ tools/call ต้องใช้คีย์ API หรือโทเค็น OAuth เสมอ

อ่านรายงานบั๊กและแก้ไขโปรเจกต์ reports:read

สร้างและอัปเดตรายงานบั๊ก reports:read, reports:write

ตัวตรวจสอบการใช้งาน usage:read

ตรวจสอบสถานะการซิงค์ Jira jira:read

ซิงค์หรือรวมรายงาน Jira jira:write

สร้างระบบอัตโนมัติบนเว็บ automations:write

รันระบบอัตโนมัติบนเว็บและอ่านผลลัพธ์ automations:run

สังเกตสินทรัพย์มือถือและผลลัพธ์ mobile:read

จัดการสินทรัพย์มือถือ mobile:read, mobile:write

รันระบบอัตโนมัติบนมือถือ mobile:read, mobile:run

จัดการแคตตาล็อกการทดสอบ reports:read, test_cases:read, test_cases:write

ตัวประมวลผลการทดสอบภายนอก test_runs:read, test_runs:write

คีย์ API ผูกกับเวิร์กสเปซที่สร้างขึ้น เครื่องมืออาจจำกัดการเรียกให้แคบลงเหลือโปรเจกต์ที่ได้รับอนุญาต แต่ไม่สามารถสลับคีย์ไปยังเวิร์กสเปซอื่นได้ แก้ไข UUID ของโปรเจกต์ด้วย list_projects และปฏิเสธชื่อที่ไม่ชัดเจน

ชื่อเครื่องมือและคำอธิบายประกอบ

ทุกเครื่องมือที่ส่งคืนโดย tools/list รวมถึงชื่อที่อ่านได้และคำแนะนำการอ่าน/เขียน คำแนะนำการอ่านที่ขาดหายไปมาจากรายการที่ตรวจสอบอย่างชัดเจน ไม่ใช่คำนำหน้าชื่อเครื่องมือหรือขอบเขตคีย์ API คำอธิบายประกอบที่ชัดเจน รวมถึง false จะถูกเก็บรักษาไว้

• readOnlyHint: true อธิบายเครื่องมือที่ไม่แก้ไขสภาพแวดล้อม
• readOnlyHint: false กับ destructiveHint: false อธิบายการเขียนแบบเพิ่มเติม ไม่ใช่การดำเนินการอ่านอย่างเดียว
• readOnlyHint: false กับ destructiveHint: true อธิบายการเขียนที่อาจทำลายข้อมูล เครื่องมือที่ไม่จัดประเภทใช้ค่าเริ่มต้นที่อนุรักษ์นิยมเหล่านี้ คำแนะนำการทำลายข้อมูลมีความหมายเฉพาะกับการเขียนเท่านั้น

login ไม่ใช่การอ่านอย่างเดียว: ในโหมด stdio จะบันทึกข้อมูลรับรอง analyze_fix_area และ check_config_drift เป็นการเขียนที่อาจทำลายข้อมูลเนื่องจากแทนที่ผลการวิเคราะห์หรือเกณฑ์พื้นฐานการกำหนดค่าที่บันทึกไว้

คำอธิบายประกอบไม่ได้ให้สิทธิ์การเข้าถึงหรือแทนที่การรับรองความถูกต้อง การอนุญาตเวิร์กสเปซ/โปรเจกต์ ขอบเขตคีย์ API หรือการตรวจสอบสิทธิ์ การแจ้งเตือนการยืนยันขึ้นอยู่กับนโยบายสิทธิ์ของไคลเอ็นต์และการตั้งค่าผู้ใช้ คำแนะนำไม่รับประกันว่าการเรียกจะมีการแจ้งเตือนหรือไม่

สำหรับการค้นพบและการตรวจสอบเชิงโปรแกรม ให้ดาวน์โหลด mcp-tool-index.json ที่สร้างขึ้น บันทึกเครื่องมือรันไทม์ทั้งหมด 141 รายการ การเข้าถึงเฉพาะขอบเขตคีย์ API หรือ OAuth เท่านั้น กลุ่มสิทธิ์ ชื่ออินพุต โหมดสคีมาผลลัพธ์ และคำอธิบายประกอบ MCP ที่ประกาศอย่างชัดเจน คำอธิบายประกอบ null หมายความว่าไม่ได้ประกาศที่จุดเรียกใช้ ใช้การตอบสนอง tools/list ของเซิร์ฟเวอร์ที่เชื่อมต่อสำหรับคำอธิบายประกอบที่มีผลหลังจากการใช้ค่าเริ่มต้น

!

เครื่องมือเฉพาะ OAuth: การจัดการบัญชี คีย์ API และทีม การจัดการการเชื่อมต่อ Jira การผสานรวมอื่นๆ การควบคุมการทดสอบระดับพรีเมียม บันทึก การติดตามเวลา และการดำเนินการโต้ตอบอื่นๆ ไม่ถูกปลดล็อกโดยการเพิ่มขอบเขตคีย์ API เครื่องมือตรวจสอบ ซิงค์ และรวมรายงาน Jira เป็นข้อยกเว้นแคบๆ ผ่าน jira:read และ jira:write

ลองใช้ — พรอมต์ภาษาธรรมดา

เมื่อเชื่อมต่อแล้ว คุณไม่จำเป็นต้องรู้ชื่อเครื่องมือหรือพารามิเตอร์ อธิบายสิ่งที่คุณต้องการเป็นภาษาธรรมดา และผู้ช่วย AI ของคุณจะเรียกใช้เครื่องมือ bug Agent ที่ถูกต้องโดยอัตโนมัติ

พรอมต์รายงานบั๊ก การจัดการการทดสอบตามขอบเขต ระบบอัตโนมัติ Playwright ระบบอัตโนมัติบนมือถือ และการใช้งาน พร้อมใช้งานสำหรับคีย์ API ที่มีขอบเขตตรงกัน ความปลอดภัย ประสิทธิภาพ การสำรวจ บัญชี ทีม บันทึก การติดตามเวลา และรายการอื่นๆ ที่ไม่มีขอบเขตคีย์ API ที่ระบุชื่อ ต้องใช้ OAuth ที่ได้รับมอบหมายและสิทธิ์แผนที่เกี่ยวข้อง

รายงานบั๊ก

List my 5 most recent bug reports
Show all open critical bugs in the Auth project
Create a bug titled "Login broken on Safari" with severity s2
Update TEST-451 status to in-progress and assign it to me
Add a comment to TEST-451: "root cause confirmed — null check missing in auth middleware"
Show me everything filed this week, grouped by severity

การจัดการการทดสอบ

Create a test suite called "Smoke Tests" with cases for login, checkout, and account settings
Run the Regression suite and list all failures
Use Hermes to execute the curated "Checkout smoke" suite and report every result to bugAgent
Show failing test cases from the last 7 days
Which test cases have never been run in the past 90 days?
Get a pass-rate trend for this month vs last month

ความปลอดภัยและประสิทธิภาพ

Run a security scan on https://app.example.com
Get this month's security scan results — show only high and critical findings
Create a performance test for the landing page and check Lighthouse scores
What are the Core Web Vitals for our checkout flow?

ระบบอัตโนมัติ Playwright

Create a Playwright script that logs in and verifies the dashboard loads
Run the checkout automation on iPhone 15 Pro on a real device
Optimize the login automation script
Show runs for the checkout automation — any failures?
Schedule the smoke test suite to run every weekday at 6 AM UTC

AI การสำรวจ

Run an exploratory AI session on https://app.example.com with 5 parallel agents
Get the latest exploration run results — list any bugs that were filed
What testing strategies did the agents use and which found the most issues?

การใช้งานและสถิติ

Check my plan usage for this month
Show team bug stats for this week broken down by severity and type
List all team members and their roles
How many security scans do I have left this month?

การอ้างอิงด่วน

การอ้างอิงการตั้งค่าสำหรับตัวเลือกการเชื่อมต่อทั้งแปดรายการ ไคลเอ็นต์คีย์ API เชื่อมต่อกับ https://mcp.bugagent.com/mcp ด้วยส่วนหัว Authorization: Bearer ba_live_YOUR_KEY_HERE ผ่าน Streamable HTTP; โฮสต์ที่รองรับ OAuth ใช้ข้อมูลรับรองตัวเชื่อมต่อที่สร้างในแดชบอร์ด

Claude Desktop — macOS ~/Library/Application Support/Claude/claude_desktop_config.json

Claude Desktop — Windows %APPDATA%\Claude\claude_desktop_config.json

Claude Code (CLI) claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_..."

Codex CLI ~/.codex/config.toml

Cursor — macOS Settings → MCP UI หรือ ~/.cursor/mcp.json

Cursor — Windows %USERPROFILE%\.cursor\mcp.json

VS Code + Continue ~/.continue/config.json (macOS) / %USERPROFILE%\.continue\config.json (Windows)

โฮสต์ที่รองรับ OAuth Settings → Developers → MCP Connectors — สร้าง client_id และ client_secret ของโฮสต์

HTTP โดยตรง (curl) curl / Invoke-RestMethod — รวม Accept: application/json, text/event-stream

การแก้ไขปัญหา

401 Unauthorized คีย์ผิด หมดอายุ หรือถูกเพิกถอน ตรวจสอบ Settings → Developers — คีย์เริ่มต้นด้วย ba_live_ สร้างใหม่หากจำเป็น

เครื่องมือไม่แสดงในไคลเอ็นต์ ไคลเอ็นต์คีย์ API แสดงเฉพาะเครื่องมือที่อนุญาตโดยขอบเขตที่เลือกของคีย์ ตรวจสอบคีย์ใน Settings → Developers จากนั้นออกจากไคลเอ็นต์โดยสมบูรณ์แล้วเปิดใหม่หลังจากการเปลี่ยนแปลงการกำหนดค่า ใน Claude Desktop ใช้ Cmd+Q (ไม่ใช่แค่ปิดหน้าต่าง) ใน Cursor ตรวจสอบ Settings → MCP สำหรับจุดสีเขียว

ฟิลด์หายไปในไคลเอ็นต์ เปรียบเทียบสคีมาของไคลเอ็นต์กับ tools/list ดิบของ endpoint เดียวกัน หากแตกต่าง ให้รีเฟรชหรือเชื่อมต่อแคตตาล็อกเครื่องมือใหม่และเริ่มแชทใหม่ หากยังคงอยู่ ให้รวบรวม endpoint เวอร์ชันไคลเอ็นต์ และการตอบสนอง tools/list ดิบ; แคชที่เก่าเป็นเพียงสาเหตุหนึ่งที่เป็นไปได้

Accept header required ส่ง Accept: application/json, text/event-stream สำหรับ Streamable HTTP ที่สอดคล้องกับมาตรฐาน bug Agent ปัจจุบันปรับค่าที่ขาดหายไปหรือไม่สมบูรณ์ให้เป็นมาตรฐาน แต่การผสานรวมไม่ควรพึ่งพาพฤติกรรมความเข้ากันได้นั้น

ข้อมูลเวิร์กสเปซผิด แต่ละคีย์ API จำกัดอยู่ในเวิร์กสเปซเดียว สร้างคีย์ใหม่จากเวิร์กสเปซที่คุณต้องการสอบถามใน Settings → Developers

เครื่องมือปรากฏแต่การเรียกล้มเหลวอย่างเงียบๆ ตรวจสอบการตอบสนองสำหรับ isError: true และเนื้อหาที่ส่งคืน เครื่องมือที่มองเห็นได้ยังสามารถถูกปฏิเสธโดยแผน บทบาท สิทธิ์ฟีเจอร์ การเป็นสมาชิกโปรเจกต์ ความเป็นเจ้าของ หรืออินพุตที่ไม่ถูกต้อง ตรวจสอบสุขภาพเซิร์ฟเวอร์หลังจากอ่านข้อผิดพลาดของเครื่องมือเท่านั้น

MCP Inspector ข้อผิดพลาด CORS เลือก Proxy (ไม่ใช่ Direct) สำหรับ Connection Type ใน UI ของ Inspector Inspector พร็อกซีผ่านกระบวนการ Node ในเครื่องเพื่อหลีกเลี่ยงข้อจำกัด CORS ของเบราว์เซอร์

MCP Inspector v2 ออกด้วยรหัส 5 Inspector v2 ส่งคืนรหัสออกที่ไม่ใช่ศูนย์เมื่อการตอบสนองของเครื่องมือมี isError: true อ่านข้อความการตอบสนองสำหรับแผน สิทธิ์ อินพุต หรือข้อผิดพลาดรันไทม์; Inspector v1 อาจส่งคืนรหัสออก 0 สำหรับการตอบสนองเครื่องมือที่ล้มเหลวเดียวกัน

Codex CLI — เครื่องมือไม่รู้จัก ตรวจสอบว่า ~/.codex/config.toml ใช้ [mcp_servers.bugagent] ตั้งค่า bearer_token_env_var = "BUGAGENT_API_KEY" และส่งออกตัวแปรนั้นก่อนเริ่ม Codex ตรวจสอบ codex --version หากเครื่องมือยังไม่ปรากฏ

คุณสมบัติ MCP

เซสชันการสนทนายังคงเป็นโปรเจกต์นำร่องที่จำกัดเวิร์กสเปซ การบันทึกสคริปต์ที่สร้างจากเซสชันต้องได้รับการอนุมัติอย่างชัดเจนจากเจ้าของผ่าน Workbench ผ่าน endpoint บันทึกสคริปต์เฉพาะเซสชัน ไม่มีเครื่องมืออนุมัติ MCP: การขอให้เอเจนต์ร่างสคริปต์ไม่ได้สร้างหรือกำหนดเวลาระบบอัตโนมัติ

แคตตาล็อกโต้ตอบ/OAuth ที่สมบูรณ์ประกอบด้วยเครื่องมือ 141 รายการ คีย์ API ของเวิร์กสเปซค้นพบเฉพาะชุดย่อยสิทธิ์น้อยที่สุดที่อนุญาตโดยขอบเขตที่เลือก; เครื่องมือบัญชี การบริหารคีย์ API การบริหารทีม การทดสอบระดับพรีเมียม บันทึก และการติดตามเวลา เป็นเซสชันโต้ตอบเท่านั้น เว้นแต่รายการจะระบุขอบเขตคีย์ API อย่างชัดเจน

🐛

การจัดการรายงานบั๊ก

การนำเข้าภาพหน้าจอ Google Sheets ที่สามารถดำเนินการต่อได้ใช้ endpoint REST POST /api/reports/import-attachment แยกต่างหากกับ reports:write และตรวจสอบสถานะ GET ด้วย reports:read ไม่มีการเพิ่มเครื่องมือ MCP สำหรับการนำเข้าภาพหน้าจอ API ที่รองรับ JPEG/PNG เท่านั้นนี้ตรวจสอบพื้นที่จัดเก็บส่วนตัวและปัญหา Jira ที่แมปอย่างแม่นยำก่อนรายงานความสำเร็จ; การอัปโหลดรายงานแบบเดิมยังคงเป็นเซสชันเท่านั้น

• create_bug_report — สร้างรายงานใหม่พร้อมการจัดหมวดหมู่อัตโนมัติครอบคลุม 19 ประเภท — บั๊ก คำขอฟีเจอร์ การปรับปรุง หนี้ทางเทคนิค และอื่นๆ (ชื่อเรื่อง: 3-500 ตัวอักษร) อาร์เรย์ attachments แบบไม่บังคับรองรับไฟล์ที่เข้ารหัส base64 สูงสุด 400 MB ต่อไฟล์: รูปภาพ วิดีโอ เสียง PDF หรือข้อความ/JSON ตั้งค่า format_description: true เพื่อจัดรูปแบบคำอธิบายใหม่เป็นเทมเพลตที่มีโครงสร้างโดยอัตโนมัติด้วย AI ส่ง time_spent_seconds เพื่อติดตามความพยายามด้าน QA ส่ง priority (urgent / high / normal / low) เพื่อตั้งค่าความเร่งด่วนในการแก้ไขโดยแยกจากระดับความรุนแรง ส่ง is_epic: true เพื่อสร้าง Epic หรือ parent_epic_id (UUID/รหัสย่อ) เพื่อสร้างรายการย่อยในโปรเจกต์ที่ได้รับอนุญาตเดียวกัน การตอบกลับประกอบด้วยฟิลด์ลำดับชั้นรวมถึง project_id, project, short_id, legacy_short_id และ project_short_id
• list_bug_reports — แสดงรายการและกรองรายงาน (สูงสุด 100 รายการต่อหน้า) ตัวกรองโปรเจกต์จะถูกนำไปใช้ฝั่งเซิร์ฟเวอร์ก่อนการแบ่งหน้า กรองตาม project (UUID, slug, ชื่อที่แน่นอน หรือคำนำหน้าตั๋ว), project_id, project_slug, project_prefix, workspace (UUID, ชื่อที่แน่นอน หรือคำนำหน้าตั๋วของเวิร์กสเปซ), workspace_id / team_id, is_epic, type, severity, status, resolution, root_cause หรือ reporter_user_id ตัวกรอง search ค้นหาข้อความในรายงาน; การป้อนเฉพาะตัวเลขเช่น 366 คือการค้นหาที่ตรงกันแบบเจาะจงกับทั้งหมายเลขตั๋วแบบเดิมและแบบโปรเจกต์ ดังนั้นข้อความที่ไม่เกี่ยวข้องซึ่งมีตัวเลขเหล่านั้นจะถูกแยกออก ผลลัพธ์แต่ละรายการประกอบด้วยตัวระบุบุคคล/โปรเจกต์ตามขอบเขตเทนแนนต์ รวมถึง is_epic, parent_epic_id, parent_epic และ epic_progress แบบจำกัด เครื่องมืออ่านรายงานไม่เปิดเผยที่อยู่อีเมลของสมาชิก
• pick_next_bug — คืนค่าบั๊กถัดไปที่ลูปเอเจนต์ควรดำเนินการ ตามลำดับความสำคัญ (S1 → S2 → S3, รายการเก่าที่สุดก่อนภายในแต่ละกลุ่ม) จำกัดขอบเขตให้กับเวิร์กสเปซของคุณโดยอัตโนมัติ — คืนค่าตั๋วในทุกโปรเจกต์ในทีมของคุณที่มี status new, awaiting-triage หรือ confirmed และระดับความรุนแรง S1-S3 อ่านอย่างเดียว — ไม่ได้จองตั๋วแบบอะตอมิก severity แบบไม่บังคับ (ระดับเดียว), limit (1-50, ค่าเริ่มต้น 1) คืนค่าวัตถุที่มี count และ bugs; แต่ละบั๊กเป็นแถวคิวแบบย่อ ไม่ใช่รูปแบบ list_bug_reports เต็มรูปแบบ ใช้ร่วมกับ claim_bug สำหรับรูปแบบอ่านแล้วจอง
• claim_bug — เปลี่ยนสถานะบั๊กแบบอะตอมิกจาก status new, awaiting-triage หรือ confirmed เป็น status='in-progress', ตั้งค่า assigned_to เป็นผู้เรียก และประทับตรา claimed_at=NOW() ปราศจากการแข่งขันระหว่างผู้เรียกพร้อมกันผ่านรูปแบบ UPDATE-WHERE-RETURNING ของ Postgres — หากเอเจนต์สองตัวเรียก claim_bug บน id เดียวกันในเวลาที่ใกล้เคียงกัน ตัวหนึ่งจะได้รับ claimed:true พร้อมเนื้อหาบั๊ก และอีกตัวจะได้รับ claimed:false พร้อมสตริงเหตุผล การตอบกลับที่สำเร็จประกอบด้วย reporter_user_id, reporter_name, assigned_to และ assignee_name ตัวเก็บขยะ pg_cron ปล่อยการจองที่เก่า (สถานะ= in-progress + claimed_at > 30 นาที) กลับไปเป็น new โดยอัตโนมัติ ดังนั้นตั๋วของเอเจนต์ที่หยุดทำงานจะกลับเข้าคิวโดยไม่ต้องดำเนินการด้วยตนเอง ข้อมูลนำเข้า: id (UUID หรือรหัสย่อ)
• get_bug_report — รับรายละเอียดเต็มของรายงานด้วย UUID หรือรหัสย่อของเวิร์กสเปซ/โปรเจกต์ คืนค่าฟิลด์บุคคล/โปรเจกต์/คุณภาพมาตรฐาน รวมถึง is_epic, ข้อมูลผู้ปกครอง, ความคืบหน้ารวม และหน้าแรกของรายการย่อยแบบจำกัดสำหรับ Epic
• แท็กรายงานแบบเนทีฟ: create_bug_report และ update_bug_report รับ tags เป็นอาร์เรย์สตริง เช่น {"tags":["login","regression"]} ยอมรับองค์ประกอบดิบสูงสุด 20 รายการก่อนการตัดซ้ำ สตริงจะถูกตัดช่องว่าง ต้องไม่ว่างเปล่าและยาวไม่เกิน 50 จุดรหัส Unicode และต้องไม่มีอักขระควบคุม ASCII (U+0000 ถึง U+001F หรือ U+007F) รายการที่ซ้ำกันทุกประการจะถูกลบหลังการตัดช่องว่าง; การใช้อักษรตัวพิมพ์ใหญ่/เล็กจะถูกรักษาไว้ และ Login แตกต่างจาก login ในการอัปเดต อาร์เรย์จะแทนที่แท็กทั้งหมด [] ล้างแท็ก และการละเว้นจะรักษาแท็กไว้ ในการสร้าง การละเว้นหมายถึงไม่มีแท็ก null และองค์ประกอบที่ไม่ถูกต้องจะถูกปฏิเสธ ผลลัพธ์การสร้าง การรับ การแสดงรายการ และการอัปเดตเปิดเผย tags แบบเนทีฟ
• การกรองแท็ก: เรียก list_bug_reports ด้วย {"project":"bugagent","tags":["login","regression"]} เพื่อจับคู่แท็กที่ร้องขอทั้งหมด ตามตัวพิมพ์เล็ก-ใหญ่ ก่อนการแบ่งหน้า ข้อจำกัดแท็กเดียวกันนี้ใช้; การละเว้นหรือ [] ไม่ใช้ตัวกรองแท็ก ขอบเขต reports:read / reports:write ที่มีอยู่และการอนุญาตเวิร์กสเปซ/โปรเจกต์ไม่เปลี่ยนแปลง สิ่งนี้ไม่เพิ่ม UI แท็กแบบภาพหรือการนำเข้า การซิงค์ หรือการเติมข้อมูลป้ายกำกับ Jira อัตโนมัติ
• get_epic — อ่าน Epic หนึ่งรายการโดยตรงด้วย id ที่จำเป็น (UUID หรือรหัสย่อของเวิร์กสเปซ/โปรเจกต์) คืนค่าเฉพาะระเบียน Epic โดยไม่โหลดรายงานย่อยโดยปริยาย ต้องมีการเข้าถึงเวิร์กสเปซและโปรเจกต์; ผู้เรียกใช้คีย์ API ต้องมี reports:read ใช้ list_epic_children แยกต่างหากเพื่ออ่านรายการย่อย
• list_epic_children — แบ่งหน้ารายงานย่อยของ Epic ด้วย id, limit (1–100) และ offset คืนค่า children, total, has_more และ epic_progress ที่รวมด้วย SQL โดยไม่โหลดรายงานย่อยทุกรายการ
• update_bug_report — อัปเดตฟิลด์รายงานมาตรฐานรวมถึง is_epic และ parent_epic_id ส่ง parent_epic_id: null เพื่อแยกออก; การกำหนดผู้ปกครองใหม่/การแยกเป็นแบบอะตอมิกและต้องมีการอนุญาตเวิร์กสเปซและโปรเจกต์เดียวกัน การเลื่อนเป็น Epic จะแยกผู้ปกครองที่มีอยู่ออก ในขณะที่ Epic ที่มีรายการย่อยไม่สามารถลดระดับได้ กฎการแจ้งเตือนสถานะ/การแก้ไข/สาเหตุรากและการกำหนดที่ยังคงใช้ การเปลี่ยนแปลง status ในรายงานที่เชื่อมโยงกับ Jira จะถูกสะท้อนไปยัง issue ของ Jira ผ่านการเปลี่ยนเวิร์กโฟลว์เมื่อมีการเปลี่ยนทางกฎหมายเพียงรายการเดียวที่ตรงกับสถานะที่แมป; มิฉะนั้น issue จะไม่ถูกแตะต้อง
• add_comment — เพิ่มความคิดเห็นในรายงานบั๊ก (UUID หรือรหัสย่อ, เนื้อหา 1-10000 ตัวอักษร) หากรายงานถูกซิงค์กับ Jira ความคิดเห็นจะถูกส่งไปยัง issue ของ Jira ที่เชื่อมโยงโดยอัตโนมัติ มาร์กดาวน์ไฟล์แนบส่วนตัวเช่น ![proof](/api/attachments/ATTACHMENT_UUID) จะกลายเป็นลิงก์อัจฉริยะ bugAgent ที่รับรองความถูกต้องแบบสัมบูรณ์ใน Jira ผู้ชมต้องลงชื่อเข้าใช้ bugAgent ด้วยการเข้าถึงเวิร์กสเปซและโปรเจกต์ของรายงาน; การแสดงตัวอย่าง Jira แบบอินไลน์เนทีฟไม่รับประกัน
• list_comments — แสดงรายการเธรดความคิดเห็นที่เก็บไว้ของรายงาน เรียงจากเก่าที่สุดก่อน — แต่ละความคิดเห็นพร้อมชื่อผู้เขียน, parentId (การตอบกลับแบบเธรด), createdAt และ updatedAt ความคิดเห็นไม่เป็นส่วนหนึ่งของ get_bug_report ดังนั้นนี่คือวิธีอ่านการสนทนาของตั๋ว รับ UUID หรือรหัสย่อ การอ่านนี้ไม่รีเฟรช Jira การผสานรวมตามกำหนดการที่ต้องการความคิดเห็น Jira ใหม่สามารถเรียก POST /api/jira/comments-refresh ก่อนด้วยคีย์ API ที่เป็นเจ้าของโดยผู้จัดการที่ได้รับอนุญาต ใช้ ID ความคิดเห็นและการแก้ไขเนื้อหาเพื่อแยกแยะความคิดเห็นใหม่จากการแก้ไข และอย่าอ้างว่ารายงานกิจกรรมสมบูรณ์หากการรีเฟรชล้มเหลว
• link_bug_reports — สร้างลิงก์ความหมายแบบมีทิศทางระหว่างรายงานสองรายการในโปรเจกต์ที่ได้รับอนุญาตเดียวกัน สำหรับ parent-of รายงานต้นทางต้องเป็น Epic และรายงานปลายทางเป็นรายการย่อยมาตรฐาน ควรใช้ parent_epic_id ในการสร้าง/อัปเดตสำหรับการกำหนด Epic
• unlink_bug_reports — ลบลิงก์รายงานบั๊กที่สร้างไว้ก่อนหน้านี้ด้วย UUID (link_id, คืนค่าโดย link_bug_reports หรือ list_bug_report_links)
• list_bug_report_links — แสดงรายการลิงก์ที่ผู้ใช้ดูแลทุกอันที่เกี่ยวข้องกับรายงานบั๊ก คืนค่าแต่ละลิงก์ตามที่อ่านจากมุมมองของรายงานที่ให้มา — เช่น แถว duplicate-of ที่เก็บไว้ซึ่งรายงานนี้เป็นเป้าหมายจะแสดงเป็น duplicated-by; parent-of ที่รายงานนี้เป็นเป้าหมายจะแสดงเป็น subtask-of; depends-on ที่รายงานนี้เป็นเป้าหมายจะแสดงเป็น blocks; testing-blocked-by ที่รายงานนี้เป็นเป้าหมายจะแสดงเป็น blocks-testing related-to เป็นแบบสมมาตร เสริมฟิลด์ similar_reports ที่ตรวจจับอัตโนมัติซึ่งคืนค่าโดย get_bug_report
• classify_bug — จัดหมวดหมู่คำอธิบายเป็นหนึ่งใน 19 ประเภทรายงาน (บั๊ก ฟีเจอร์ การปรับปรุง ฯลฯ) พร้อมคะแนนความเชื่อมั่น
• flush_reports — ลบรายงานเก่าจำนวนมาก (เฉพาะผู้ดูแลระบบ)

📊

การใช้งานและการวิเคราะห์

• get_usage — ตรวจสอบการใช้งานเทียบกับขีดจำกัดของแผน ผู้เรียกใช้คีย์ API ต้องมี usage:read
• get_stats — จำนวนรายวัน การแจกแจงตามประเภท/ความรุนแรง/สถานะ

📁

การจัดการโปรเจกต์

• list_projects — แสดงรายการโปรเจกต์ที่เข้าถึงได้พร้อม id, name, slug, ticket_prefix, คำอธิบาย และสถานะเริ่มต้น ใช้ค่าเหล่านั้นกับเครื่องมือรายงานบั๊กและแคตตาล็อกการทดสอบเพื่อกำหนดเป้าหมายโปรเจกต์ที่ถูกต้อง
• create_project — สร้างโปรเจกต์ใหม่ (กลายเป็นค่าเริ่มต้นโดยอัตโนมัติหากเป็นโปรเจกต์แรก)
• delete_project — ลบโปรเจกต์และข้อมูลที่เกี่ยวข้องทั้งหมดอย่างถาวร (รายงานบั๊ก ระบบอัตโนมัติ กรณีทดสอบ แอปมือถือ ตารางเวลา สแนปภูมิศาสตร์ บันทึก รายการเวลา) เฉพาะเจ้าของ/ผู้จัดการเท่านั้น ไม่สามารถลบโปรเจกต์สุดท้ายได้ พื้นที่จัดเก็บจะถูกปล่อยโดยอัตโนมัติ
• export_okf_bundle — ส่งออกความรู้ QA ของโปรเจกต์ — รายงานบั๊ก กรณีทดสอบ ระบบอัตโนมัติ และการทดสอบประสิทธิภาพ ความปลอดภัย และการสำรวจ — เป็นชุดมาร์กดาวน์ OKF/OQA (รูปแบบ Open Query Agent ที่ใช้โดย oqa.ai) ค่าเริ่มต้นคือโปรเจกต์ที่ใช้งานอยู่; ส่ง project แบบไม่บังคับ (slug หรือชื่อ) เพื่อส่งออกโปรเจกต์อื่น คืนค่ารายการไฟล์ในชุดรวมถึงชุดรวมเองเป็น zip ที่เข้ารหัส base64

🔐

การรับรองความถูกต้องและบัญชี

• register_account — สร้างบัญชีใหม่ (รหัสผ่าน: 8-128 ตัวอักษร, จำกัดอัตรา: 5/15 นาที)
• login — ลงชื่อเข้าใช้และรับโทเค็นการเข้าถึง (จำกัดอัตรา: 5/15 นาที)
• update_profile — อัปเดตชื่อที่แสดง
• change_password — เปลี่ยนรหัสผ่านบัญชี
• get_settings — อ่านโปรไฟล์และการตั้งค่าการแจ้งเตือน
• update_settings — อัปเดตโปรไฟล์และการตั้งค่าการแจ้งเตือนที่รองรับ การเปลี่ยนแปลงเฉพาะ OAuth

🔑

การจัดการคีย์ API

• generate_api_key — สร้างคีย์ API ที่มีชื่อ
• list_api_keys — แสดงรายการคีย์ที่ใช้งานอยู่ (เฉพาะคำนำหน้า)
• regenerate_api_key — เพิกถอนและแทนที่คีย์
• delete_api_key — เพิกถอนคีย์อย่างถาวร

👥

การจัดการทีม

• list_workspaces — แสดงรายการเวิร์กสเปซที่คุณเป็นสมาชิก บทบาทของคุณในแต่ละเวิร์กสเปซ และเวิร์กสเปซที่เซสชันใช้เป็นค่าเริ่มต้น โฮสต์หลายเวิร์กสเปซสามารถปักหมุดคำขอด้วยส่วนหัว X-BugAgent-Workspace (เฉพาะสมาชิกที่ใช้งานอยู่)
• list_team_members — แสดงรายการสมาชิกทั้งหมดของเวิร์กสเปซของคุณพร้อมบทบาท สถานะ และแฟล็กบูสเตอร์
• invite_team_member — เชิญผู้ใช้ทางอีเมล (ผู้จัดการสามารถเชิญผู้มีส่วนร่วมและผู้จัดการ; เฉพาะเจ้าของเท่านั้นที่สามารถเชิญผู้ดูแลระบบ) ลิงก์หมดอายุ 5 วัน

🎯

การผสานรวม

การซิงค์รายงาน Jira Cloud รวมอยู่ใน Free และ Enterprise ผู้จัดการเวิร์กสเปซต้องเชื่อมต่อ Jira ในแดชบอร์ดก่อน คีย์ API ของเวิร์กสเปซสามารถใช้ jira:read สำหรับการเปรียบเทียบและ jira:write สำหรับการซิงค์/รวม; แผน Atlassian และขีดจำกัด API ยังคงมีผล

• sync_to_jira — ผลักรายงานไปยัง Jira โดยใช้การเชื่อมต่อที่ใช้ร่วมกันของทีม เส้นทางไปยังโปรเจกต์ Jira ที่ แมป กับโปรเจกต์ bugAgent ของรายงาน (ค่าเริ่มต้นของเวิร์กสเปซเป็นตัวสำรอง) โดยใช้แผนผังฟิลด์: v2 แยก priority และ custom severity ขณะที่แผนผังที่ไม่มีเวอร์ชันยังคงการแปล severity-to-priority แบบเดิม ตัวเลือก projectKey อาจเลือกเฉพาะการแมปที่กำหนดค่าหรือค่าเริ่มต้นของเวิร์กสเปซ โปรเจกต์ Jira ตามอำเภอใจจะถูกปฏิเสธ คุณมักไม่จำเป็นต้องใช้สิ่งนี้: เมื่อโหมดซิงค์ของโปรเจกต์เป็น auto_new หรือ auto_all รายงานที่คุณสร้างจะถูกผลักโดยอัตโนมัติ — เรียกใช้เพื่อการผลักด้วยตนเองในโหมด manual
• check_jira_sync — การเปรียบเทียบแบบอ่านอย่างเดียวของชื่อเรื่องและสถานะที่แมป priority และ severity สำหรับรายงานที่เชื่อมโยงที่ได้รับอนุญาต ใช้โปรเจกต์ที่บันทึกไว้และการเชื่อมต่อ Jira ของรายงาน เวอร์ชัน 2 แมป Jira Priority แยกจากฟิลด์ Severity แบบกำหนดเองที่รองรับ การแมปที่ไม่มีเวอร์ชันยังคงพฤติกรรม priority-to-severity แบบเดิม เครื่องมือนี้ไม่เปรียบเทียบความคิดเห็น ไฟล์แนบ ประเภท หรือทุกฟิลด์ Jira
• merge_jira_sync — รวมฟิลด์ที่แมปเหล่านั้นโดยใช้ prefer: jira เพื่อดึงค่า Jira หรือ prefer: bugagent เพื่อผลักค่าท้องถิ่น การผลักสถานะใช้การเปลี่ยนสถานะเวิร์กโฟลว์ Jira ที่ถูกต้องตามกฎหมาย ความขัดแย้งขาออกที่ไม่มีการแมป การเขียนระยะไกลที่ล้มเหลว และการเปลี่ยนแปลงท้องถิ่นพร้อมกันส่งคืนข้อผิดพลาดแทนที่จะอ้างว่าทุกอย่างซิงค์กัน ความคิดเห็นและไฟล์แนบยังคงเป็นเวิร์กโฟลว์ซิงค์แดชบอร์ดแยกต่างหาก การเขียนข้ามระบบไม่เป็นอะตอมมิก
• push_to_claude — สร้าง (หรือสร้างใหม่) Developer Notes สำหรับรายงานบั๊ก — สาเหตุต้นตอ ข้อเสนอแนะการแก้ไข ขั้นตอนการตรวจสอบ และการประเมินความเสี่ยง รับ UUID หรือ ID สั้น (WRKID-545) ใช้คีย์แพลตฟอร์ม — ไม่ต้องเชื่อมต่อ Claude ต่อทีม เรียกใช้เชนแบบปรับตัว: สามขั้นตอน สำหรับบั๊ก s3 / medium หรือ s4 / low (ร่าง Sonnet → คำวิจารณ์ OpenAI gpt-5 → การสังเคราะห์ Sonnet) ห้าขั้นตอน สำหรับกลุ่มความรุนแรงสองอันดับแรก — s1 / critical หรือ s2 / high — (ร่าง → คำวิจารณ์ → การโต้แย้ง Sonnet → ผู้ตัดสิน Claude Opus ที่อ่านบันทึกทั้งหมดและเขียนบันทึกสุดท้ายด้วยดุลยพินิจอิสระ) การตอบสนองเปิดเผยทุกรอบ: analysis, draft, critique, rebuttal, challenger_model, adjudicator_model, และแฟล็ก debated ขั้นตอนใดก็ตามที่ล้มเหลวจะตกไปยังคำตอบที่ดีที่สุดถัดไป เรียกใช้โดยอัตโนมัติเมื่อสร้างบั๊ก โดยปกติจะเรียกใช้เพื่อสร้างใหม่ด้วยตนเองเท่านั้น
• analyze_fix_area — สร้าง (หรือสร้างใหม่) บล็อกย่อย "Likely Fix Area" ของ Developer Notes — ผลลัพธ์ Sonnet แบบแคบที่ระบุว่าการแก้ไขมีแนวโน้มอยู่ในส่วนใดของโค้ดเบส รับ UUID หรือ ID สั้น ใช้คีย์ Anthropic ของแพลตฟอร์ม เมื่อทีมมีแถว github_connections และโปรเจกต์มีการแมป github_repo ผลลัพธ์จะอ้างอิงจากตัวอย่างไฟล์จริงจาก repo ที่เชื่อมต่อ มิฉะนั้นจะตกไปใช้คำแนะนำทั่วไปพร้อมคำแนะนำให้เชื่อมต่อ repo ส่งคืนข้อความ likely_fix_area, generated_at, repo_used, และแฟล็ก grounded เรียกใช้โดยอัตโนมัติเมื่อสร้างบั๊ก — เอเจนต์โดยทั่วไปต้องเรียกใช้เพื่อสร้างใหม่ด้วยตนเองเท่านั้น
• upgrade_plan — รับลิงก์การลงทะเบียน Enterprise ที่ช่วยเหลือโดยฝ่ายขาย

⚡

การทดสอบประสิทธิภาพ

• create_performance_test — สร้างการกำหนดค่าการทดสอบประสิทธิภาพด้วย URL อุปกรณ์ ผู้ใช้เสมือน ระยะเวลา เกณฑ์คะแนน และสลับการสร้างบั๊กอัตโนมัติ เฉพาะ Enterprise
• run_performance_test — เรียกใช้การตรวจสอบหน้าเว็บและการทดสอบโหลดสำหรับการทดสอบประสิทธิภาพเว็บ ส่งคืน ID การรันเพื่อรอผล การรันโปรไฟล์แอปมือถือถูกเรียกใช้จากแดชบอร์ด
• get_performance_results — รับผลลัพธ์เต็มรูปแบบรวมถึงคะแนน Lighthouse (Performance, Accessibility, Best Practices, SEO), Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI), และเมตริกการทดสอบโหลด (VUs, requests, RPS, p50/p90/p95/p99 latencies)
• list_performance_tests — แสดงรายการการกำหนดค่าการทดสอบประสิทธิภาพทั้งหมดสำหรับทีมปัจจุบัน
• get_performance_usage — ตรวจสอบการใช้งานการทดสอบประสิทธิภาพรายเดือน การทดสอบประสิทธิภาพเฉพาะ Enterprise เท่านั้น Free=0, Enterprise=ไม่จำกัด

เวิร์กโฟลว์ตัวอย่าง

1. get_performance_usage → ตรวจสอบโควต้าคงเหลือ
2. create_performance_test → กำหนดค่าการทดสอบสำหรับ URL ของคุณ
3. run_performance_test → เรียกใช้การตรวจสอบ + การทดสอบโหลด
4. get_performance_results → ตรวจสอบคะแนนและ vitals

🛡

การสแกนความปลอดภัย

• create_security_scan — สร้างการกำหนดค่าการสแกนความปลอดภัย การสแกนเว็บใช้ Quick Scanner + Nuclei (เทมเพลต 4,000+ รายการ) พร้อมระดับความลึกสามระดับและการสแกนแบบรับรองความถูกต้องที่เป็นตัวเลือก การสแกนมือถือใช้ MobSF สำหรับการวิเคราะห์ไบนารี APK/IPA การสร้างบั๊กอัตโนมัติที่กำหนดค่าได้พร้อมเกณฑ์ความรุนแรง เฉพาะ Enterprise
• run_security_scan — เรียกใช้การสแกนช่องโหว่ การสแกนเว็บต้องมีการยืนยันโดเมน DNS การสแกนมือถือต้องมีแอปที่อัปโหลด ส่งคืน ID การรันเพื่อรอผล
• get_security_results — รับผลลัพธ์เต็มรูปแบบรวมถึงคะแนนความปลอดภัย (0-100) การค้นพบที่จัดหมวดหมู่ตามความรุนแรง (Critical, High, Medium, Low, Info) พร้อมการอ้างอิง CWE การแมป OWASP หลักฐาน และคำแนะนำการแก้ไข
• list_security_scans — แสดงรายการการกำหนดค่าการสแกนความปลอดภัยทั้งหมดสำหรับทีมปัจจุบันพร้อมคะแนนล่าสุดและป้าย auth/depth
• get_security_usage — ตรวจสอบการใช้งานการสแกนความปลอดภัยรายเดือน การสแกนความปลอดภัยเฉพาะ Enterprise เท่านั้น Enterprise=ไม่จำกัด
• list_security_schedules — แสดงรายการการสแกนความปลอดภัยตามกำหนดเวลาทั้งหมดสำหรับทีมพร้อม cron โซนเวลา สถานะเปิดใช้งาน การรันครั้งถัดไป และการตั้งค่าการแจ้งเตือน รวมกับการกำหนดค่าการสแกนหลัก (name, scan_type, target_url)
• create_security_schedule — สร้างกำหนดการที่เกิดซ้ำสำหรับการสแกนความปลอดภัย ต้องใช้ scan_id และ cron_expression หนึ่งกำหนดการต่อการกำหนดค่าการสแกน ตัวเลือก timezone, notify_on_fail (none/email/slack/both), notify_email, slack_channel_id ทุกการรันนับรวมกับขีดจำกัดรายเดือนของคุณ ผู้ใช้ admin ข้ามขีดจำกัด ความลึกการสแกนจะอ่านจากการกำหนดค่าการสแกนเสมอเมื่อรัน
• delete_security_schedule — ลบการสแกนความปลอดภัยตามกำหนดเวลา ไม่ส่งผลต่อการกำหนดค่าการสแกนหลักหรือการรันที่เสร็จสมบูรณ์

เวิร์กโฟลว์ตัวอย่าง

1. get_security_usage → ตรวจสอบโควต้าคงเหลือ
2. create_security_scan → กำหนดค่าการสแกนสำหรับ URL หรือ repo ของคุณ
3. run_security_scan → เรียกใช้การสแกนช่องโหว่แบบครั้งเดียว
4. create_security_schedule → ทำให้การรันที่เกิดซ้ำเป็นอัตโนมัติ (เช่น SAST รายสัปดาห์บนสาขาหลัก)
5. get_security_results → ตรวจสอบการค้นพบและการแก้ไข

📖

การตรวจสอบโค้ด

• list_code_reviews — แสดงรายการการตรวจสอบโค้ด AI ล่าสุดสำหรับทีม ส่งคืนคะแนนคุณภาพ จำนวนความรุนแรง ข้อมูล PR และการประทับเวลา เฉพาะ Enterprise
• get_code_review — รับการตรวจสอบโค้ดพร้อมการค้นพบทั้งหมด การค้นพบแต่ละรายการรวมถึงความรุนแรง หมวดหมู่ (bug/security/performance/style/logic/maintainability) ชื่อเรื่อง คำอธิบาย ข้อเสนอแนะโค้ด เส้นทางไฟล์ และหมายเลขบรรทัด
• get_code_review_usage — ตรวจสอบการใช้งานการตรวจสอบโค้ด การตรวจสอบโค้ด AI เฉพาะ Enterprise เท่านั้น ไม่จำกัดบน Enterprise
• get_code_review_analytics — รับการวิเคราะห์การตรวจสอบ: แนวโน้ม หมวดหมู่/แหล่งที่มาของการค้นพบ การแจกแจงความรุนแรง เมตริกความเร็ว repo/ผู้เขียนอันดับต้น รองรับการย้อนหลัง 7/30/90 วัน

เวิร์กโฟลว์ตัวอย่าง

1. get_code_review_usage → ตรวจสอบการตรวจสอบที่เหลือ
2. ตรวจสอบ PR ในแดชบอร์ดที่ /dashboard/code-review
3. list_code_reviews → ดูการตรวจสอบล่าสุด
4. get_code_review → รับการค้นพบและข้อเสนอแนะ

🔍

Exploratory AI

ตัวค้นหาบั๊กเว็บไซต์อัตโนมัติแบบหลายเอเจนต์พร้อมเอเจนต์ขนานสูงสุด 10 ตัว แต่ละตัวใช้กลยุทธ์การทดสอบที่แตกต่างกัน

• list_explorations — แสดงรายการการกำหนดค่า Exploratory AI สำหรับทีม
• create_exploration — สร้างการสำรวจใหม่ รับ agent_count (1–10, สูงสุด 10) เพื่อรันเอเจนต์ขนานหลายตัวพร้อมกลยุทธ์เฉพาะ: happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom เครื่องมือนี้ไม่สามารถกำหนดค่าข้อมูลรับรองหรือโหมดการรับรองความถูกต้อง กำหนดค่าและเปิดใช้ Test login flow only อย่างชัดเจนผ่านแดชบอร์ดหรือ REST จากนั้นใช้ get_exploration และ get_exploration_run เพื่อตรวจสอบการกำหนดค่าและผลลัพธ์ อย่าอนุมานโหมดจากคำแนะนำหรือใส่ข้อมูลรับรองในอาร์กิวเมนต์ MCP การสำรวจตามข้อมูลรับรองเริ่มต้นยังต้องมีเซสชันที่ใช้ซ้ำได้
• get_exploration — รับการกำหนดค่าการสำรวจพร้อมการตั้งค่าเอเจนต์ เมตาดาต้าการรับรองความถูกต้องที่ปลอดภัย และการรันล่าสุด รหัสผ่านและ ciphertext จะไม่ถูกส่งคืน
• get_exploration_run — รับผลลัพธ์การรันพร้อมความคืบหน้าต่อเอเจนต์ ข้อมูลเฟส การค้นพบพร้อมการระบุแหล่งที่มาของเอเจนต์ (agent_index, agent_strategy) และบั๊กที่เชื่อมโยง
• get_exploration_usage — ตรวจสอบการใช้งานรายเดือน Exploratory AI เฉพาะ Enterprise เท่านั้น Enterprise: ไม่จำกัด (10 เอเจนต์)

เวิร์กโฟลว์ตัวอย่าง

1. create_exploration พร้อม agent_count: 5 → กำหนดค่าเอเจนต์ขนาน 5 ตัว
2. เรียกใช้การรันจากแดชบอร์ดหรือผ่าน POST /api/explorations/run
3. get_exploration_run → รอความคืบหน้าต่อเอเจนต์และการค้นพบ
4. ดูการค้นพบที่ไม่ได้ทำซ้ำพร้อมการระบุแหล่งที่มาของเอเจนต์ในแดชบอร์ด

📝

บันทึก

• list_notes — แสดงรายการบันทึกพร้อมตัวกรองคำสำคัญ โปรเจกต์ การมองเห็น โฟลเดอร์ แท็ก ไฟล์เก็บถาวร wiki ช่วงวันที่ และการเรียงลำดับที่เป็นตัวเลือก ส่งคืนบันทึกที่ผู้ใช้เป็นเจ้าของหรือบันทึกที่แชร์กับพวกเขา
• create_note — สร้างบันทึกใน 1 ใน 5 รูปแบบ: markdown, plain, bugtemplate, checklist, outline ตั้งค่า visibility เป็น private หรือ shared ชื่อเรื่องอัตโนมัติจาก 30 ตัวอักษรแรกหากไม่มีชื่อเรื่องที่ให้ไว้ อาร์เรย์ attachments ที่เป็นตัวเลือกรับไฟล์ที่เข้ารหัส base64 สูงสุด 400 MB ต่อไฟล์: รูปภาพ วิดีโอ เสียง PDF หรือ text/JSON ผ่าน time_spent_seconds เพื่อติดตามความพยายาม QA
• get_note — รับรายละเอียดบันทึกเต็มรวมถึงเนื้อหาและไฟล์แนบ ต้องใช้ id
• update_note — อัปเดตชื่อเรื่อง เนื้อหา รูปแบบ การมองเห็น โปรเจกต์ หรือ time_spent_seconds ผ่านอาร์เรย์ attachments เพื่อเพิ่มไฟล์ใหม่ (สูงสุด 400 MB ต่อไฟล์) ไปยังไฟล์แนบที่มีอยู่ของบันทึกโดยไม่แทนที่ เฉพาะผู้เขียนเท่านั้นที่สามารถอัปเดตได้ ต้องใช้ id
• delete_note — ลบบันทึกและไฟล์แนบอย่างถาวร เฉพาะผู้เขียนเท่านั้นที่สามารถลบได้ ต้องใช้ id
• list_note_folders — แสดงรายการโฟลเดอร์บันทึก/wiki กำหนดขอบเขตตามโปรเจกต์ได้
• create_note_folder — สร้างโฟลเดอร์บันทึก/wiki ที่กำหนดขอบเขตตามโปรเจกต์พร้อมการตั้งค่าโฟลเดอร์หลัก การมองเห็น รายการโปรด และการเข้าถึงของเพื่อนร่วมทีมที่เป็นตัวเลือก

เวิร์กโฟลว์ตัวอย่าง

1. create_note → เริ่มบันทึกเซสชันการทดสอบ
2. update_note → เพิ่มข้อสังเกตขณะที่คุณทดสอบ
3. list_notes → ค้นหาบันทึกก่อนหน้าโดยคำสำคัญหรือโปรเจกต์
4. get_note → ดึงบันทึกเต็มพร้อมไฟล์แนบ

🤖

ระบบอัตโนมัติ

• create_automation — สร้างระบบอัตโนมัติใหม่ด้วยสคริปต์ Playwright ที่กำหนดเอง (ไม่ต้องมีการบันทึก FAB) ต้องใช้ name ไม่บังคับ: target_url (ดึงจาก URL page.goto(...) แรกในสคริปต์โดยอัตโนมัติหากไม่ระบุ), script (Node.js/JavaScript/TypeScript หรือ Python — ตรวจจับภาษาอัตโนมัติ; ค่าเริ่มต้นเป็นตัวยึดตำแหน่ง), status (draft หรือ active, ค่าเริ่มต้น: draft), project_id คืนค่า id ของระบบอัตโนมัติ เคล็ดลับ — ทำสำเนาระบบอัตโนมัติ: ใช้ get_automation เพื่อดึงสคริปต์ต้นฉบับ จากนั้นเรียก create_automation โดยตั้งค่า name เป็น "[Copy] Original Name" และส่ง script, target_url, และ project_id ต้นฉบับ สำเนาจะเริ่มต้นในสถานะ draft โดยไม่มีประวัติเวอร์ชัน
• list_automations — แสดงรายการสคริปต์ระบบอัตโนมัติ Playwright กรองตาม project_id หรือ status (draft, active, paused) คืนค่าอาร์เรย์ของระบบอัตโนมัติพร้อมชื่อ target_url, last_run_status และ run_count
• get_automation — รับรายละเอียดระบบอัตโนมัติทั้งหมดรวมถึงสคริปต์ Playwright และการรันล่าสุด ต้องใช้ id คืนค่าระบบอัตโนมัติพร้อม script ที่ใช้งานจริง, สแตก script_versions (เก่าที่สุดก่อน, สูงสุด 100 รายการก่อนหน้า, แต่ละรายการเป็น { script, source, timestamp }) และอาร์เรย์ recent_runs ซึ่งแต่ละการรันมี script_version_label / script_version_source ที่ดำเนินการ เรียกสิ่งนี้ก่อน run_automation หากคุณต้องการเลือกเวอร์ชันประวัติที่เฉพาะเจาะจง
• run_automation — เรียกใช้การทดสอบ Playwright ทันที ต้องใช้ automation_id ตัวระบุตำแหน่งที่ซ่อมแซมตัวเอง (อัตโนมัติ): เมื่อการดำเนินการตัวระบุตำแหน่งหมดเวลา ตัวรันจะถาม Claude สำหรับตัวเลือกที่ใช้งานได้และลองขั้นตอนนั้นอีกครั้งหนึ่งครั้ง — การยืนยันจะไม่ถูกซ่อมแซม ดังนั้นการถดถอยจริงจะยังคงล้มเหลว — และการซ่อมแซมแต่ละครั้งจะถูกบันทึกใน stdout ของการรัน โหมดจำลอง (ค่าเริ่มต้น): device ไม่บังคับสำหรับโปรไฟล์อุปกรณ์จำลอง (เช่น desktop, iphone-15) โหมดจริง: ตั้งค่า browserstack: true ด้วย bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X) และ bs_os_version เพื่อรันบนเบราว์เซอร์เดสก์ท็อปจริง มือถือจริง: ตั้งค่า bs_os: "android" (อุปกรณ์: "Samsung Galaxy S25 Ultra", "Google Pixel 10", "OnePlus 13R") หรือ bs_os: "ios" (อุปกรณ์: "iPhone 17 Pro Max", "iPhone 16 Pro Max", "iPhone 15 Pro Max") และส่งชื่ออุปกรณ์ใน bs_os_version ทั้งสองโหมดทำงานในเบื้องหลัง; จริงอธิบายสภาพแวดล้อมการดำเนินการ ไม่ใช่เซสชันโต้ตอบที่มองเห็นได้ สคริปต์ Node.js ผ่าน browserstack-node-sdk (ครอบคลุมเดสก์ท็อป + Android + iPhone) สคริปต์ Python ผ่าน browserstack-sdk (pytest-playwright) และครอบคลุมเดสก์ท็อปเท่านั้น — มือถือจริงผ่าน Python ไม่รองรับเพราะ browser_type.connect() ของ pytest-playwright ไม่สามารถขับเคลื่อนจุดสิ้นสุดมือถือจริงของ BrowserStack ได้ วิดีโอและบันทึกเครือข่ายถูกจับโดยอัตโนมัติ; บันทึกคอนโซลเฉพาะเดสก์ท็อป เล่นซ้ำเวอร์ชัน: ตรวจสอบ script_versions ด้วย get_automation จากนั้นส่ง version_label ที่ทนทานที่ต้องการ (ตัวอย่างเช่น "v103") version_index รุ่นเก่ายังคงรองรับ แต่ต้องไม่รวมกับ version_label ค่าเริ่มต้น: เมื่อละเว้นตัวเลือกทั้งสอง สคริปต์ที่บันทึกปัจจุบันจะทำงาน ป้ายกำกับที่ถูกตัดและดัชนีที่ไม่ถูกต้องจะถูกปฏิเสธแทนที่จะรันปัจจุบันอย่างเงียบ ๆ บันทึกการรันเก็บสแนปชอตที่แน่นอนที่รัน และรายงานบั๊กใด ๆ ที่สร้างอัตโนมัติจากการรันที่ล้มเหลวจะเชื่อมโยงลึกกลับไปยังเวอร์ชันนั้นในตัวแก้ไข
• list_automation_runs — แสดงรายการการรันล่าสุดสำหรับระบบอัตโนมัติ ต้องใช้ automation_id คืนค่าการรันพร้อมสถานะ duration_ms และ error_message
• list_schedules — แสดงรายการการรันระบบอัตโนมัติเว็บตามกำหนดการทั้งหมดพร้อม cron_expression ที่เป็นค่าว่างได้, run_at ที่เป็นค่าว่างได้, once_status, เขตเวลา, อุปกรณ์ และการตั้งค่าการแจ้งเตือน แถวที่เกิดซ้ำจะเก็บ run_at และ once_status เป็น null; แถวครั้งเดียวมี cron เป็น null สถานะครั้งเดียว: pending, claimed, missed, dispatched, failed, uncertain สิ่งเหล่านี้เป็นสถานะการจัดส่ง ไม่ใช่ผลการทดสอบ; ตรวจสอบ list_automation_runs สำหรับผลลัพธ์
• กำหนดการเว็บที่เกิดซ้ำ: create_schedule ตรวจสอบฟิลด์ cron ตัวเลขห้าฟิลด์และเขตเวลา และคืนค่า next_run_at UTC ในอนาคต รองรับการเกิดซ้ำรายเดือนและรายปี ตัวอย่างเช่น 30 12 23 9 * ใน America/Toronto หมายถึง 23 กันยายน เวลา 12:30 ทุกปี ไม่ใช่การรันครั้งเดียว เวลาที่ไม่ถูกต้องหรือเป็นไปไม่ได้จะถูกปฏิเสธก่อนการสร้าง เมื่อทั้งวันของเดือนและวันของสัปดาห์ถูกจำกัด ทั้งสองต้องตรงกัน เวลาออมแสงที่ไม่มีอยู่จะถูกข้าม; เวลานาฬิกาที่ซ้ำกันสามารถเกิดขึ้นได้สองครั้ง การจัดส่งเกิดขึ้นในการสำรวจครั้งถัดไปของตัวกำหนดเวลา ไม่จำเป็นต้องเป็นนาทีที่แน่นอน พฤติกรรมการเกิดซ้ำที่มีอยู่ไม่เปลี่ยนแปลง
• กำหนดการเว็บครั้งเดียว: เรียก create_schedule ด้วย { "automation_id": "AUTOMATION_UUID", "run_at": "2030-12-15T09:30:00-05:00", "timezone": "America/Toronto" }, เลือกวันที่ในอนาคตและละเว้น cron_expression ระบุฟิลด์เวลาหนึ่งฟิลด์เท่านั้น run_at ต้องใช้การประทับเวลา ISO 8601 ในอนาคตที่ระบุออฟเซ็ต (ออฟเซ็ตที่ชัดเจนหรือ Z); เขตเวลา IANA สำหรับการแสดงผล กำหนดการที่รอดำเนินการที่เปิดใช้งานจะดำเนินการในการสำรวจ cron ครั้งแรกหลังจากถึงกำหนด; ล่าช้ากว่าหนึ่งชั่วโมงจะถูกทำเครื่องหมายเป็น missed มันถูกอ้างสิทธิ์และปิดใช้งานโดยอะตอมก่อนการจัดส่ง และไม่สามารถเปิดใช้งานอีกครั้งเมื่อถูกใช้แล้ว ความล้มเหลวในการจัดส่งที่ชัดเจนคือ failed; การจัดส่งที่ไม่ชัดเจนคือ uncertain และไม่มีการลองใหม่โดยอัตโนมัติ ตรวจสอบการรันก่อนกำหนดเวลาความพยายามอื่น dispatched ไม่ได้หมายความว่าเสร็จสมบูรณ์หรือผ่าน การสร้างเป็น API/MCP เท่านั้น ไม่ใช่โหมดการสร้างแดชบอร์ดใหม่
• เขตเวลากำหนดการเว็บเป็นตัวระบุ IANA เช่น America/Argentina/Buenos_Aires ตัวเลือกแดชบอร์ดรวมถึงภูมิภาคและเมืองที่รองรับทั้งหมดของเซิร์ฟเวอร์และค่าเริ่มต้นเป็นเขตเวลาโปรไฟล์ของคุณ; ค่าเริ่มต้นเขตเวลา MCP ยังคงเป็น UTC
• create_schedule — สร้างการรันระบบอัตโนมัติเว็บตามกำหนดการ ต้องใช้ automation_id และหนึ่งใน cron_expression หรือ run_at เท่านั้น รองรับอุปกรณ์, เขตเวลา, การแจ้งเตือนความล้มเหลว, อีเมล และการตั้งค่าช่อง Slack ไม่บังคับ เชื่อมต่อ Slack ผ่านแดชบอร์ดก่อนและเลือกช่องที่บอทเป็นสมาชิก; การติดตั้งเว็บฮุคเพียงอย่างเดียวไม่เพียงพอ ดู การตั้งค่า Slack และการค้นพบช่อง
• การเปิดตัวครั้งเดียวและการกู้คืน: ใช้การย้ายฐานข้อมูล 374_one_time_web_schedules.sql ก่อนปรับใช้ API/MCP และโค้ดตัวกำหนดเวลาที่ตรงกัน claimed สามารถคงอยู่หลังจากการขัดข้องของเวิร์กเกอร์: ตรวจสอบประวัติการรันก่อนสร้างการแทนที่สำหรับการจัดส่งที่อ้างสิทธิ์หรือไม่ชัดเจน การประทับเวลาที่ล่าช้ากว่าหนึ่งชั่วโมงจะไม่ถูกดำเนินการโดยอัตโนมัติ
• ร่างระบบอัตโนมัติเว็บ: เปิดใช้งานระบบอัตโนมัติก่อนสร้างกำหนดการ, เปิดใช้งานกำหนดการอีกครั้ง หรือเปลี่ยนนิพจน์ cron หรือเขตเวลา create_schedule ตรวจสอบการเข้าถึงพื้นที่ทำงานและโปรเจกต์ก่อนปฏิเสธสถานะร่าง กำหนดการที่มีอยู่ข้ามรอบในขณะที่ระบบอัตโนมัติเป็นร่าง; การหยุดชั่วคราว, การลบ, การปักหมุด และการเปลี่ยนแปลงเฉพาะการแจ้งเตือนยังคงพร้อมใช้งาน ไม่มีเครื่องมือ MCP update_schedule เว็บ; ใช้แดชบอร์ดสำหรับการอัปเดตเหล่านั้น
• delete_schedule — ลบการรันระบบอัตโนมัติเว็บตามกำหนดการ
• list_mobile_schedules — แสดงรายการการรันระบบอัตโนมัติมือถือตามกำหนดการทั้งหมดพร้อมอุปกรณ์, cron, เขตเวลา และการแจ้งเตือน
• create_mobile_schedule — สร้างการรันระบบอัตโนมัติมือถือตามกำหนดการบนอุปกรณ์จริง ต้องใช้ automation_id และ cron_expression; devices ไม่บังคับ
• delete_mobile_schedule — ลบการรันระบบอัตโนมัติมือถือตามกำหนดการ
• optimize_automation_script — ส่งสคริปต์ Playwright ไปยัง Sonnet 4 เพื่อการเพิ่มประสิทธิภาพที่ขับเคลื่อนด้วย AI ใช้รายการตรวจสอบ 12 จุดที่แก้ไขตัวเลือก, กลยุทธ์การรอ, การยืนยัน, การจัดการข้อผิดพลาด, รูปแบบการรับรองความถูกต้อง, ความเข้ากันได้ของมือถือ และโหมดเข้มงวด ต้องใช้ automation_id เวอร์ชันสคริปต์ปัจจุบันจะถูกบันทึกก่อนการเพิ่มประสิทธิภาพ คืนค่าสคริปต์ที่เพิ่มประสิทธิภาพและสรุปการเปลี่ยนแปลง
• undo_automation_script — ย้อนกลับสคริปต์ระบบอัตโนมัติเป็นเวอร์ชันก่อนหน้า เก็บเวอร์ชันก่อนหน้าสูงสุด 100 เวอร์ชัน ต้องใช้ automation_id คืนค่าสคริปต์ที่กู้คืนและจำนวนเวอร์ชันที่เหลือ

เวิร์กโฟลว์ตัวอย่าง

1. create_automation → สร้างการทดสอบด้วยสคริปต์ที่กำหนดเอง
2. list_automations → เรียกดูการทดสอบที่มีอยู่
3. get_automation → ตรวจสอบสคริปต์ Playwright
4. run_automation → เรียกใช้การทดสอบ
5. list_automation_runs → ตรวจสอบผลลัพธ์และระยะเวลา

⏱️

การติดตามเวลา

• list_time_entries — แสดงรายการรายการเวลาสำหรับทีม กรองตาม period (today, week, month, all), project_id, category และ sort (newest, oldest, most_time, least_time) เฉพาะแผน Enterprise
• create_time_entry — บันทึกเวลาที่ใช้ในงาน QA ต้องใช้ description, category และ duration_minutes ไม่บังคับตั้งค่า project_id และ entry_date (ค่าเริ่มต้นเป็นวันนี้) เฉพาะแผน Enterprise
• update_time_entry — อัปเดตรายการเวลาที่มีอยู่ ต้องใช้ id สามารถอัปเดต description, category, duration_minutes, project_id หรือ entry_date เฉพาะแผน Enterprise
• delete_time_entry — ลบรายการเวลาอย่างถาวร ต้องใช้ id เฉพาะแผน Enterprise

เวิร์กโฟลว์ตัวอย่าง

1. create_time_entry → บันทึกการทดสอบการถดถอย 45 นาที
2. list_time_entries → ดูรายการเวลาของสัปดาห์นี้
3. update_time_entry → ปรับระยะเวลาหรือหมวดหมู่
4. delete_time_entry → ลบรายการที่ไม่ถูกต้อง

☑️

กรณีทดสอบ

การจัดการการทดสอบด้วยโฟลเดอร์แบบลำดับชั้น, ชุดทดสอบที่ซ้อนกัน (ลึกสูงสุด 3 ระดับพร้อมการขยายชุดย่อยอัตโนมัติในการรัน), การจัดลำดับใหม่แบบลากและวาง และแท็บรายงานการวิเคราะห์พร้อมแนวโน้ม KPI, การวิเคราะห์ความล้มเหลว, สุขภาพชุดทดสอบ, ความครอบคลุม และประสิทธิภาพของผู้ทดสอบ เครื่องมือทั้งหมดเรียก Supabase โดยตรง — ไม่มีการเดินทาง HTTP รอบเดียว, ความหน่วงเดียวกันกับแดชบอร์ด

ขีดจำกัดฟรี: กรณีทดสอบที่เก็บ 10 รายการ, 1 ชุดทดสอบ, 3 โฟลเดอร์, เนื้อหาโครงสร้าง 128 KB ต่อกรณี, คีย์ API พื้นที่ทำงานที่ใช้งาน 2 รายการ และการรันทดสอบทั้งหมด 10 ครั้งต่อเดือนปฏิทิน UTC สูงสุด 3 การรันเหล่านั้นอาจใช้ Hermes หรือตัวแทนภายนอกอื่น โดยมีการรันภายนอกที่ใช้งาน 1 รายการและสูงสุด 10 กรณีในแต่ละแผนภายนอก การรับส่งข้อมูล MCP คีย์ API ฟรีจำกัดที่ 30 คำขอต่อคีย์และ 60 ต่อพื้นที่ทำงานต่อนาที การจัดเก็บกรณีทดสอบและการรัน Enterprise ไม่จำกัด ภายใต้การป้องกันแพลตฟอร์มทั่วไป

การสร้างกรณีทดสอบด้วย AI, คำแนะนำแท็กด้วย AI, การนำเข้า Figma และไฟล์แนบกรณีทดสอบต้องใช้ Enterprise ขอบเขตเนื้อหาโครงสร้างฟรี 128 KB แยกจากการแนบไฟล์ Enterprise ฟรีสามารถเก็บการอ้างอิง URL เครื่องมือ MCP กรณีทดสอบหลักยังคงพร้อมใช้งานในฟรีภายใต้ขีดจำกัดข้างต้น

การดำเนินการแบบแฮนด์ฟรี: หน้ารีวิวการรันเป็นม้าหมุนโดยแสดงหนึ่งกรณีในแต่ละครั้ง, ปุ่มลัด (P ผ่าน · F ล้มเหลว · B บล็อก · S ข้าม) และ การควบคุมด้วยเสียง คลิกไมโครโฟน จากนั้นพูด "ผ่าน", "ล้มเหลว", "บล็อก", "ข้าม", "ถัดไป", "ก่อนหน้า", "เพิ่มบันทึก" (ถอดเสียงลงในช่องบันทึก), "บันทึกบันทึก" หรือ "ปิดเสียง" เลื่อนอัตโนมัติไปยังกรณีที่ยังไม่ได้ทดสอบถัดไปเมื่อผลลัพธ์สำเร็จ; คงอยู่ที่ล้มเหลวเพื่อให้ผู้ทดสอบสามารถบอกรายละเอียดและสร้างบั๊ก ทำงานใน Chrome, Edge และ Safari

กรณีและโฟลเดอร์

• list_test_cases — แสดงรายการเทสต์เคสที่เข้าถึงได้ พร้อมตัวเลือก project และตัวกรอง search, priority, type, status, และ sort เพิ่ม folder_id (null สำหรับ unfiled) หรือ suite_id สำหรับการเป็นสมาชิกโดยตรง โดยไม่มี descendant ผู้เรียกผ่าน API key ต้องใช้ test_cases:read ค่าเริ่มต้นของ limit คือ 50 (1-200); ค่าเริ่มต้นของ offset คือ 0 (0-1000000) อาร์เรย์ cases ที่ไม่เปลี่ยนแปลงจะมาพร้อมกับ total / total_count สำหรับผลลัพธ์ที่ตรงตามสิทธิ์ทั้งหมด, limit, offset, has_more, และ next_offset ที่เป็น nullable ก่อนหน้านี้ total หมายถึงความยาวหน้าเพจอย่างไม่ถูกต้อง ให้ทำตาม next_offset จนกว่าจะเป็น null; อย่าอนุมานว่าการแบ่งหน้าเสร็จสิ้นจากความยาวหน้าเพจ การดำเนินการต่อเกิน offset 1000000 จะล้มเหลวอย่างชัดเจน; ให้จำกัดตัวกรองแทนที่จะได้รับ cursor ที่ใช้ไม่ได้หรือการเสร็จสิ้นที่ผิดพลาด หน้าที่เกิน 1 MiB ของข้อมูลเคสจะล้มเหลวอย่างชัดเจน: ให้ลองใหม่ด้วย limit ที่เล็กลง แทนที่จะยอมรับเรกคอร์ดที่ถูกละเว้น มีการใช้การตัดสินเสมอด้วย ID ที่เสถียร แต่การแก้ไขพร้อมกันอาจทำให้หน้าของ offset เลื่อนได้
• ตัวอย่างการแบ่งหน้า: เรียก list_test_cases ด้วย {"project":"test-bed","limit":50,"offset":0} สำหรับผลลัพธ์ 55 รายการ การตอบสนองจะมี total:55, has_more:true, next_offset:50 ทำซ้ำด้วย offset:50 สำหรับห้ารายการที่เหลือและ has_more:false, next_offset:null
• create_test_case — สร้างเทสต์เคสในตัวเลือก project ที่จำเป็น (UUID, slug, ชื่อที่แน่นอน, หรือคำนำหน้าตั๋ว; เรียก list_projects ก่อน) มีสองรูปแบบเทมเพลต: steps (ค่าเริ่มต้น) — ตาราง { action, expected } แบบรายขั้นตอนผ่านอาร์เรย์ steps; text — คำอธิบายแบบอิสระเดียวผ่าน text_content ทั้งสองฟิลด์สามารถส่งได้ในการเรียกเดียวกัน อาร์เรย์ urls ที่ไม่บังคับ (สูงสุด 10 URL http/https) แนบลิงก์อ้างอิงและใช้ได้ในแผน Free ไฟล์แนบต้องใช้ Enterprise และเซสชันแดชบอร์ด ผู้เรียกผ่าน API key ต้องใช้ test_cases:write
• การกู้คืนการแบ่งหน้า: การขอ offset ของเคสที่เกินผลลัพธ์ที่มีอยู่จะส่งคืนข้อผิดพลาดอย่างชัดเจน; ให้เริ่มใหม่ที่ offset 0 สิ่งนี้สามารถเกิดขึ้นได้เมื่อเคสถูกลบระหว่างคำขอ ให้ทำตาม continuation ที่ส่งคืนแทนการเดา offset ถัดไป
• ตัวระบุเคส: list_test_cases, get_test_case, create_test_case, และ update_test_case ส่งคืน UUID id, short_id ที่ไม่เปลี่ยนรูป (ตัวอย่างเช่น TEST-BA-CASE-123), และ case_number เชิงตัวเลข รวมถึงการตอบสนองแบบ compact update/no-op เคสแบบ legacy ที่ไม่มีโปรเจกต์ใช้ TEST-CASE-123 ตัวระบุที่หายไปจะถูกส่งคืนเป็น null; ให้ใช้ UUID เป็นตัวสำรอง ฐานข้อมูลเป็นผู้กำหนดตัวระบุ; ผู้เรียกไม่สามารถเปลี่ยนแปลงหรือเลือกได้ในระหว่างการสร้าง การเปลี่ยนคำนำหน้าไม่เขียนทับ ID ที่มีอยู่
• การค้นหาเคสเดียว: get_test_case และ update_test_case รับ UUID หรือ short ID เต็มใน id; link_test_case_to_bug และ list_test_case_links รับอย่างใดอย่างหนึ่งใน case_id ช่องว่างรอบข้าง ตัวพิมพ์ใหญ่เล็ก และการเติมตัวเลขจะถูกทำให้เป็นมาตรฐานก่อนการค้นหาที่แน่นอนในเวิร์กสเปซที่ใช้งานอยู่ การอนุญาตใช้เวิร์กสเปซและโปรเจกต์ที่จัดเก็บไว้ ไม่ใช่คำนำหน้า ID ตัวเลขเปล่า ID บางส่วน และการค้นหาแบบ wildcard ไม่ได้รับการยอมรับ อาร์เรย์เคสแบบกลุ่ม, case_id ของผลการดำเนินการ, ID บั๊ก, ID โฟลเดอร์ และ ID ชุดทดสอบยังคงเป็น UUID เท่านั้น เรกคอร์ดลิงก์เก็บ UUID case_id ไว้
• ช่องว่างการนับเลข: หมายเลขเคสไม่จำเป็นต้องต่อเนื่องกัน การแก้ไข URL หรือการเพิ่มตัวเลขอาจทำให้เคสหายไปหรือเข้าถึงไม่ได้; ไม่ใช่การดำเนินการที่รับประกันว่าจะได้เคสถัดไป ค้นพบเคสด้วยเครื่องมือรายการและทำตามการแบ่งหน้า
• ขอบเขตเวิร์กสเปซ: short ID เดียวกันสามารถมีอยู่ในเวิร์กสเปซที่ต่างกัน MCP แก้ไขเฉพาะในเวิร์กสเปซที่ใช้งานอยู่; สลับบริบทเวิร์กสเปซก่อนใช้ short ID ของเวิร์กสเปซอื่น เมื่อแชร์ URL short ID ของแดชบอร์ด ให้รักษา ?team=<case.team_id> ไว้ ตัวอย่างเช่น /dashboard/test-cases/TEST-BA-CASE-123?team=<team-uuid> ลิงก์ถาวร UUID ยังคงพฤติกรรมข้ามเวิร์กสเปซที่ได้รับอนุญาตที่มีอยู่ MCP ไม่สร้างลิงก์ถาวร
• get_test_case — รับเรกคอร์ดเคสที่ได้รับอนุญาต รวมถึงขั้นตอนและตัวระบุ ไม่โหลดประวัติการเปลี่ยนแปลงหรือประวัติการดำเนินการ ตัวอย่าง: {"id":"TEST-BA-CASE-123"}
• การประมาณเวลาดำเนินการ: get_test_case ส่งคืน estimated_time_seconds และนามแฝงความเข้ากันได้ estimated_time ทั้งคู่เป็นวินาที ค่า 0 ที่จัดเก็บไว้ยังคงเป็น 0; ค่าที่ไม่รู้จักหรือหายไปคือ null ฟิลด์หลักชนะเมื่อมีทั้งสองชื่อ รวมถึง null ที่ชัดเจน; ค่า estimated_time แบบ legacy เท่านั้นถือเป็นวินาทีโดยไม่มีการแปลง list_test_cases ใช้ estimated_time_seconds อินพุต create_test_case ยังคงเป็น estimated_time ในหน่วยวินาทีเช่นกัน; คำขอและการตอบสนอง REST ใช้ estimated_time_seconds
• list_test_case_folders — แสดงรายการโฟลเดอร์ที่เข้าถึงได้ จำกัดที่ 500; รับตัวเลือก project ที่ยืดหยุ่นและตัวกรอง parent_folder_id (ใช้ "root" สำหรับระดับบนสุดเท่านั้น) ผู้เรียกผ่าน API key ต้องใช้ test_cases:read
• get_test_case_folder — อ่านโฟลเดอร์เทสต์เคสหนึ่งโฟลเดอร์โดยตรงด้วย id ที่จำเป็น (UUID) ส่งคืนเฉพาะเรกคอร์ดโฟลเดอร์ โดยไม่โหลดโฟลเดอร์ descendant หรือเทสต์เคสโดยปริยาย ต้องเข้าถึงเวิร์กสเปซและโปรเจกต์ของมัน; ผู้เรียกผ่าน API key ต้องใช้ test_cases:read
• ค่า type ของเทสต์เคสสำหรับ list_test_cases, create_test_case, และ bulk_update_test_cases: functional (ค่าเริ่มต้นการสร้าง), regression, smoke, integration, performance, security, usability, exploratory ประเภทที่ไม่ถูกต้องจะถูกปฏิเสธก่อนการเขียน ใช้ integration สำหรับโฟลว์แบบ end-to-end; e2e, accessibility, และ other ไม่ใช่ประเภทเทสต์เคสที่ยอมรับ ประเภทสคริปต์อัตโนมัติเป็นสัญญาแยกต่างหาก
• create_test_case_folder — สร้างโฟลเดอร์ใน project ที่จำเป็นซึ่งส่งคืนโดย list_projects (ซ้อนได้สูงสุด 3 ระดับผ่าน parent_folder_id) ต้องมีสิทธิ์เข้าถึงเวิร์กสเปซระดับ contributor หรือสูงกว่าและการเข้าถึงโปรเจกต์ ผู้เรียกผ่าน API key ต้องใช้ test_cases:write ด้วย
• update_test_case_folder — อัปเดตด้วย UUID โฟลเดอร์: id, name ที่ไม่บังคับ (ตัดช่องว่าง 1-120 ตัวอักษร), description ที่เป็น nullable (สูงสุด 50000 ตัวอักษร), parent_folder_id ที่เป็น nullable, และ card_color ที่เป็น nullable UUID หลักย้ายโฟลเดอร์และซับทรีภายในเวิร์กสเปซและโปรเจกต์เดียวกัน; null ย้ายไปที่ราก สีรับชุดสีตัวพิมพ์เล็ก #1e293b, #7c2d12, #713f12, #14532d, #1e3a5f, #312e81, #581c87, #831843, #4a044e, #fef08a, #fca5a5, #93c5fd; null ล้างสี ฟิลด์ที่ละเว้นจะถูกรักษาไว้ ต้องมีฟิลด์อัปเดตอย่างน้อยหนึ่งฟิลด์ ฟิลด์ที่ไม่รู้จัก สะกดผิด หรือไม่ถูกต้องจะปฏิเสธคำขอทั้งหมดโดยไม่บันทึกการเปลี่ยนแปลงใดๆ วงจรตัวเอง/descendant ชื่อที่ตรงกับ sibling พ่อแม่โดยตรง หรือลูกโดยตรง (ไม่สนใจตัวพิมพ์เล็กใหญ่และช่องว่างรอบข้าง) และความลึกซับทรีที่เกิน 3 (ความลึกราก 0) จะถูกปฏิเสธ ความลึกของ descendant อัปเดตแบบอะตอม; ID เคสและการเป็นสมาชิกไม่เปลี่ยนแปลง การเปลี่ยนแปลงพร้อมกันที่ขัดแย้งอาจล้มเหลว; อ่านโฟลเดอร์อีกครั้งก่อนลองใหม่ ต้องมีสิทธิ์เข้าถึงโปรเจกต์ระดับ contributor หรือสูงกว่าและ test_cases:write สำหรับคีย์ API ตัวอย่าง: {"id":"folder-uuid","card_color":"#93c5fd"} ส่งคืน id, team_id, project_id, name, description, card_color, parent_folder_id, depth และ updated_at ที่อัปเดต การอ่านโฟลเดอร์แบบ get/list รวม card_color ด้วย
• update_test_case — แก้ไขเคสที่มีอยู่ด้วย UUID หรือ full short ID ใน id โดยมีอย่างน้อยหนึ่งฟิลด์: name (หรือนามแฝง title), description, preconditions, steps, template_type, text_content, priority, type, status, หรือ folder_id ฟิลด์ที่ละเว้นจะถูกรักษาไว้; steps แทนที่อาร์เรย์ทั้งหมด ([] ล้าง) null ที่ชัดเจนล้างคำอธิบาย เงื่อนไขเบื้องต้น text_content หรือการวางโฟลเดอร์; text_content ว่างก็ล้างเช่นกัน หากส่งทั้ง name และ title ต้องตรงกัน ลำดับความสำคัญและประเภทใช้ enum การสร้าง; สถานะคือ active, draft, หรือ deprecated การเปลี่ยนประเภทจัดแนว type_tags กับประเภทใหม่ ตรงกับ PATCH API ไม่มีการย้ายเวิร์กสเปซ/โปรเจกต์หรือการเขียน metadata ไฟล์ โฟลเดอร์ต้องใช้เวิร์กสเปซและโปรเจกต์ที่แน่นอนเดียวกัน ต้องใช้ test_cases:write ส่งคืนสรุปเคส, id, short_id, case_number, และ changed; ค่าที่ไม่เปลี่ยนแปลงสร้าง changed: false การอัปเดตที่ยืนยันแล้วพร้อมรายการประวัติที่ไม่ได้รับการยืนยันส่งคืน warnings; อย่าทำการอัปเดตซ้ำเพื่อซ่อมแซมประวัติ เมื่อเกิดข้อผิดพลาดการเปลี่ยนแปลงพร้อมกัน ให้อ่านเคสอีกครั้งก่อนลองใหม่ การเป็นสมาชิกชุดทดสอบแยกต่างหาก: ใช้เครื่องมือกลุ่มด้านล่าง ไม่ใช่ suite_id ในเครื่องมือนี้ ไม่มีเครื่องมือลบที่เปิดเผย
• bulk_update_test_cases — ใช้การกระทำหนึ่งกับ UUID เคส 1–500 รายการ; ส่ง ID หนึ่งรายการสำหรับเคสเดียว set_folder รับ params.folder_id (UUID ที่จะย้าย, null ที่ชัดเจนเพื่อ unfile) add_to_suite และ remove_from_suite รับ params.suite_id; การเพิ่มไม่เคยลบการเป็นสมาชิกอื่นหรือย้ายโฟลเดอร์ รองรับ set_priority, set_status, set_type, add_tags, remove_tags, pin, และ unpin ด้วย คีย์ API ต้องใช้ test_cases:write ส่งคืน applied, skipped, และ errors; การกระทำขององค์กรนับแถวที่เปลี่ยนแปลงที่ยืนยันแล้ว ตัด ID ที่ซ้ำกัน และข้ามการเป็นสมาชิกที่มีอยู่
• การวางตำแหน่งเมื่อสร้าง: create_test_case รับ folder_id และ suite_id ที่ไม่บังคับ ค้นพบเป้าหมายด้วย list_test_case_folders และ list_test_suites (การค้นพบชุดทดสอบต้องใช้ test_runs:read สำหรับคีย์ API) โฟลเดอร์เป็นตำแหน่งแคตตาล็อกเดียว; ชุดทดสอบเป็นการเป็นสมาชิกแผนการทดสอบแบบหลายต่อหลาย เป้าหมายต้องอยู่ในเวิร์กสเปซที่ได้รับอนุญาตเดียวกันและโปรเจกต์ที่แน่นอน รวมถึงเคส legacy ที่ไม่มีขอบเขต ID เคสที่เข้าถึงไม่ได้จะถูกข้ามโดยไม่มีรายละเอียด; เป้าหมายที่ไม่ตรงกันจะถูกปฏิเสธ เป้าหมายการสร้างที่ไม่ถูกต้องล้มเหลวก่อนสร้างเคส
• การสร้างบางส่วน: การสร้างเคสและการแนบชุดทดสอบเป็นการเขียนแยกกัน หากการแนบล้มเหลว การตอบสนองส่งคืน ID เคสที่สร้าง, suite_id: null, และอาร์เรย์ warnings อย่าทำ create_test_case ซ้ำ; ลอง bulk_update_test_cases ใหม่ด้วย add_to_suite สำหรับ ID ที่ส่งคืนนั้น
• link_test_case_to_bug — สร้างความสามารถในการติดตามระหว่างเทสต์เคสและ UUID รายงานบั๊ก (verified_by, covers, หรือ relates) เรกคอร์ดทั้งสองต้องอยู่ในเวิร์กสเปซที่ใช้งานอยู่และโปรเจกต์ที่ผู้เรียกเข้าถึงได้
• list_test_case_links — แสดงรายการลิงก์การติดตามทั้งหมดสำหรับเทสต์เคส
• list_test_case_review_candidates — แฟลกเคสที่ตายแล้ว: never_run (90+ วันนับตั้งแต่สร้าง), always_passes (ผ่านติดต่อกัน 5+ ครั้งใน 90 วัน), always_skipped (ข้ามติดต่อกัน 3+ ครั้ง)
• mark_test_case_review_flags — บันทึกแฟลกผู้สมัครเก็บถาวรปัจจุบันลงใน test_cases.review_flag ทำงานอัตโนมัติทุกวันจันทร์ 09:00 UTC ผ่าน pg_cron

การนำเข้า

• การนำเข้า Figma (Enterprise) (เฉพาะเซสชันแดชบอร์ด): อัปโหลดไฟล์ zip ที่ส่งออกจากเฟรม Figma (สูงสุด 100 MiB), Claude วิเคราะห์แต่ละหน้าจอและร่างเทสต์เคสลงในโฟลเดอร์ที่คุณเลือกหรือสร้าง ก่อนการถอดรหัส ไฟล์เก็บถาวรจำกัดที่ 1,000 รายการ, 20 MiB ขยาย (ถอดรหัส) ต่อรายการ, และข้อมูลขยายรวม 100 MiB รวมถึงไฟล์และไดเรกทอรีที่ถูกละเว้นในงบประมาณ บัฟเฟอร์เฟรมที่ถอดรหัสต้องตรงกับขนาดที่ประกาศ ไฟล์เก็บถาวรที่เสียหาย ขนาดไม่ตรงกัน และเกินขีดจำกัดทำให้งานล้มเหลวก่อนการวิเคราะห์ AI; อัปโหลดต้นฉบับจะถูกเก็บไว้เมื่อล้มเหลวเพื่อลองใหม่ ภายใต้นโยบายการล้างพื้นที่จัดเก็บ ไฟล์เก็บถาวรที่ถูกต้องเข้าสู่ไปป์ไลน์หลายรอบ (จัดประเภท → เคสรายหน้าจอ → เคสระดับโฟลว์ข้ามหน้าจอที่มีคำนำหน้าร่วม → วิจารณ์ตนเอง) พร้อมแคชพรอมต์, การลองใหม่ 429, และการแยกข้อผิดพลาด AI ต่อเฟรม เคสจะถูกสร้างเป็น status=active, แท็ก ai_generated=true, ด้วย source='figma' และ source_frame_name ที่รักษาลิงก์ไปยังเฟรมต้นฉบับ ใช้คีย์ Anthropic ของแพลตฟอร์ม — ไม่ต้องเชื่อมต่อ Claude ต่อทีม

ชุดทดสอบและการรัน

• list_test_suites — แสดงรายการชุดทดสอบที่เข้าถึงได้สูงสุด 50 รายการ พร้อมตัวกรอง project แบบยืดหยุ่นตามต้องการ ชุดทดสอบแต่ละชุดมี case_count จำนวนเต็มที่แม่นยำ: จำนวนเคสที่ถูกกำหนดโดยตรงในทุกสถานะ โดยไม่รวมเคสย่อย และไม่รวมเคสจากเวิร์กสเปซหรือโปรเจกต์อื่น (เคสเก่าที่ไม่มีโปรเจกต์ยังคงถูกรวมอยู่) จำนวนไม่ถูกจำกัดด้วยแถวสมาชิกที่ดึงมา ผู้เรียกใช้ผ่าน API-key ต้องมี test_runs:read เพื่อความเข้ากันได้ย้อนหลังกับเวิร์กเกอร์ที่ใช้ดำเนินการ
• get_test_suite — อ่านชุดทดสอบหนึ่งชุดโดยตรง พร้อมระบุ id ที่จำเป็น (UUID) คืนค่าเฉพาะระเบียนชุดทดสอบเท่านั้น โดยไม่โหลดชุดย่อยหรือเคสทดสอบสมาชิกโดยปริยาย ต้องมีการเข้าถึงเวิร์กสเปซและโปรเจกต์ของชุดทดสอบนั้น ผู้เรียกใช้ผ่าน API-key ต้องมี test_runs:read
• create_test_suite — สร้างชุดทดสอบใน project ที่จำเป็นซึ่งคืนค่าจาก list_projects รองรับการซ้อนได้สูงสุด 3 ระดับผ่าน parent_suite_id ผู้เรียกใช้ผ่าน API-key ต้องมี test_cases:write
• update_test_suite — อัปเดตตาม UUID ของชุดทดสอบ: id, name ไม่บังคับ (ตัดช่องว่างแล้ว 1–120 ตัวอักษร), description ที่เป็น null ได้ (สูงสุด 50000 ตัวอักษร) และ status (active/archived) ฟิลด์ที่ละเว้นและสมาชิกเคสจะถูกคงไว้ ต้องมีการเข้าถึงโปรเจกต์ในระดับ contributor-or-higher ที่ยังใช้งานอยู่ และ test_cases:write ไม่รองรับการย้ายชุดทดสอบไปอยู่ภายใต้ชุดอื่นหรือการปักหมุด การย้ายชุดทดสอบต้องมีการบำรุงรักษาความลึกของเคสย่อยแบบอะตอมมิก คืนค่า id, team_id, project_id, name, description, parent_suite_id, depth, status และ updated_at ตัวอย่าง: {"id":"suite-uuid","name":"Checkout regression","description":null}
• list_test_runs — แสดงรายการรันการทดสอบพร้อมชื่อชุดทดสอบ ผู้รับผิดชอบ และสรุปผ่าน/ไม่ผ่าน
• create_test_run — สร้างรันชุดทดสอบที่จัดการผ่านแดชบอร์ด การรันชุดทดสอบหลักจะรวมทุกเคสในชุดย่อยทุกระดับโดยอัตโนมัติ (เคสที่เชื่อมโยงกับทั้งสองชุดจะถูกเพิ่มเพียงครั้งเดียว) แต่ละแถว test_run_results จะบันทึกว่าชุดย่อยต้นทางใดที่เคสมาจาก เพื่อให้หน้าผลลัพธ์สามารถจัดกลุ่มตามต้นทางได้

การดำเนินการโดยเอเจนต์ภายนอก

เครื่องมือเหล่านี้ช่วยให้ Hermes หรือรันไทม์เอเจนต์อื่นดำเนินการชุดทดสอบที่ได้รับการอนุมัติโดยไม่ต้องเป็นระบบบันทึก QA หลัก ใช้คีย์แบบ workspace-scoped ที่มีเฉพาะ test_runs:read และ test_runs:write เท่านั้น ชุดทดสอบเป็นตัวกำหนดขอบเขตโปรเจกต์ ผู้เรียกใช้ไม่สามารถแทนที่ได้

• start_test_plan — เริ่มหรือดำเนินการต่อสแนปช็อตชุดทดสอบที่ไม่เปลี่ยนรูป พร้อม external_run_id ที่เสถียร การใช้ ID ซ้ำจะคืนค่ารันที่ตรงกันที่มีอยู่และหน้าแรกแทนการสร้างรายการซ้ำ
• get_test_run_plan — อ่านสถานะรันตามมาตรฐานและหน้าแผนที่เสถียร ส่ง next_cursor ก่อนหน้า หน้าต่างๆ มีค่าเริ่มต้น 100 เคสและจำกัดสูงสุด 200 เคส
• report_test_results — ส่งผลลัพธ์ 1–200 รายการ พร้อมสถานะ passed, failed, blocked หรือ skipped การลองซ้ำแบบเหมือนเดิมปลอดภัย การพยายามเขียนทับเคสด้วยสถานะอื่นจะถูกปฏิเสธ
• abort_test_run — หยุดรันที่ถูกขัดจังหวะแบบ idempotent พร้อมคงผลลัพธ์บางส่วนที่ยอมรับและสรุปตามมาตรฐานไว้

พฤติกรรมโควตา: ลอง start_test_plan อีกครั้งด้วย external_run_id เดียวกันเพื่อดำเนินการต่อรันที่ตรงกันโดยไม่ใช้โควตาการรันเพิ่ม การลบข้อมูลไม่รีเซ็ตการใช้งานรันรายเดือน

ขอบเขตรันไทม์: สแนปช็อตเคสไม่รวมข้อมูลรับรอง เนื้อหาไฟล์ และเส้นทางไฟล์แนบส่วนตัว หลักฐานผลลัพธ์เป็นข้อความใน MVP ข้อมูลรับรองเป้าหมายยังคงอยู่ในรันไทม์การดำเนินการ ค่าใช้จ่ายเบราว์เซอร์ โมเดล และเครือข่ายยังคงเป็นฝ่ายลูกค้า และลูกค้าต้องจำกัดการเข้าถึงเป้าหมายและการส่งออกเครือข่าย มนุษย์ยังคงรับผิดชอบการตัดสินใจเกี่ยวกับข้อบกพร่องและการเผยแพร่

คู่มือ Hermes Agent จัดแพ็กเกจลูปนี้เป็นสกิลชุมชนที่ดูแลโดย bugAgent ชุดเริ่มต้นสาธารณะ มีคอนฟิกที่พร้อมคัดลอกและสกิลที่ติดตั้งได้ ไม่ใช่การผสานรวมอย่างเป็นทางการของ Nous Research

รายงาน (Tier 1 + Tier 4 analytics)

• get_test_reports_overview — KPI หลักสำหรับช่วงเวลา (อัตราผ่าน จำนวนรันที่เสร็จสิ้น จำนวนเคสที่ดำเนินการ) พร้อมส่วนต่างเทียบกับช่วงเวลาก่อนหน้าที่เทียบเท่า ตัวเลขเดียวกันกับแถบ KPI ในแท็บรายงาน ไม่สร้าง Project Report ที่บันทึก Enterprise XLSX Project Reports และกำหนดการจัดการในแดชบอร์ด ไม่มีเครื่องมือ MCP สำหรับอาร์ติแฟกต์ที่บันทึกเหล่านั้นในรุ่นนี้
• get_test_reports_failures — รายการ "สิ่งที่ต้องแก้ไข?" สี่รายการ: failing_cases (ล้มเหลว ≥50% ขั้นต่ำ 3 รัน), flaky_cases (พลิกผ่าน/ไม่ผ่านมากที่สุด), failing_suites (ล้มเหลว ≥30% ขั้นต่ำ 5 รัน), regressed_cases (ล้มเหลวล่าสุดโดยมีผ่านก่อนหน้าในช่วงเวลา)

เวิร์กโฟลว์ตัวอย่าง

1. create_test_case_folder → สร้างโครงสร้างโฟลเดอร์ (เช่น Smoke → Auth) ใช้ ID โฟลเดอร์ที่คืนค่าเมื่อสร้างเคสทดสอบในโปรเจกต์เดียวกัน ฟอร์ม New Test Case ในแดชบอร์ดยังมีการสร้างโฟลเดอร์แบบอินไลน์ด้วย
2. create_test_case → กำหนดเคส แก้ไขเนื้อหาด้วย update_test_case จัดการสมาชิกชุดทดสอบด้วย bulk_update_test_cases
3. ตัวอย่างเครื่องมือ/การเรียก: {"name":"update_test_case","arguments":{"id":"00000000-0000-4000-8000-000000000001","title":"Verify login rejection","steps":[{"action":"Submit an incorrect password","expected":"An error is shown; no session is created"}],"status":"active","folder_id":null}} ฟิลด์ priority, type และ description ที่ละเว้นจะไม่เปลี่ยนแปลง
4. create_test_suite → สร้างแผนการทดสอบ (ชุดย่อยไม่บังคับ สูงสุด 3 ระดับลึก)
5. create_test_run → สร้างรันที่จัดการโดยมนุษย์/แดชบอร์ดจากชุดหลัก — ชุดย่อยถูกรวมอัตโนมัติ
6. start_test_plan → เริ่มหรือดำเนินการต่อรันเอเจนต์ภายนอกที่ปลอดภัยต่อการลองซ้ำ
7. get_test_run_plan → ดึงทุกหน้าแผนที่ไม่เปลี่ยนรูป จากนั้นดำเนินการในรันไทม์ที่เลือก
8. report_test_results → ส่งชุดผลลัพธ์ที่มีขอบเขต เรียก abort_test_run หากไม่สามารถดำเนินการต่อได้อย่างปลอดภัย
9. get_test_reports_failures → ถาม "จะแก้ไขอะไรสัปดาห์นี้?" เมื่อรันเสร็จสิ้น
10. get_test_reports_overview → ติดตามแนวโน้มอัตราผ่านสัปดาห์ต่อสัปดาห์

⚡

Team Booster

• scale_team — ขยายทีม QA ของคุณทันทีด้วยผู้ทดสอบ booster บัญชีถูกจัดเตรียมโดยอัตโนมัติพร้อมสิทธิ์ผู้ทดสอบ ระบุ team_size (1–10), location, duration, budget และไม่บังคับ product_url, product_types และ tech_levels มีให้ในแผน Enterprise คุณจะไม่ถูกเรียกเก็บเงินจนกว่าจะได้รับการอนุมัติ

เวิร์กโฟลว์ตัวอย่าง

1. scale_team → จัดเตรียมผู้ทดสอบอาวุโส 5 คนในสหรัฐอเมริกาเป็นเวลา 1 เดือน
2. list_team_members → ตรวจสอบว่าผู้ทดสอบใหม่ปรากฏในทีมของคุณ
3. list_bug_reports → ตรวจสอบรายงานที่ส่งโดยผู้ทดสอบ booster

📱

การทดสอบบนมือถือ (Enterprise)

ทรัพยากรมือถือถูกจำกัดขอบเขตตามโปรเจกต์ ส่ง project_id หรือตัวเลือก project แบบยืดหยุ่นในการสร้าง นำเข้า และรายการที่กรองแล้ว อัตโนมัติสืบทอดโปรเจกต์ของแอปที่เชื่อมโยง มิฉะนั้นเซิร์ฟเวอร์ใช้โปรเจกต์เริ่มต้นของเวิร์กสเปซ รายการที่ไม่กรองอาจยังรวมแถวระดับเวิร์กสเปซเก่าจนกว่าจะถูกย้าย

• list_mobile_apps — แสดงรายการแอปที่อัปโหลด พร้อมตัวกรอง project_id / project, platform และ limit แบบไม่บังคับ ผลลัพธ์จะคืนค่า project_id ของแต่ละแอป เพื่อให้เอเจนต์สามารถดำเนินการถัดไปในโปรเจกต์เดียวกันได้
• upload_mobile_app — ลงทะเบียนแอป APK (Android) หรือ IPA (iOS) สำหรับการทดสอบบนอุปกรณ์จริง ต้องระบุ name, platform (android / ios) และ file_url; ส่ง project_id เพื่อกำหนดให้แอปอยู่ในโปรเจกต์ที่ใช้งานอยู่ สำหรับ iOS ให้อัปโหลด IPA สำหรับการรันบนอุปกรณ์จริง จากนั้นใช้แดชบอร์ดเพื่ออัปโหลดบิลด์ .app ของซิมูเลเตอร์สำหรับการบันทึก
• update_mobile_app — แทนที่ไบนารีของแอปด้วยเวอร์ชันใหม่ ล้างแคช URL และบิลด์ซิมูเลเตอร์ เพื่อให้ระบบอัตโนมัติทั้งหมดใช้เวอร์ชันใหม่ในการรันครั้งถัดไป ต้องระบุ app_id และ file_url; ไม่บังคับ: version โปรไฟล์การเข้าสู่ระบบแบบลิงก์ส่วนตัวต้องมีผู้สร้างที่ใช้งานอยู่ โปรไฟล์ที่แชร์ต้องมีการเข้าถึงโปรเจกต์เดียวกันอย่างใช้งานอยู่ ตารางเวลาจะสืบทอดค่าเริ่มต้นของระบบอัตโนมัติที่ได้รับการป้องกัน
• list_mobile_automations — แสดงรายการระบบอัตโนมัติบนมือถือ พร้อมตัวกรอง project_id / project, app_id, status และ limit แบบไม่บังคับ ผลลัพธ์รวมถึง project_id และ ID แอปที่เชื่อมโยง
• create_mobile_automation — สร้างสคริปต์ทดสอบ ต้องระบุ name, app_id, script_type (maestro สำหรับ YAML, appium สำหรับ Appium Python, appium_js สำหรับ Appium JavaScript) และ script; ส่ง project_id เมื่อแอปยังไม่ได้อยู่ในขอบเขตโปรเจกต์ สำหรับโฟลว์ Maestro YAML ที่ผ่านการตรวจสอบภายนอกและเป็นแบบครบถ้วนในตัวเอง ตั้งค่า execution_mode เป็น browserstack_maestro; มิฉะนั้นจะใช้ค่าเริ่มต้นเป็น appium_actions ค่า appId ของ YAML ต้องตรงกับแพ็กเกจหรือ bundle ID ที่เก็บไว้ของแอปที่เชื่อมโยง หากไม่มีค่าที่เก็บไว้ โฟลว์เนทีฟที่ผ่านการตรวจสอบครั้งแรกจะเป็นตัวกำหนดค่า ID แอปที่เป็นตัวแทนและ ID ทรัพยากร Android ที่ถูกบดบังจะถูกปฏิเสธ รองรับ runFlow แบบอินไลน์ แต่การอ้างอิงไฟล์โฟลว์/สคริปต์ภายนอกถูกปฏิเสธใน v1 Maestro เนทีฟจะรักษาคำสั่งเช่น inputRandomText และ copyTextFrom รวมถึงนิพจน์รันไทม์เช่น ${maestro.copiedText} และ ${output.value} ค่า credential_id ในโปรเจกต์เดียวกันอาจระบุค่า inputText ที่สมบูรณ์ของ ${USERNAME} / ${PASSWORD} ค่า variable_profile_id ในโปรเจกต์เดียวกันอาจบันทึกค่าเริ่มต้นสำหรับค่า ${DATA_*} ที่อ้างอิง; ทุกคีย์ที่อ้างอิงต้องมีอยู่ โปรไฟล์ข้อมูลเป็นข้อมูลสังเคราะห์ที่ไม่เป็นความลับเท่านั้น
• import_mobile_script — นำเข้าสคริปต์ทดสอบบนมือถือที่มีอยู่และแปลงเป็นระบบอัตโนมัติที่รันได้ โดยรักษา locators ของนักพัฒนาเดิมเพื่อให้การรันแก้ไของค์ประกอบได้อย่างแม่นยำ ไดอะเล็กต์ที่รองรับ: Appium‑Python, WebdriverIO, Maestro (โฟลว์ YAML) และ Playwright (มือถือ‑เว็บ) ตัวแทน ID ทรัพยากร Android ที่ถูกบดบังจะถูกข้ามและรายงานใน warnings ของการแมปตัวเลือก เฉพาะแอป Android ต้องระบุ name, app_id และ script; ไม่บังคับ target_devices และ project_id คืนค่าระบบอัตโนมัติพร้อม action_count, dialect ที่ตรวจพบ และ warnings ของการแมปตัวเลือก
• run_mobile_automation — เริ่มระบบอัตโนมัติบนมือถือบนอุปกรณ์จริง ต้องระบุ automation_id; ไม่บังคับ device, os_version, credential_id และ variable_profile_id แบบเนทีฟ-Maestro สำหรับข้อมูล ละเว้น variable_profile_id เพื่อสืบทอดค่าเริ่มต้นของระบบอัตโนมัติ ส่ง null เพื่อไม่ใช้โปรไฟล์ หรือส่ง UUID ในโปรเจกต์เดียวกันเพื่อแทนที่ ทุกคีย์ ${DATA_*} ที่อ้างอิงต้องมีอยู่ โปรไฟล์การเข้าสู่ระบบส่วนตัวต้องมีผู้สร้างที่ใช้งานอยู่ โปรไฟล์การเข้าสู่ระบบที่แชร์ต้องมีการเข้าถึงโปรเจกต์เดียวกันอย่างใช้งานอยู่ ค่าข้อมูลประจำตัวที่ทราบแน่นอนจะถูกกรอง และค่าข้อมูลโปรไฟล์ที่แน่นอนจะได้รับการกรองอย่างดีที่สุดจากหลักฐานข้อความที่เก็บไว้ ค่าที่แปลงแล้ว บางส่วน เข้ารหัส หรือได้จากแอปอาจยังคงอยู่ วิดีโอ/ภาพหน้าจอส่วนตัวที่ได้รับอนุญาตยังคงพร้อมใช้งานและอาจแสดงค่าที่เรนเดอร์โดยแอปที่ทดสอบ ดังนั้นโปรไฟล์ข้อมูลต้องมีเฉพาะค่าสังเคราะห์ที่ไม่เป็นความลับ หากไม่มีบริบทการแก้ไขข้อมูลประจำตัวหรือไม่สามารถพิสูจน์ความปลอดภัยของการทำความสะอาดได้ ข้อความที่มีรายละเอียดข้อมูลประจำตัวจะถูกระงับ ในขณะที่สถานะและหลักฐานภาพที่พร้อมใช้งานยังคงอยู่ การวินิจฉัยต้องมีการอนุญาตพื้นที่ทำงานและโปรเจกต์ ลิงก์สื่อหมดอายุหลังจากห้านาที
• list_mobile_runs — รับผลการรันบนมือถือที่ได้รับอนุญาต (สถานะ อุปกรณ์ สรุปผล ลิงก์วิดีโอและภาพหน้าจอส่วนตัว เซสชัน BrowserStack บันทึกและความล้มเหลวของ Maestro เนทีฟที่กรองข้อมูลประจำตัวเมื่อปลอดภัย และบั๊กที่สร้างอัตโนมัติ) การเป็นสมาชิกพื้นที่ทำงานและการเข้าถึงโปรเจกต์ถูกบังคับใช้สำหรับการวินิจฉัยการรัน ตัวกรองไม่บังคับ: project_id, automation_id, status (queued, running, passed, failed, error, archived) และ limit การรันที่เก็บถาวรจะถูกแยกออกโดยค่าเริ่มต้น
• create_login_profile — สร้างโปรไฟล์ชื่อผู้ใช้/รหัสผ่านที่เข้ารหัสแบบเขียนอย่างเดียวที่นำกลับมาใช้ใหม่ได้โดย Mobile, Web Automation และ Exploratory AI ต้องระบุ project_id, name, username และ password; ไม่บังคับ visibility คือ private (ค่าเริ่มต้น) หรือ shared โปรไฟล์ส่วนตัวเป็นของผู้สร้างเท่านั้น โปรไฟล์ที่แชร์สามารถใช้ได้โดยสมาชิกที่ใช้งานอยู่ซึ่งเข้าถึงโปรเจกต์เดียวกัน
• create_mobile_credential — ชื่อความเข้ากันได้สำหรับ create_login_profile; ใช้อินพุตและขอบเขตความปลอดภัยเดียวกัน
• list_login_profiles — แสดงเฉพาะโปรไฟล์ที่ผู้เรียกเห็นได้ ไม่บังคับสำหรับ project_id หนึ่งรายการ คืนค่าเมตาดาต้าที่ไม่เป็นความลับรวมถึง visibility; โปรไฟล์ส่วนตัวที่เป็นของผู้ใช้อื่นและโปรเจกต์ที่ไม่สามารถเข้าถึงได้จะถูกละเว้น
• list_mobile_credentials — ชื่อความเข้ากันได้สำหรับ list_login_profiles; ไม่คืนค่าความลับของข้อมูลประจำตัว
• update_login_profile — เปลี่ยนชื่อ หมุนเวียน หรือเปลี่ยน visibility ผู้สร้างที่ใช้งานอยู่สามารถอัปเดตฟิลด์ใดก็ได้ เจ้าของ/ผู้ดูแลพื้นที่ทำงานที่ใช้งานอยู่สามารถเปลี่ยนชื่อหรือหมุนเวียนโปรไฟล์ที่แชร์ได้ แต่ไม่สามารถเปลี่ยนการมองเห็นได้ โปรไฟล์ส่วนตัวยังคงเป็นของผู้สร้างเท่านั้น
• update_mobile_credential — ชื่อความเข้ากันได้สำหรับ update_login_profile; ใช้การตรวจสอบความเป็นเจ้าของและโปรเจกต์เดียวกัน
• delete_login_profile — การลบแบบอ่อนโดยผู้สร้าง โดยมีการกู้คืนวงจรชีวิตโดยเจ้าของ/ผู้ดูแลสำหรับโปรไฟล์ที่แชร์เท่านั้น ค่าเริ่มต้นการใช้งานในอนาคตจะถูกล้างในขณะที่ประวัติการตรวจสอบยังคงอยู่
• delete_mobile_credential — ชื่อความเข้ากันได้สำหรับ delete_login_profile; การอ้างอิงทางประวัติยังคงอยู่เพื่อการตรวจสอบ
• create_mobile_variable_profile — สร้างข้อมูลทดสอบสังเคราะห์ที่นำกลับมาใช้ใหม่ได้และอยู่ในขอบเขตโปรเจกต์ด้วย project_id, name และออบเจกต์ variables เช่น {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"} คีย์ต้องเป็นตัวระบุ DATA_* ตัวพิมพ์ใหญ่ โปรไฟล์อนุญาต 1–100 สตริง, 4096 ไบต์ UTF-8 ต่อค่า และรวม 65536 ไบต์ ชื่อที่สงวนไว้สำหรับข้อมูลประจำตัว/รันไทม์จะถูกปฏิเสธ ห้ามเก็บข้อมูลประจำตัว โทเค็น ข้อมูลส่วนบุคคลในการผลิต หรือความลับอื่น ๆ
• list_mobile_variable_profiles — แสดงรายการโปรไฟล์ Mobile/Both และค่าที่ไม่เป็นความลับที่อ่านได้สำหรับ project_id ที่ได้รับอนุญาตหนึ่งรายการ กฎการกำหนดโปรเจกต์มีผล โปรไฟล์ที่มีอยู่และการสร้างบนมือถือใช้ค่าเริ่มต้นเป็น both; การสร้าง/อัปเดตยอมรับ platform (mobile หรือ both) โปรไฟล์เฉพาะเว็บถูกแยกออกจากการเข้าถึงแคตตาล็อกมือถือและการใช้งานรันไทม์
• update_mobile_variable_profile — เปลี่ยนชื่อโปรไฟล์หรือแทนที่ออบเจกต์ variables ทั้งหมดด้วย id เฉพาะผู้สร้างที่ใช้งานอยู่หรือเจ้าของ/ผู้ดูแลพื้นที่ทำงานที่ใช้งานอยู่เท่านั้นที่สามารถอัปเดตได้
• delete_mobile_variable_profile — ลบโปรไฟล์แบบอ่อนด้วย id เฉพาะผู้สร้างที่ใช้งานอยู่หรือเจ้าของ/ผู้ดูแลพื้นที่ทำงานที่ใช้งานอยู่เท่านั้นที่สามารถลบได้ ค่าเริ่มต้นระบบอัตโนมัติจะถูกล้างในขณะที่การอ้างอิงการรันทางประวัติยังคงอยู่
• list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — แสดงรายการ สร้าง และลบตารางเวลาอุปกรณ์จริง ตารางเวลาสืบทอดบริบทโปรเจกต์ โปรไฟล์การเข้าสู่ระบบ และโปรไฟล์ตัวแปรที่ไม่เป็นความลับจากระบบอัตโนมัติที่เลือก โปรไฟล์การเข้าสู่ระบบส่วนตัวต้องมีผู้สร้างที่ใช้งานอยู่ โปรไฟล์การเข้าสู่ระบบที่แชร์ต้องมีการเข้าถึงโปรเจกต์เดียวกันอย่างใช้งานอยู่ โปรไฟล์ตัวแปรที่ไม่เป็นความลับยังคงนโยบายผู้สร้างหรือเจ้าของ/ผู้ดูแล การเปลี่ยนแปลงและการลบตารางเวลาจำกัดเฉพาะผู้สร้างตารางเวลาที่ใช้งานอยู่หรือเจ้าของ/ผู้ดูแลพื้นที่ทำงานที่ใช้งานอยู่

แคตตาล็อกข้อมูลทดสอบเว็บ

แคตตาล็อกโปรเจกต์ที่ไม่เป็นความลับเดียวกันพร้อมใช้งานจาก Automate Web เครื่องมือเหล่านี้ต้องมีสิทธิ์ automation ของพื้นที่ทำงานและขอบเขตคีย์ API automations:write รวมถึงการอ่าน ไม่ต้องเข้าถึง Mobile ค่าไม่เคยแชร์บันทึกกับโปรไฟล์การเข้าสู่ระบบที่เข้ารหัส การสนับสนุนแคตตาล็อกยังไม่ได้ผูกหรือฉีดค่าโปรไฟล์ลงในการรันเว็บ

• create_web_variable_profile: ต้องระบุ project_id, name, variables; ไม่บังคับ platform (web หรือ both), ค่าเริ่มต้น web ใช้ขีดจำกัด DATA_* เดียวกับมือถือ คืนค่าโปรไฟล์ รวมถึง platform
• list_web_variable_profiles: ต้องระบุ project_id; คืนค่า { profiles: [...] } ที่มีบันทึก Web/Both เท่านั้น
• get_web_variable_profile: ต้องระบุ id; คืนค่าโปรไฟล์ Web/Both ที่เข้าถึงได้และค่าสังเคราะห์
• update_web_variable_profile: ต้องระบุ id; ไม่บังคับ name, การแทนที่ variables ทั้งหมด หรือ platform (web หรือ both) ต้องมีผู้สร้างที่ใช้งานอยู่หรือเจ้าของ/ผู้ดูแลพื้นที่ทำงานที่ใช้งานอยู่ หากต้องการจำกัด Both เป็น Mobile ให้ใช้แคตตาล็อกมือถือกับการเข้าถึง Mobile
• delete_web_variable_profile: ต้องระบุ id; สิทธิ์การจัดการเดียวกัน ลบแบบอ่อนและคืนค่า { deleted: true } โดยเก็บประวัติการตรวจสอบ

ตัวอย่าง: แก้ไขโปรเจกต์ด้วย list_projects, เรียก create_web_variable_profile ด้วย {"project_id":"PROJECT_UUID","name":"Canadian checkout","platform":"both","variables":{"DATA_REGION":"CA"}} จากนั้นตรวจสอบด้วย list_web_variable_profiles โปรเจกต์/โปรไฟล์ที่ไม่สามารถเข้าถึงได้จะล้มเหลวโดยไม่เปิดเผยค่า ข้อมูลที่ไม่ถูกต้องหรือชื่อซ้ำทั่วโปรเจกต์จะถูกปฏิเสธ

ตัวอย่างเวิร์กโฟลว์ — Android

1. list_projects → แก้ไข project_id เป้าหมาย
2. upload_mobile_app → ลงทะเบียน APK ในโปรเจกต์นั้น
3. บันทึกอย่างปลอดภัยในแดชบอร์ด หรือใช้ import_mobile_script / create_mobile_automation
4. list_mobile_automations → แก้ไขระบบอัตโนมัติในโปรเจกต์เดียวกัน
5. run_mobile_automation → เรียกใช้บนอุปกรณ์จริง ไม่บังคับด้วยโปรไฟล์การเข้าสู่ระบบ
6. list_mobile_runs → ตรวจสอบสถานะ สรุปผล ลิงก์ภาพส่วนตัว และเมตาดาต้าเซสชัน BrowserStack
7. ความล้มเหลวสร้างรายงานบั๊กอัตโนมัติพร้อมสแนปชอตความล้มเหลวและการแบ่งขั้นตอน

ตัวอย่างเวิร์กโฟลว์ — iOS

1. upload_mobile_app → ลงทะเบียน IPA ของคุณด้วย project_id สำหรับการรันบนอุปกรณ์จริง
2. อัปโหลดบิลด์ .app ของซิมูเลเตอร์ในหน้าข้อมูลแอป (สำหรับการบันทึก)
3. บันทึกการทดสอบในเบราว์เซอร์ → การกระทำถูกจับจากซิมูเลเตอร์
4. run_mobile_automation → เรียกใช้ระบบอัตโนมัติที่บันทึกไว้บน iPhone (ใช้ IPA)
5. update_mobile_app → แทนที่ IPA ด้วยเวอร์ชันใหม่เมื่อพร้อม

ตัวอย่างเวิร์กโฟลว์ — Native Maestro

1. upload_mobile_app → ลงทะเบียน APK หรือ IPA ในโปรเจกต์เป้าหมาย
2. create_mobile_credential → ไม่บังคับสร้างโปรไฟล์ในโปรเจกต์เดียวกันสำหรับโฟลว์ที่ผ่านการรับรองความถูกต้อง
3. create_mobile_variable_profile → ไม่บังคับสร้างค่า DATA_* สังเคราะห์ในโปรเจกต์เดียวกันที่ใช้โดยโฟลว์
4. create_mobile_automation → ส่งโฟลว์ YAML ที่รู้จักว่าทำงานหนึ่งรายการพร้อม appId แพ็กเกจ/bundle ที่แน่นอนของแอปที่เชื่อมโยง, script_type: maestro และ execution_mode: browserstack_maestro ใช้ ${USERNAME} / ${PASSWORD} สำหรับการเข้าสู่ระบบและตัวแทนแบบ ${DATA_EMAIL} สำหรับอินพุตสังเคราะห์ ส่ง ID โปรไฟล์เพื่อบันทึกค่าเริ่มต้น
5. run_mobile_automation → เลือกอุปกรณ์ที่เข้ากันได้และไม่บังคับแทนที่โปรไฟล์การเข้าสู่ระบบหรือตัวแปร ละเว้นโปรไฟล์ตัวแปรเพื่อสืบทอด หรือส่ง null เพื่อปิดใช้งานสำหรับหนึ่งการรัน
6. list_mobile_runs → ตรวจสอบสรุปผ่าน/ไม่ผ่านที่ได้รับอนุญาต วิดีโอ/ภาพหน้าจอส่วนตัว บันทึกที่กรอง ชื่อขั้นตอนจริง ความล้มเหลวโดยละเอียด และเมตาดาต้าเซสชัน หากไม่สามารถสร้างความปลอดภัยของการทำความสะอาดสำหรับการรันที่มีข้อมูลประจำตัว ข้อความโดยละเอียดจะถูกระงับในขณะที่สถานะและหลักฐานภาพที่พร้อมใช้งานยังคงอยู่

ปรับแต่งด้วย AI: เบต้าที่อนุญาตผ่านรายการพร้อมใช้งานผ่านแดชบอร์ดและจุดสิ้นสุดการปรับแต่ง REST ไม่มีเครื่องมือ Refine MCP ในแคตตาล็อกสาธารณะในขณะนี้

✅

การปฏิบัติตามข้อกำหนดและหลักฐาน (ระดับองค์กร)

• collect_compliance_evidence — เรียกใช้การรวบรวมหลักฐานอัตโนมัติจากบริการที่เชื่อมต่อ (Cloudflare, GitHub, Sentry, Supabase, Railway) คืนค่า run ID รวบรวมการตั้งค่า SSL/TLS, สถานะ WAF, การแจ้งเตือน Dependabot, แนวโน้มข้อผิดพลาด, ประวัติการ deploy และอื่นๆ
• check_config_drift — ตรวจสอบบริการที่เชื่อมต่อทั้งหมดว่ามีการเบี่ยงเบนการกำหนดค่าด้านความปลอดภัยจาก baseline หรือไม่ (โหมด SSL, เวอร์ชัน TLS, HSTS, กฎ WAF, security headers)
• generate_access_review — สร้างรายงานการตรวจสอบการเข้าถึงรายไตรมาส ตรวจสอบสมาชิกทีม บทบาท สถานะ MFA การใช้งาน API key และสร้างคำแนะนำ (เช่น เพิกถอนคีย์ที่ไม่ใช้งาน)
• get_security_events — ค้นหาไทม์ไลน์เหตุการณ์ความปลอดภัยข้ามบริการ กรองตามแหล่งที่มา (cloudflare, sentry, github) และระดับความรุนแรง (critical, high, medium, low, info) เหตุการณ์จะถูกเชื่อมโยงอัตโนมัติข้ามบริการ

ความครอบคลุมการปฏิบัติตามข้อกำหนด

เครื่องมือเหล่านี้ช่วยตอบสนองข้อกำหนด SOC2 (CC4.1, CC6.1, CC7.2, CC8.1), ISO 27001 (A.5.18, A.8.8, A.8.9, A.8.15-16, A.8.29) และ GDPR (Art. 5, 25, 32, 33)

ไคลเอนต์ที่เข้ากันได้

bug Agent ทำงานร่วมกับไคลเอนต์ใดก็ได้ที่รองรับ Model Context Protocol นี่คือคำแนะนำการตั้งค่าสำหรับไคลเอนต์ยอดนิยม:

เปิด Settings → Developer → Edit Config จากนั้นเพิ่ม:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

รีสตาร์ท Claude Desktop หลังจากบันทึก

✳️

Cursor

เปิด Settings → MCP Servers → Add Server หรือแก้ไข .cursor/mcp.json ในโฟลเดอร์โปรเจกต์ของคุณ:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

🌊

Windsurf

เปิด Settings → MCP → Add Server หรือแก้ไขไฟล์กำหนดค่า MCP ของคุณ:

{
  "mcpServers": {
    "bugagent": {
      "type": "http",
      "url": "https://mcp.bugagent.com/mcp",
      "headers": {
        "Authorization": "Bearer ba_live_YOUR_KEY_HERE"
      }
    }
  }
}

เพิ่ม bug Agent โดยตรงจากเทอร์มินัล:

claude mcp add --transport http bugagent https://mcp.bugagent.com/mcp --header "Authorization: Bearer ba_live_YOUR_KEY_HERE"

การดำเนินการนี้เชื่อมต่อโดยตรงกับโฮสต์ Streamable HTTP

สำหรับไคลเอนต์ที่ต้องใช้ stdio ให้ใช้บริดจ์ bugagent-mcp ที่เผยแพร่:

• คำสั่ง: npx
• บรรทัดคำสั่ง: npx -y bugagent-mcp
• อาร์กิวเมนต์: ["-y", "bugagent-mcp"]
• ตัวแปรสภาพแวดล้อม: BUGAGENT_API_KEY

ขอความช่วยเหลือ

ต้องการความช่วยเหลือหรือไม่ เราพร้อมช่วยเหลือคุณ

ชุมชน Discord

เข้าร่วม Discord ของเราเพื่อรับการสนับสนุนแบบเรียลไทม์และการสนทนาในชุมชน

ฝ่ายสนับสนุนทางอีเมล

support@bugagent.com — เรามักจะตอบกลับภายใน 24 ชั่วโมง