bugAgent

chính thức

Kết nối bugAgent với bất kỳ ứng dụng AI tương thích MCP nào. Tạo, phân loại và quản lý lỗi, yêu cầu tính năng, v.v. trực tiếp từ trợ lý mã hóa AI của bạn. Không cần chuyển đổi ngữ cảnh, không cần sao chép-dán — chỉ cần mô tả vấn đề và bugAgent xử lý phần còn lại.

Xem trên bugagent.comDùng thử MCP nàyĐược tài trợ

Bạn có thể làm gì với bugAgent MCP?

Tạo báo cáo lỗi — Yêu cầu trợ lý của bạn tạo báo cáo lỗi với phân loại tự động trên 19 loại, bao gồm cả cài đặt mức độ nghiêm trọng và ưu tiên.
Liệt kê và lọc báo cáo — Sử dụng list_bug_reports để truy vấn lỗi theo dự án, mức độ nghiêm trọng, trạng thái, loại hoặc văn bản tìm kiếm, với phân trang lên đến 100 kết quả.
Chọn lỗi tiếp theo để xử lý — Để trợ lý của bạn gọi pick_next_bug để lấy lỗi chưa được gán có mức ưu tiên cao nhất (S1→S3, cũ nhất trước) cho nhóm của bạn.
Nhận lỗi một cách nguyên tử — Sử dụng claim_bug để chuyển lỗi sang trạng thái đang xử lý mà không gặp xung đột và gán nó cho bạn, ngăn chặn công việc trùng lặp.
Quản lý bộ kiểm thử và trường hợp kiểm thử — Tạo bộ kiểm thử, chạy bộ hồi quy và liệt kê các trường hợp kiểm thử thất bại trong 7 ngày qua.

Tài liệu

Kết nối bug Agent với bất kỳ AI client tương thích MCP nào.

Ghi lại, phân loại và quản lý lỗi, yêu cầu tính năng và nhiều hơn nữa trực tiếp từ trợ lý lập trình AI của bạn. Không cần chuyển ngữ cảnh, không cần sao chép-dán — chỉ cần mô tả vấn đề và bug Agent xử lý phần còn lại.

Các MCP client bên ngoài tách biệt với AI Assistant trong bảng điều khiển của bug Agent. Trợ lý bảng điều khiển bị tắt theo mặc định trên mọi gói và yêu cầu kích hoạt không gian làm việc rõ ràng; cổng ai_assistant của nó không vô hiệu hóa MCP hoặc tích hợp. Xác thực MCP, phạm vi, quyền không gian làm việc/dự án và quyền riêng theo công cụ vẫn được áp dụng.

Bắt đầu

bug Agent chạy máy chủ MCP được lưu trữ để các AI client có thể tạo, truy vấn và quản lý báo cáo lỗi, yêu cầu tính năng, cải tiến và nhiều hơn nữa thông qua Giao thức Ngữ cảnh Mô hình. Các client kết nối trực tiếp đến điểm cuối Streamable HTTP được lưu trữ.

Lấy khóa API của bạn

Tạo tài khoản miễn phí; chủ sở hữu không gian làm việc mới được đưa trực tiếp đến thiết lập khóa API. Người dùng quay lại có thể tạo khóa từ Cài đặt → Nhà phát triển → Khóa API.

Cấu hình AI client của bạn

Thêm bug Agent làm máy chủ MCP trong cấu hình client của bạn (xem thiết lập bên dưới).

Bắt đầu ghi lỗi

Mô tả lỗi bằng ngôn ngữ tự nhiên và bug Agent tự động phân loại, làm phong phú và lưu trữ nó.

# 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

Thiết lập

Được khuyến nghị: Streamable HTTP được lưu trữ

Kết nối trực tiếp đến https://mcp.bugagent.com/mcp. Không có gì để cài đặt hoặc giữ chạy cục bộ. Thêm khóa API không gian làm việc của bạn làm mã thông báo bearer:

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

💡

Thay thế ba_live_YOUR_KEY_HERE bằng khóa API thực tế của bạn từ Cài đặt → Nhà phát triển.

Cầu nối stdio tùy chọn

Chỉ sử dụng cầu nối đã xuất bản khi client yêu cầu stdio và không thể kết nối với máy chủ HTTP từ xa. Chạy nó theo yêu cầu với npx -y bugagent-mcp:

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

Kết nối với Máy chủ

Máy chủ MCP của bug Agent hoạt động tại https://mcp.bugagent.com/mcp qua giao thức vận chuyển Streamable HTTP. Kết nối từ bất kỳ client nào trong tám client bên dưới — chọn client phù hợp với quy trình làm việc của bạn.

Để có cấu hình nhỏ sẵn sàng sao chép, hướng dẫn khóa có phạm vi và các lời nhắc khởi động an toàn, hãy sử dụng khởi động nhanh MCP công khai.

🔑

Lấy khóa API của bạn trước. Đăng nhập vào Cài đặt → Nhà phát triển, nhấp Tạo Khóa API, chọn các phạm vi client của bạn cần và sao chép giá trị (bắt đầu bằng ba_live_). Bạn sẽ chỉ thấy nó một lần, vì vậy hãy dán nó vào nơi an toàn. Các MCP client chỉ liệt kê các công cụ được cấp bởi các phạm vi đó. Các ví dụ kết nối bên dưới sử dụng khóa này; các lời nhắc yêu cầu OAuth/phiên tương tác hoặc quyền gói trả phí được xác định riêng.

Tùy chọn 1 — MCP Inspector (Giao diện Web, được khuyến nghị cho lần kiểm tra đầu tiên)

Công cụ chính thức của Anthropic. Khởi chạy giao diện web cục bộ nơi bạn có thể nhấp qua từng công cụ, điền tham số và xem phản hồi. Không cần cấu hình, không cần IDE.

macOS (Terminal)

npx @modelcontextprotocol/inspector

Windows (PowerShell hoặc CMD)

npx @modelcontextprotocol/inspector

Trong giao diện trình duyệt mở ra:

Loại Giao thức vận chuyển: chọn Streamable HTTP
URL: https://mcp.bugagent.com/mcp
Loại Kết nối: chọn Proxy (mặc định — Inspector ủy quyền qua tiến trình Node cục bộ để bỏ qua CORS của trình duyệt)
Mở Cài đặt Máy chủ → Tiêu đề Tùy chỉnh và thêm:
- Tên Tiêu đề: X-Api-Key
  - Giá trị: ba_live_YOUR_KEY_HERE (không có tiền tố Bearer)
Nhấp Kết nối. Bảng điều khiển bên trái liệt kê các công cụ bug Agent được phép bởi các phạm vi khóa API bạn đã chọn.
Nhấp vào bất kỳ công cụ nào (ví dụ: list_bug_reports), điền tham số, nhấp Chạy Công cụ. Phản hồi hiển thị ở bên phải.

Điều kiện tiên quyết: MCP Inspector v2 yêu cầu Node.js 22.19 trở lên. Cài đặt bản phát hành Node.js hiện tại từ nodejs.org nếu bạn chưa có.

Nếu Inspector trả về invalid_client, nó đang cố gắng thực hiện kết nối OAuth đã lưu thay vì xác thực khóa API. Xóa máy chủ đã lưu (hoặc xóa trạng thái OAuth đã lưu của nó), thêm lại và sử dụng tiêu đề tùy chỉnh X-Api-Key ở trên. Không đặt khóa ba_live_ trong trường client_id OAuth.

Tùy chọn 2 — Claude Desktop (Mac + Windows)

Nếu bạn sử dụng ứng dụng Claude Desktop, bạn có thể thêm bug Agent làm máy chủ MCP vĩnh viễn. Với khóa API không gian làm việc, Claude chỉ nhận các công cụ được phép bởi phạm vi của khóa đó. OAuth được ủy quyền hiển thị danh mục tương tác đầy đủ.

macOS

Mở Claude Desktop → thanh menu Claude → Cài đặt → Nhà phát triển → Chỉnh sửa Cấu hình. Thao tác này mở ~/Library/Application Support/Claude/claude_desktop_config.json.

Thêm mục bug Agent dưới mcpServers:

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

Lưu tệp và thoát hoàn toàn Claude Desktop (Cmd+Q, không chỉ đóng cửa sổ).
Khởi chạy lại Claude Desktop. Biểu tượng búa công cụ ở cuối đầu vào trò chuyện bây giờ sẽ hiển thị các công cụ bug Agent.
Thử: gõ “Liệt kê 5 báo cáo lỗi gần đây nhất của tôi” — Claude sẽ tự động gọi list_bug_reports.

Windows

Mở Claude Desktop → Tệp → Cài đặt → Nhà phát triển → Chỉnh sửa Cấu hình. Thao tác này mở %APPDATA%\Claude\claude_desktop_config.json (thường là C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json).
Thêm cùng khối JSON được hiển thị trong phần macOS.
Lưu tệp và thoát hoàn toàn Claude Desktop từ khay hệ thống (nhấp chuột phải vào biểu tượng Claude → Thoát), sau đó khởi chạy lại.
Biểu tượng búa công cụ sẽ hiển thị các công cụ bug Agent.

Tùy chọn 3 — Claude Code (CLI)

Nếu bạn sử dụng Claude Code từ terminal của mình (phiên bản CLI của Claude), hãy đăng ký máy chủ bug Agent bằng một lệnh. Hoạt động giống hệt trên macOS, Linux và Windows.

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

Sau đó khởi động lại phiên Claude Code của bạn. Xác minh nó đã kết nối:

claude mcp list

Bạn sẽ thấy bugagent trong danh sách với dấu chấm xanh. Bắt đầu với lời nhắc tương thích khóa API: “Liệt kê 5 báo cáo lỗi đang mở gần đây nhất của tôi.”

Đã kết nối, nhưng thiếu một số công cụ?

Kiểm tra số lượng công cụ của máy chủ trong /mcp, không chỉ các công cụ đã tải trong cuộc trò chuyện. Claude Code có thể khám phá công cụ theo yêu cầu bằng tìm kiếm công cụ. Yêu cầu nó tìm kiếm bugAgent cho list_test_cases, list_test_suites hoặc get_test_run_plan. Xem tài liệu tìm kiếm công cụ của Claude Code.

Danh mục được lọc theo phạm vi khóa API. Đọc trường hợp kiểm thử cần test_cases:read; đọc bộ/chuỗi chạy cần test_runs:read. Chỉ yêu cầu các phạm vi ghi bạn thực sự cần. So sánh tools/list đã xác thực với cùng điểm cuối và khóa như client của bạn; khám phá ẩn danh hoặc khóa khác không phải là so sánh hợp lệ. Kiểm tra cấu hình cấp dự án ghi đè kết nối cấp người dùng của bạn, sau đó kết nối lại hoặc khởi động lại sau khi thay đổi thông tin xác thực.

Nếu danh mục máy chủ đã xác thực bao gồm một công cụ nhưng client vẫn không thể khám phá nó, hãy ghi lại phiên bản client, phiên bản máy chủ, tên/số lượng công cụ và bất kỳ lỗi lược đồ nào, với thông tin xác thực và dữ liệu khách hàng được loại bỏ. Phiên bắt đầu với ENABLE_TOOL_SEARCH=false claude có thể phân biệt khám phá trì hoãn với sự cố tải, nhưng tải tất cả định nghĩa công cụ và sử dụng nhiều ngữ cảnh hơn; chỉ sử dụng nó như chẩn đoán tạm thời. Không mở rộng quyền hoặc tách điểm cuối chỉ để tăng số lượng công cụ.

Để gỡ bỏ sau này:

claude mcp remove bugagent

Tùy chọn 4 — OpenAI Codex CLI

Nếu bạn sử dụng OpenAI Codex CLI, hãy xuất khóa API của bạn và thêm bug Agent vào ~/.codex/config.toml.

Đăng ký vĩnh viễn (thêm vào cấu hình)

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

Đặt khóa API

export BUGAGENT_API_KEY="ba_live_YOUR_KEY_HERE"

Bắt đầu hoặc khởi động lại Codex từ môi trường đó. Codex tự động giải quyết các lệnh gọi công cụ từ lời nhắc ngôn ngữ tự nhiên của bạn. Thử: “Liệt kê các lỗi đang mở của tôi được sắp xếp theo mức độ nghiêm trọng.”

Tùy chọn 5 — Cursor (Mac + Windows)

Cursor có hỗ trợ MCP tích hợp. Với khóa API không gian làm việc có phạm vi phù hợp, trợ lý AI bên trong Cursor có thể ghi lỗi, liệt kê báo cáo và chạy các quy trình tự động hóa được hỗ trợ mà không cần rời khỏi trình soạn thảo của bạn. Quét bảo mật, hiệu suất và thăm dò yêu cầu OAuth được ủy quyền và quyền truy cập gói áp dụng.

Mở Cursor → Cài đặt (Cmd+, trên Mac / Ctrl+, trên Windows) → MCP trong thanh bên trái.
Nhấp + Thêm máy chủ MCP mới.
Chọn loại giao thức vận chuyển HTTP.
Điền:
- Tên: bugagent
  - URL: https://mcp.bugagent.com/mcp
  - Tên tiêu đề: Authorization
  - Giá trị tiêu đề: Bearer ba_live_YOUR_KEY_HERE
Nhấp Lưu. Cursor hiển thị chỉ báo màu xanh khi kết nối.
Mở trò chuyện của Cursor (Cmd+L / Ctrl+L) và gõ “Tạo báo cáo lỗi có tiêu đề ‘Đăng nhập bị hỏng’ với mức độ nghiêm trọng cao.” Cursor sẽ gọi create_bug_report.

Thay thế: Cursor cũng đọc ~/.cursor/mcp.json (Mac) hoặc %USERPROFILE%\.cursor\mcp.json (Windows). Thêm cùng định dạng JSON được hiển thị trong phần Claude Desktop.

Tùy chọn 6 — VS Code với tiện ích mở rộng Continue (Mac + Windows)

Nếu bạn thích VS Code, tiện ích mở rộng Continue hỗ trợ máy chủ MCP nguyên bản.

Cài đặt tiện ích mở rộng Continue từ marketplace VS Code.
Mở cấu hình của Continue: Bảng lệnh (Cmd+Shift+P / Ctrl+Shift+P) → Continue: Mở config.json. Tệp nằm tại:
- macOS: ~/.continue/config.json
  - Windows: %USERPROFILE%\.continue\config.json

Thêm mục mcpServers:

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

Lưu. Continue sẽ tự động tải lại và hiển thị các công cụ bug Agent trong thanh bên.
Mở bảng trò chuyện Continue và thử: “Liệt kê 5 báo cáo lỗi đang mở gần đây nhất của tôi.”

Các tiện ích mở rộng VS Code khác có khả năng MCP: Cline, Roo Code và Windsurf (fork) đều tuân theo các mẫu cấu hình JSON tương tự với khóa mcpServers và giao thức vận chuyển HTTP.

Tùy chọn 7 — Máy chủ nhận biết OAuth (ứng dụng web Claude.ai được hiển thị làm ví dụ)

Một số máy chủ MCP xác thực qua OAuth 2.0 và yêu cầu client_id và client_secret tĩnh trước thay vì chấp nhận khóa API bearer. Tạo cặp thông tin xác thực trình kết nối từ bảng điều khiển bug Agent và dán nó vào biểu mẫu trình kết nối của máy chủ. Cặp này xác định MCP client; sau khi đồng ý, thực thi công cụ sử dụng người dùng đã đăng nhập và không gian làm việc bug Agent đang hoạt động của người dùng đó. Hướng dẫn bên dưới sử dụng ứng dụng web Claude.ai làm ví dụ phổ biến nhất.

OAuth ràng buộc tài nguyên. Định danh tài nguyên được bảo vệ là https://mcp.bugagent.com/mcp. Các máy chủ nhận biết tiêu chuẩn khám phá nó từ /.well-known/oauth-protected-resource/mcp và gửi nó làm tham số resource RFC 8707. bug Agent phát hành mã thông báo không rõ ràng ràng buộc với tài nguyên đó, OAuth client, người dùng đã đăng nhập và các phạm vi được cấp; mã thông báo không thể phát lại chống lại dịch vụ khác hoặc được đổi bởi client khác.

Trong bug Agent: mở Cài đặt → Nhà phát triển → Trình kết nối MCP. Nhấp Tạo trình kết nối, đặt tên mô tả máy chủ (ví dụ: “Claude.ai (công việc)”), dán URI chuyển hướng mà máy chủ MCP của bạn yêu cầu (đối với ứng dụng web Claude.ai đó là https://claude.ai/api/mcp/auth_callback — kiểm tra tài liệu trình kết nối của máy chủ của bạn cho các máy chủ khác) và chọn Bảo mật cho phương thức xác thực. Sao chép client_id và client_secret được hiển thị một lần trên màn hình thành công.
Trong cài đặt trình kết nối / OAuth của máy chủ MCP của bạn, dán:
- URL máy chủ: https://mcp.bugagent.com/mcp
  - ID client + Bí mật client: từ bước 1
  - URL ủy quyền: https://mcp.bugagent.com/authorize
  - URL mã thông báo: https://mcp.bugagent.com/token
  - Tài nguyên được bảo vệ / đối tượng, khi được yêu cầu: https://mcp.bugagent.com/mcp Cụ thể cho Claude.ai: đi tới claude.ai/customize/connectors và nhấp Thêm trình kết nối MCP.
Lưu. Máy chủ chuyển hướng bạn đến bug Agent để đăng nhập (Google hoặc email/mật khẩu — bất kỳ phương thức nào bạn sử dụng cho bảng điều khiển) và phê duyệt đồng ý, sau đó hoàn tất bắt tay OAuth.
Quản lý và thu hồi các trình kết nối đã tạo từ cùng trang Cài đặt. Thu hồi là ngay lập tức — yêu cầu tiếp theo từ trình kết nối đó trả về invalid_client.

Lưu ý: Claude Code, Cursor, VS Code và MCP Inspector không cần quy trình này — chúng xử lý đăng ký client động (RFC 7591) tự động và xác thực qua khóa API như được hiển thị ở trên. Biểu mẫu Trình kết nối MCP chỉ dành cho các máy chủ yêu cầu thông tin xác thực OAuth tĩnh.

Các giá trị truy cập và làm mới OAuth chỉ được hiển thị cho máy chủ. Chúng không rõ ràng, được xoay vòng khi làm mới và được lưu trữ bởi bug Agent chỉ dưới dạng băm một chiều; thông tin xác thực làm mới danh tính ngược dòng được mã hóa khi lưu trữ. Không bao giờ sao chép mã thông báo OAuth vào yêu cầu API REST hoặc máy chủ MCP khác.

Tùy chọn 8 — HTTP trực tiếp với curl (Terminal)

Nếu bạn muốn kiểm thử máy chủ trực tiếp mà không cần bất kỳ máy khách nào, hoặc tích hợp nó vào một tập lệnh, bạn có thể gọi endpoint HTTP bằng curl. Giao thức MCP là JSON-RPC 2.0 qua 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

Phản hồi có thể là JSON hoặc Server-Sent Events. Mỗi khối SSE là một dòng có tiền tố data: theo sau là một đối tượng JSON. Các máy khách tuân thủ tiêu chuẩn nên gửi Accept: application/json, text/event-stream; bug Agent hiện đang chuẩn hóa các giá trị Accept bị thiếu hoặc không đầy đủ để tương thích.

ℹ️

Xử lý lỗi 401 Unauthorized: Kiểm tra xem khóa API của bạn đã bị thu hồi trong Cài đặt → Nhà phát triển chưa. Các khóa bắt đầu bằng ba_live_. Nếu bạn vẫn gặp sự cố, hãy tạo lại khóa và thử lại.

Mô hình truy cập và phạm vi đặc quyền tối thiểu

Danh mục OAuth đầy đủ chứa 141 công cụ. Khóa API của không gian làm việc chỉ thấy các công cụ được ánh xạ tới một trong các phạm vi đã chọn. Khám phá chưa xác thực có thể hiển thị siêu dữ liệu công cụ, nhưng tools/call luôn yêu cầu khóa API hoặc mã thông báo OAuth.

Đọc báo cáo lỗi và giải quyết dự án reports:read

Tạo và cập nhật báo cáo lỗi reports:read, reports:write

Giám sát sử dụng usage:read

Kiểm tra trạng thái đồng bộ Jira jira:read

Đồng bộ hoặc hợp nhất báo cáo Jira jira:write

Tạo tự động hóa web automations:write

Chạy tự động hóa web và đọc các lần chạy automations:run

Quan sát tài sản di động và các lần chạy mobile:read

Quản lý tài sản di động mobile:read, mobile:write

Chạy tự động hóa di động mobile:read, mobile:run

Quản lý danh mục kiểm thử reports:read, test_cases:read, test_cases:write

Worker thực thi kiểm thử bên ngoài test_runs:read, test_runs:write

Khóa API được liên kết với không gian làm việc nơi chúng được tạo. Đầu vào công cụ có thể thu hẹp một lệnh gọi tới một dự án được ủy quyền, nhưng không thể chuyển khóa sang không gian làm việc khác. Giải quyết UUID dự án bằng list_projects và từ chối các tên không rõ ràng.

Tiêu đề và chú thích công cụ

Mọi công cụ được trả về bởi tools/list đều bao gồm tiêu đề dễ đọc và gợi ý đọc/ghi. Các gợi ý đọc bị thiếu đến từ một danh sách được xem xét rõ ràng, không phải từ tiền tố tên công cụ hoặc phạm vi khóa API. Các chú thích rõ ràng, bao gồm false, được giữ nguyên.

readOnlyHint: true mô tả một công cụ không sửa đổi môi trường của nó.
readOnlyHint: false với destructiveHint: false mô tả các ghi bổ sung, không phải thao tác chỉ đọc.
readOnlyHint: false với destructiveHint: true mô tả các ghi có khả năng phá hủy. Các công cụ chưa được phân loại sử dụng các mặc định thận trọng này. Gợi ý phá hủy chỉ có ý nghĩa đối với các ghi.

login không chỉ đọc: trong chế độ stdio, nó lưu thông tin xác thực. analyze_fix_area và check_config_drift là các ghi có khả năng phá hủy vì chúng thay thế kết quả phân tích đã lưu hoặc đường cơ sở cấu hình.

Chú thích không cấp quyền truy cập hoặc thay thế xác thực, ủy quyền không gian làm việc/dự án, phạm vi khóa API hoặc kiểm tra quyền. Lời nhắc xác nhận phụ thuộc vào chính sách quyền của máy khách và cài đặt người dùng; các gợi ý không đảm bảo liệu một lệnh gọi có nhắc hay không.

Để khám phá và kiểm toán theo chương trình, hãy tải xuống mcp-tool-index.json được tạo. Nó ghi lại tất cả 141 công cụ thời gian chạy, phạm vi khóa API hoặc quyền truy cập chỉ OAuth, họ quyền, tên đầu vào, chế độ lược đồ đầu ra và các chú thích MCP được khai báo rõ ràng. Chú thích null có nghĩa là nó không được khai báo tại điểm gọi; sử dụng phản hồi tools/list của máy chủ đã kết nối để biết các chú thích hiệu quả sau khi áp dụng mặc định.

Công cụ chỉ OAuth: quản trị tài khoản, khóa API và nhóm, quản lý kết nối Jira, tích hợp khác, kiểm soát kiểm thử cao cấp, ghi chú, theo dõi thời gian và các thao tác tương tác khác không được mở khóa bằng cách thêm phạm vi khóa API. Các công cụ kiểm tra, đồng bộ và hợp nhất báo cáo Jira là ngoại lệ hẹp thông qua jira:read và jira:write.

Dùng thử — Lời nhắc bằng tiếng Anh đơn giản

Khi đã kết nối, bạn không cần biết tên công cụ hoặc tham số. Mô tả những gì bạn muốn bằng tiếng Anh đơn giản và trợ lý AI của bạn sẽ tự động gọi đúng công cụ bug Agent.

Lời nhắc báo cáo lỗi, quản lý kiểm thử có phạm vi, tự động hóa Playwright, tự động hóa di động và sử dụng có sẵn cho khóa API có phạm vi phù hợp. Bảo mật, hiệu suất, khám phá, tài khoản, nhóm, ghi chú, theo dõi thời gian và các mục khác không có phạm vi khóa API được đặt tên yêu cầu OAuth được ủy quyền và bất kỳ quyền gói áp dụng nào.

Báo cáo lỗi

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

Quản lý kiểm thử

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

Bảo mật & Hiệu suất

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?

Tự động hóa 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 khám phá

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?

Sử dụng & Thống kê

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?

Tham chiếu nhanh

Tài liệu tham khảo thiết lập cho tất cả tám tùy chọn kết nối. Máy khách khóa API kết nối tới https://mcp.bugagent.com/mcp với tiêu đề Authorization: Bearer ba_live_YOUR_KEY_HERE qua Streamable HTTP; máy chủ hỗ trợ OAuth sử dụng thông tin xác thực đầu nối được tạo trong bảng điều khiển.

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 Cài đặt → Giao diện MCP, hoặc ~/.cursor/mcp.json

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

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

Máy chủ hỗ trợ OAuth Cài đặt → Nhà phát triển → Đầu nối MCP — tạo client_id và client_secret của máy chủ

HTTP trực tiếp (curl) curl / Invoke-RestMethod — bao gồm Accept: application/json, text/event-stream

Xử lý sự cố

401 Unauthorized Khóa sai, hết hạn hoặc bị thu hồi. Kiểm tra Cài đặt → Nhà phát triển — khóa bắt đầu bằng ba_live_. Tạo lại nếu cần.

Công cụ không hiển thị trong máy khách Máy khách khóa API chỉ liệt kê các công cụ được phép bởi phạm vi đã chọn của khóa. Kiểm tra khóa trong Cài đặt → Nhà phát triển, sau đó thoát hoàn toàn và khởi động lại máy khách sau khi thay đổi cấu hình. Trong Claude Desktop, Cmd+Q (không chỉ đóng cửa sổ). Trong Cursor, kiểm tra Cài đặt → MCP để thấy dấu chấm xanh.

Trường bị thiếu trong máy khách So sánh lược đồ của máy khách với tools/list thô của cùng endpoint. Nếu chúng khác nhau, hãy làm mới hoặc kết nối lại danh mục công cụ và bắt đầu cuộc trò chuyện mới. Nếu vẫn tiếp tục, hãy thu thập endpoint, phiên bản máy khách và phản hồi tools/list thô; bộ nhớ cache cũ chỉ là một nguyên nhân có thể.

Accept header required Gửi Accept: application/json, text/event-stream cho Streamable HTTP tuân thủ tiêu chuẩn. bug Agent hiện đang chuẩn hóa các giá trị bị thiếu hoặc không đầy đủ, nhưng các tích hợp không nên dựa vào hành vi tương thích đó.

Dữ liệu sai không gian làm việc Mỗi khóa API được giới hạn trong một không gian làm việc. Tạo khóa mới từ không gian làm việc bạn muốn truy vấn trong Cài đặt → Nhà phát triển.

Công cụ xuất hiện nhưng lệnh gọi thất bại âm thầm Kiểm tra phản hồi để tìm isError: true và nội dung được trả về. Một công cụ hiển thị vẫn có thể bị từ chối bởi gói, vai trò, quyền tính năng, tư cách thành viên dự án, quyền sở hữu hoặc đầu vào không hợp lệ. Kiểm tra sức khỏe máy chủ chỉ sau khi đọc lỗi công cụ.

Lỗi CORS của MCP Inspector Chọn Proxy (không phải Direct) cho Loại kết nối trong giao diện Inspector. Inspector ủy quyền qua một tiến trình Node cục bộ để vượt qua các hạn chế CORS của trình duyệt.

MCP Inspector v2 thoát với mã 5 Inspector v2 trả về mã thoát khác không khi phản hồi công cụ có isError: true. Đọc thông báo phản hồi để biết lỗi gói, quyền, đầu vào hoặc thời gian chạy; Inspector v1 có thể trả về mã thoát 0 cho cùng phản hồi công cụ thất bại.

Codex CLI — công cụ không được nhận dạng Xác minh ~/.codex/config.toml sử dụng [mcp_servers.bugagent], đặt bearer_token_env_var = "BUGAGENT_API_KEY" và xuất biến đó trước khi bắt đầu Codex. Kiểm tra codex --version nếu công cụ vẫn không xuất hiện.

Tính năng MCP

Phiên hội thoại vẫn là chương trình thí điểm giới hạn trong không gian làm việc. Lưu tập lệnh được tạo trong phiên yêu cầu phê duyệt Workbench rõ ràng của chủ sở hữu thông qua endpoint lưu tập lệnh chỉ trong phiên. Không có công cụ phê duyệt MCP: yêu cầu một tác nhân soạn thảo tập lệnh không tạo hoặc lên lịch tự động hóa.

Danh mục tương tác/OAuth đầy đủ chứa 141 công cụ. Khóa API không gian làm việc chỉ khám phá tập con đặc quyền tối thiểu được phép bởi phạm vi đã chọn; quản trị tài khoản, quản trị khóa API, quản trị nhóm, kiểm thử cao cấp, ghi chú và công cụ theo dõi thời gian chỉ dành cho phiên tương tác trừ khi một mục đặt tên rõ ràng phạm vi khóa API.

🐛

Quản lý báo cáo lỗi

Nhập ảnh chụp màn hình Google Sheets có thể tiếp tục sử dụng endpoint REST POST /api/reports/import-attachment riêng với reports:write và trạng thái GET với reports:read. Không có công cụ MCP nhập ảnh chụp màn hình nào được thêm. API chỉ JPEG/PNG này xác minh lưu trữ riêng tư và vấn đề Jira được ánh xạ chính xác trước khi báo cáo hoàn tất; tải lên báo cáo kế thừa vẫn chỉ dành cho phiên.

create_bug_report — Tạo báo cáo mới với tính năng tự phân loại trên 19 loại — lỗi, yêu cầu tính năng, cải tiến, nợ kỹ thuật, v.v. (tiêu đề: 3-500 ký tự). Mảng attachments tùy chọn chấp nhận các tệp mã hóa base64 tối đa 400 MB mỗi tệp: bất kỳ hình ảnh, video, âm thanh, PDF hoặc văn bản/JSON nào. Đặt format_description: true để tự động định dạng lại mô tả thành mẫu có cấu trúc bằng AI. Truyền time_spent_seconds để theo dõi nỗ lực QA. Truyền priority (urgent / high / normal / low) để đặt mức độ khẩn cấp sửa lỗi độc lập với mức độ nghiêm trọng. Truyền is_epic: true để tạo Epic, hoặc parent_epic_id (UUID/ID ngắn) để tạo mục con trong cùng dự án được ủy quyền. Phản hồi bao gồm các trường phân cấp cùng với project_id, project, short_id, legacy_short_id và project_short_id.
list_bug_reports — Liệt kê và lọc báo cáo (tối đa 100 mỗi trang). Bộ lọc dự án được áp dụng phía máy chủ trước khi phân trang. Lọc theo project (UUID, slug, tên chính xác hoặc tiền tố vé), project_id, project_slug, project_prefix, workspace (UUID, tên chính xác hoặc tiền tố vé không gian làm việc), workspace_id / team_id, is_epic, type, severity, status, resolution, root_cause hoặc reporter_user_id. Bộ lọc search tìm kiếm văn bản báo cáo; đầu vào chỉ chứa chữ số như 366 là tra cứu chính xác đối với cả số vé kế thừa và số vé dự án, do đó văn bản không liên quan chứa các chữ số đó sẽ bị loại trừ. Mỗi kết quả bao gồm mã định danh người/dự án theo phạm vi đối tượng thuê bao cùng với is_epic, parent_epic_id, parent_epic và epic_progress có giới hạn. Các công cụ đọc báo cáo không tiết lộ địa chỉ email của thành viên.
pick_next_bug — Trả về (các) lỗi tiếp theo mà vòng lặp tác nhân nên xử lý, theo thứ tự ưu tiên (S1 → S2 → S3, cũ nhất trước trong từng nhóm). Tự động giới hạn trong không gian làm việc của bạn — trả về vé trên tất cả các dự án trong nhóm của bạn có status new, awaiting-triage hoặc confirmed và mức độ nghiêm trọng S1-S3. Chỉ đọc — không tự động chiếm giữ vé. severity tùy chọn (một bậc), limit (1-50, mặc định 1). Trả về một đối tượng có count và bugs; mỗi lỗi là một hàng hàng đợi rút gọn thay vì cấu trúc list_bug_reports đầy đủ. Kết hợp với claim_bug cho mẫu đọc-rồi-chiếm giữ.
claim_bug — Chuyển đổi nguyên tử một lỗi từ status new, awaiting-triage hoặc confirmed sang status='in-progress', đặt assigned_to thành người dùng gọi, và đóng dấu claimed_at=NOW(). Không có điều kiện cạnh tranh giữa các trình gọi đồng thời thông qua mẫu UPDATE-WHERE-RETURNING của Postgres — nếu hai tác nhân gọi claim_bug trên cùng một id trong khoảng thời gian gần nhau, chính xác một tác nhân nhận được claimed:true kèm nội dung lỗi và tác nhân kia nhận được claimed:false kèm chuỗi lý do. Các phản hồi thành công bao gồm reporter_user_id, reporter_name, assigned_to và assignee_name. Một tiến trình pg_cron thu hồi các yêu cầu chiếm giữ hết hạn (trạng thái= in-progress + claimed_at > 30 phút) trở lại new tự động, do đó vé của tác nhân bị sự cố sẽ quay lại hàng đợi mà không cần can thiệp thủ công. Đầu vào: id (UUID hoặc ID ngắn).
get_bug_report — Lấy chi tiết đầy đủ của một báo cáo theo UUID hoặc ID ngắn không gian làm việc/dự án. Trả về các trường người/dự án/chất lượng tiêu chuẩn cùng với is_epic, danh tính cha, tiến độ tổng hợp và trang con đầu tiên có giới hạn cho Epic.
Thẻ báo cáo gốc: create_bug_report và update_bug_report chấp nhận tags dưới dạng mảng chuỗi, ví dụ {"tags":["login","regression"]}. Tối đa 20 phần tử thô được chấp nhận trước khi loại bỏ trùng lặp. Chuỗi được cắt bỏ khoảng trắng, phải không rỗng và tối đa 50 điểm mã Unicode, và không được chứa ký tự điều khiển ASCII (U+0000 đến U+001F hoặc U+007F). Các bản sao chính xác được loại bỏ sau khi cắt; chữ hoa/thường được giữ nguyên và Login khác với login. Khi cập nhật, mảng thay thế tất cả thẻ, [] xóa chúng, và bỏ qua giữ nguyên chúng. Khi tạo, bỏ qua nghĩa là không có thẻ. null và các phần tử không hợp lệ bị từ chối. Kết quả tạo, lấy, liệt kê và cập nhật hiển thị tags gốc.
Lọc thẻ: gọi list_bug_reports với {"project":"bugagent","tags":["login","regression"]} để khớp TẤT CẢ các thẻ được yêu cầu, phân biệt chữ hoa/thường, trước khi phân trang. Các giới hạn thẻ tương tự được áp dụng; bỏ qua hoặc [] không áp dụng bộ lọc thẻ. Các phạm vi reports:read / reports:write hiện có và ủy quyền không gian làm việc/dự án không thay đổi. Điều này không thêm giao diện thẻ trực quan hoặc tự động nhập, đồng bộ hóa hoặc backfill nhãn Jira.
get_epic — Đọc trực tiếp một Epic với id bắt buộc (UUID hoặc ID ngắn không gian làm việc/dự án). Chỉ trả về bản ghi Epic, không tải ngầm các báo cáo con. Yêu cầu quyền truy cập vào không gian làm việc và dự án của nó; người gọi bằng khóa API yêu cầu reports:read. Sử dụng list_epic_children riêng để đọc các mục con.
list_epic_children — Phân trang các báo cáo con của Epic với id, limit (1–100) và offset. Trả về children, total, has_more và epic_progress tổng hợp SQL mà không tải mọi báo cáo con.
update_bug_report — Cập nhật các trường báo cáo tiêu chuẩn cùng với is_epic và parent_epic_id. Truyền parent_epic_id: null để tách; tái gán/tách là nguyên tử và yêu cầu ủy quyền cùng không gian làm việc, cùng dự án. Nâng cấp lên Epic sẽ tách cha hiện có, trong khi Epic có con không thể bị hạ cấp. Các quy tắc thông báo trạng thái/giải quyết/nguyên nhân gốc và phân công hiện có vẫn được áp dụng. Thay đổi status trên báo cáo liên kết Jira được phản ánh sang vấn đề Jira thông qua các chuyển đổi quy trình làm việc khi có đúng một chuyển đổi hợp lệ khớp với trạng thái được ánh xạ; nếu không, vấn đề được giữ nguyên.
add_comment — Thêm bình luận vào báo cáo lỗi (UUID hoặc ID ngắn, nội dung 1-10000 ký tự). Nếu báo cáo được đồng bộ với Jira, bình luận tự động được đẩy lên vấn đề Jira được liên kết. Markdown tệp đính kèm riêng tư như ![proof](/api/attachments/ATTACHMENT_UUID) trở thành liên kết thông minh bugAgent tuyệt đối được xác thực trong Jira. Người xem phải đăng nhập vào bugAgent với quyền truy cập vào không gian làm việc và dự án của báo cáo; bản xem trước nội tuyến Jira gốc không được đảm bảo.
list_comments — Liệt kê chuỗi bình luận đã lưu của báo cáo, cũ nhất trước — mỗi bình luận có tên tác giả, parentId (trả lời theo chuỗi), createdAt và updatedAt. Bình luận không thuộc get_bug_report, vì vậy đây là cách bạn đọc thảo luận của vé. Chấp nhận UUID hoặc ID ngắn. Thao tác đọc này không làm mới Jira. Các tích hợp theo lịch trình cần bình luận Jira mới có thể gọi POST /api/jira/comments-refresh trước với khóa API do người quản lý sở hữu được ủy quyền. Sử dụng ID bình luận và bản sửa đổi nội dung để phân biệt bình luận mới với chỉnh sửa, và không khẳng định báo cáo hoạt động đầy đủ nếu làm mới thất bại.
link_bug_reports — Tạo liên kết ngữ nghĩa định hướng giữa hai báo cáo trong cùng dự án được ủy quyền. Đối với parent-of, báo cáo nguồn phải là Epic và báo cáo đích là mục con tiêu chuẩn. Ưu tiên parent_epic_id khi tạo/cập nhật để gán Epic.
unlink_bug_reports — Xóa liên kết báo cáo lỗi đã tạo trước đó theo UUID của nó (link_id, được trả về bởi link_bug_reports hoặc list_bug_report_links).
list_bug_report_links — Liệt kê mọi liên kết do người dùng tuyển chọn chạm vào một báo cáo lỗi. Trả về mỗi liên kết theo góc nhìn của báo cáo được cung cấp — ví dụ: hàng duplicate-of được lưu trong đó báo cáo này là đích hiển thị dưới dạng duplicated-by; parent-of trong đó báo cáo này là đích hiển thị dưới dạng subtask-of; depends-on trong đó báo cáo này là đích hiển thị dưới dạng blocks; testing-blocked-by trong đó báo cáo này là đích hiển thị dưới dạng blocks-testing. related-to là đối xứng. Bổ sung cho trường similar_reports tự phát hiện được trả về bởi get_bug_report.
classify_bug — Phân loại mô tả thành một trong 19 loại báo cáo (lỗi, tính năng, cải tiến, v.v.) với điểm tin cậy
flush_reports — Xóa hàng loạt báo cáo cũ (chỉ quản trị viên)

📊

Sử dụng & Phân tích

get_usage — Kiểm tra mức sử dụng so với giới hạn gói. Người gọi bằng khóa API yêu cầu usage:read.
get_stats — Số liệu hàng ngày, phân tích theo loại/mức độ nghiêm trọng/trạng thái

📁

Quản lý dự án

list_projects — Liệt kê các dự án có thể truy cập với id, name, slug, ticket_prefix, mô tả và trạng thái mặc định. Sử dụng các giá trị đó với các công cụ báo cáo lỗi và danh mục kiểm thử để nhắm đúng dự án.
create_project — Tạo dự án mới (tự động trở thành mặc định nếu là dự án đầu tiên)
delete_project — Xóa vĩnh viễn một dự án và tất cả dữ liệu liên quan (báo cáo lỗi, tự động hóa, ca kiểm thử, ứng dụng di động, lịch trình, ảnh chụp vị trí, ghi chú, mục thời gian). Chỉ chủ sở hữu/người quản lý. Không thể xóa dự án cuối cùng. Dung lượng lưu trữ được giải phóng tự động
export_okf_bundle — Xuất kiến thức QA của dự án — báo cáo lỗi, ca kiểm thử, tự động hóa và kiểm thử hiệu suất, bảo mật và thăm dò — dưới dạng gói markdown OKF/OQA (định dạng Open Query Agent được sử dụng bởi oqa.ai). Mặc định là dự án đang hoạt động; truyền project tùy chọn (slug hoặc tên) để xuất dự án khác. Trả về danh sách tệp trong gói cùng với chính gói dưới dạng tệp zip mã hóa base64

🔐

Xác thực & Tài khoản

register_account — Tạo tài khoản mới (mật khẩu: 8-128 ký tự, giới hạn tốc độ: 5/15 phút)
login — Đăng nhập và nhận mã thông báo truy cập (giới hạn tốc độ: 5/15 phút)
update_profile — Cập nhật tên hiển thị
change_password — Thay đổi mật khẩu tài khoản
get_settings — Đọc hồ sơ và tùy chọn thông báo.
update_settings — Cập nhật hồ sơ và tùy chọn thông báo được hỗ trợ. Thay đổi chỉ dành cho OAuth.

🔑

Quản lý khóa API

generate_api_key — Tạo khóa API có tên
list_api_keys — Liệt kê các khóa đang hoạt động (chỉ tiền tố)
regenerate_api_key — Thu hồi và thay thế khóa
delete_api_key — Thu hồi vĩnh viễn khóa

👥

Quản lý nhóm

list_workspaces — Liệt kê các không gian làm việc bạn thuộc về, vai trò của bạn trong từng không gian và không gian nào phiên sử dụng theo mặc định. Máy chủ nhiều không gian làm việc có thể ghim yêu cầu bằng tiêu đề X-BugAgent-Workspace (chỉ thành viên đang hoạt động)
list_team_members — Liệt kê tất cả thành viên của không gian làm việc của bạn với vai trò, trạng thái và cờ tăng tốc
invite_team_member — Mời người dùng qua email (người quản lý có thể mời cộng tác viên và người quản lý; chỉ chủ sở hữu mới có thể mời quản trị viên). Liên kết hết hạn sau 5 ngày

🎯

Tích hợp

Đồng bộ báo cáo Jira Cloud được bao gồm trong gói Free và Enterprise. Người quản lý không gian làm việc phải kết nối Jira trước trong bảng điều khiển. Khóa API không gian làm việc sau đó có thể sử dụng jira:read để so sánh và jira:write để đồng bộ/hợp nhất; giới hạn gói và API của Atlassian vẫn được áp dụng.

sync_to_jira — Đẩy một báo cáo lên Jira bằng kết nối dùng chung của nhóm. Định tuyến đến dự án Jira được ánh xạ với dự án bugAgent của báo cáo (mặc định workspace dùng làm phương án dự phòng), sử dụng bản đồ trường của nó: v2 tách biệt mức ưu tiên và mức độ nghiêm trọng tùy chỉnh, trong khi các bản đồ không có phiên bản giữ lại chuyển đổi mức độ nghiêm trọng sang mức ưu tiên kế thừa. Tùy chọn projectKey có thể chỉ chọn ánh xạ đã cấu hình đó hoặc mặc định workspace; các dự án Jira tùy ý bị từ chối. Bạn thường không cần điều này: khi chế độ đồng bộ của dự án là auto_new hoặc auto_all, các báo cáo bạn tạo sẽ được đẩy tự động — hãy gọi nó để đẩy thủ công trong chế độ manual.
check_jira_sync — So sánh chỉ đọc về tiêu đề và trạng thái, mức ưu tiên, mức độ nghiêm trọng đã ánh xạ cho một báo cáo được liên kết được ủy quyền. Sử dụng dự án đã lưu và kết nối Jira của báo cáo. Phiên bản 2 ánh xạ Mức ưu tiên Jira riêng biệt với trường Mức độ nghiêm trọng tùy chỉnh được hỗ trợ; các ánh xạ không có phiên bản giữ lại hành vi mức ưu tiên sang mức độ nghiêm trọng kế thừa. Công cụ này không so sánh nhận xét, tệp đính kèm, loại hoặc mọi trường Jira.
merge_jira_sync — Hợp nhất các trường đã ánh xạ đó bằng prefer: jira để kéo giá trị Jira hoặc prefer: bugagent để đẩy giá trị cục bộ. Đẩy trạng thái sử dụng các chuyển đổi quy trình làm việc Jira hợp lệ. Các xung đột gửi đi chưa ánh xạ, ghi từ xa thất bại và thay đổi cục bộ đồng thời trả về lỗi thay vì tuyên bố mọi thứ đã đồng bộ. Nhận xét và tệp đính kèm vẫn là các quy trình đồng bộ riêng trên bảng điều khiển. Ghi chéo hệ thống không mang tính nguyên tử.
push_to_claude — Tạo (hoặc tạo lại) Ghi chú Nhà phát triển cho một báo cáo lỗi — nguyên nhân gốc, đề xuất sửa chữa, các bước xác minh và đánh giá rủi ro. Chấp nhận UUID hoặc ID ngắn (WRKID-545). Sử dụng khóa nền tảng — không cần kết nối Claude riêng cho từng nhóm. Chạy một chuỗi thích ứng: ba bước trên lỗi s3 / medium hoặc s4 / low (bản nháp Sonnet → phê bình OpenAI gpt-5 → tổng hợp Sonnet), năm bước trên hai nhóm mức độ nghiêm trọng cao nhất — s1 / critical hoặc s2 / high — (bản nháp → phê bình → phản bác Sonnet → trọng tài Claude Opus đọc toàn bộ bản ghi và viết ghi chú cuối cùng bằng phán đoán độc lập). Phản hồi hiển thị mọi vòng: analysis, draft, critique, rebuttal, challenger_model, adjudicator_model và cờ debated. Bất kỳ bước nào thất bại đều chuyển sang câu trả lời tốt nhất tiếp theo. Tự động kích hoạt khi tạo lỗi; thường chỉ được gọi để tạo lại thủ công.
analyze_fix_area — Tạo (hoặc tạo lại) khối con "Khu vực sửa lỗi có khả năng" của Ghi chú Nhà phát triển — một đầu ra Sonnet hẹp nêu tên vị trí trong mã nguồn mà bản sửa lỗi có khả năng thuộc về nhất. Chấp nhận UUID hoặc ID ngắn. Sử dụng khóa Anthropic của nền tảng. Khi nhóm có hàng github_connections và dự án có github_repo được ánh xạ, đầu ra được căn cứ vào các đoạn mã thực từ kho lưu trữ được kết nối; nếu không, sẽ quay lại hướng dẫn chung kèm gợi ý kết nối kho lưu trữ. Trả về văn bản likely_fix_area, generated_at, repo_used và cờ grounded. Tự động kích hoạt khi tạo lỗi — các tác nhân thường chỉ cần gọi điều này để tạo lại thủ công.
upgrade_plan — Nhận liên kết đăng ký Enterprise có hỗ trợ bán hàng

⚡

Kiểm thử Hiệu suất

create_performance_test — Tạo cấu hình kiểm thử hiệu suất với URL, thiết bị, người dùng ảo, thời lượng, ngưỡng điểm và công tắc tự động tạo lỗi. Chỉ dành cho Enterprise
run_performance_test — Kích hoạt kiểm tra trang và kiểm thử tải cho một kiểm thử hiệu suất web. Trả về ID chạy để thăm dò kết quả. Các lần chạy lập hồ sơ ứng dụng di động được kích hoạt từ bảng điều khiển
get_performance_results — Nhận kết quả đầy đủ bao gồm điểm Lighthouse (Hiệu suất, Khả năng truy cập, Thực tiễn tốt nhất, SEO), Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI) và số liệu kiểm thử tải (VU, yêu cầu, RPS, độ trễ p50/p90/p95/p99)
list_performance_tests — Liệt kê tất cả cấu hình kiểm thử hiệu suất cho nhóm hiện tại
get_performance_usage — Kiểm tra mức sử dụng kiểm thử hiệu suất hàng tháng. Kiểm thử hiệu suất chỉ dành cho Enterprise. Miễn phí=0, Enterprise=không giới hạn

Quy trình Ví dụ

get_performance_usage → kiểm tra hạn mức còn lại
create_performance_test → cấu hình kiểm thử cho URL của bạn
run_performance_test → kích hoạt kiểm tra + kiểm thử tải
get_performance_results → xem lại điểm và chỉ số quan trọng

🛡

Quét Bảo mật

create_security_scan — Tạo cấu hình quét bảo mật. Quét web sử dụng Quick Scanner + Nuclei (hơn 4.000 mẫu) với ba mức độ sâu và tùy chọn quét có xác thực. Quét di động sử dụng MobSF để phân tích nhị phân APK/IPA. Tự động tạo lỗi có thể cấu hình với ngưỡng mức độ nghiêm trọng. Chỉ dành cho Enterprise
run_security_scan — Kích hoạt quét lỗ hổng. Quét web yêu cầu xác minh tên miền DNS. Quét di động yêu cầu ứng dụng đã tải lên. Trả về ID chạy để thăm dò kết quả
get_security_results — Nhận kết quả đầy đủ bao gồm điểm bảo mật (0-100), các phát hiện được phân loại theo mức độ nghiêm trọng (Nghiêm trọng, Cao, Trung bình, Thấp, Thông tin) với tham chiếu CWE, ánh xạ OWASP, bằng chứng và hướng dẫn khắc phục
list_security_scans — Liệt kê tất cả cấu hình quét bảo mật cho nhóm hiện tại với điểm cuối cùng và huy hiệu xác thực/độ sâu
get_security_usage — Kiểm tra mức sử dụng quét bảo mật hàng tháng. Quét bảo mật chỉ dành cho Enterprise. Enterprise=không giới hạn
list_security_schedules — Liệt kê tất cả quét bảo mật theo lịch trình cho nhóm với cron, múi giờ, trạng thái bật, lần chạy tiếp theo và cài đặt thông báo. Kết hợp với cấu hình quét cha (tên, scan_type, target_url)
create_security_schedule — Tạo lịch trình định kỳ cho quét bảo mật. Yêu cầu scan_id và cron_expression. Một lịch trình cho mỗi cấu hình quét. Tùy chọn timezone, notify_on_fail (không/email/slack/cả hai), notify_email, slack_channel_id. Mỗi lần chạy tính vào hạn mức hàng tháng của bạn; người dùng quản trị viên bỏ qua hạn mức. Độ sâu quét luôn được đọc từ cấu hình quét tại thời điểm chạy
delete_security_schedule — Xóa quét bảo mật theo lịch trình. Không ảnh hưởng đến cấu hình quét cha hoặc các lần chạy đã hoàn thành

Quy trình Ví dụ

get_security_usage → kiểm tra hạn mức còn lại
create_security_scan → cấu hình quét cho URL hoặc kho lưu trữ của bạn
run_security_scan → kích hoạt quét lỗ hổng một lần
create_security_schedule → tự động hóa các lần chạy định kỳ (ví dụ: SAST hàng tuần trên nhánh chính)
get_security_results → xem lại phát hiện và khắc phục

📖

Đánh giá Mã

list_code_reviews — Liệt kê các đánh giá mã AI gần đây cho nhóm. Trả về điểm chất lượng, số lượng mức độ nghiêm trọng, thông tin PR và dấu thời gian. Chỉ dành cho Enterprise
get_code_review — Nhận đánh giá mã với tất cả phát hiện. Mỗi phát hiện bao gồm mức độ nghiêm trọng, danh mục (lỗi/bảo mật/hiệu suất/phong cách/logic/khả năng bảo trì), tiêu đề, mô tả, đề xuất mã, đường dẫn tệp và số dòng
get_code_review_usage — Kiểm tra mức sử dụng đánh giá mã. Đánh giá mã AI chỉ dành cho Enterprise; không giới hạn trên Enterprise
get_code_review_analytics — Nhận phân tích đánh giá: xu hướng, danh mục/nguồn phát hiện, phân tích mức độ nghiêm trọng, số liệu tốc độ, kho lưu trữ/tác giả hàng đầu. Hỗ trợ xem lại 7/30/90 ngày

Quy trình Ví dụ

get_code_review_usage → kiểm tra số lần đánh giá còn lại
Đánh giá PR trong bảng điều khiển tại /dashboard/code-review
list_code_reviews → xem các đánh giá gần đây
get_code_review → nhận phát hiện và đề xuất

🔍

AI Thăm dò

Công cụ tìm lỗi trang web tự động đa tác nhân với tối đa 10 tác nhân song song, mỗi tác nhân sử dụng một chiến lược kiểm thử khác nhau.

list_explorations — Liệt kê cấu hình AI Thăm dò cho nhóm
create_exploration — Tạo một lần thăm dò mới. Chấp nhận agent_count (1–10, tối đa 10) để chạy nhiều tác nhân song song với các chiến lược riêng: happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom. Công cụ này không thể cấu hình thông tin xác thực hoặc chế độ xác thực. Cấu hình và khởi chạy Chỉ luồng đăng nhập kiểm thử một cách rõ ràng qua bảng điều khiển hoặc REST, sau đó sử dụng get_exploration và get_exploration_run để kiểm tra cấu hình và kết quả. Không bao giờ suy luận chế độ từ hướng dẫn hoặc đặt thông tin xác thực trong đối số MCP. Thăm dò dựa trên thông tin xác thực mặc định vẫn yêu cầu phiên tái sử dụng.
get_exploration — Nhận cấu hình thăm dò với cài đặt tác nhân, siêu dữ liệu xác thực an toàn và các lần chạy gần đây. Mật khẩu và bản mã hóa không bao giờ được trả về.
get_exploration_run — Nhận kết quả chạy với tiến trình từng tác nhân, dữ liệu giai đoạn, phát hiện có ghi công tác nhân (agent_index, agent_strategy) và lỗi được liên kết
get_exploration_usage — Kiểm tra mức sử dụng hàng tháng. AI Thăm dò chỉ dành cho Enterprise; Enterprise: không giới hạn (10 tác nhân)

Quy trình Ví dụ

create_exploration với agent_count: 5 → cấu hình 5 tác nhân song song
Kích hoạt một lần chạy từ bảng điều khiển hoặc qua POST /api/explorations/run
get_exploration_run → thăm dò tiến trình và phát hiện từng tác nhân
Xem các phát hiện đã khử trùng lặp với ghi công tác nhân trong bảng điều khiển

📝

Ghi chú

list_notes — Liệt kê ghi chú với bộ lọc tùy chọn từ khóa, dự án, khả năng hiển thị, thư mục, thẻ, lưu trữ, wiki, phạm vi ngày và sắp xếp. Trả về ghi chú người dùng sở hữu hoặc ghi chú được chia sẻ với họ.
create_note — Tạo ghi chú ở một trong 5 định dạng: markdown, plain, bugtemplate, checklist, outline. Đặt visibility thành private hoặc shared. Tự động đặt tiêu đề từ 30 ký tự đầu tiên nếu không có tiêu đề. Mảng attachments tùy chọn chấp nhận tệp mã hóa base64 tối đa 400 MB mỗi tệp: bất kỳ hình ảnh, video, âm thanh, PDF hoặc văn bản/JSON nào. Truyền time_spent_seconds để theo dõi nỗ lực QA.
get_note — Nhận chi tiết ghi chú đầy đủ bao gồm nội dung và tệp đính kèm. Yêu cầu id.
update_note — Cập nhật tiêu đề, nội dung, định dạng, khả năng hiển thị, dự án hoặc time_spent_seconds. Truyền mảng attachments để thêm tệp mới (tối đa 400 MB mỗi tệp) vào tệp đính kèm hiện có của ghi chú mà không thay thế chúng. Chỉ tác giả mới có thể cập nhật. Yêu cầu id.
delete_note — Xóa vĩnh viễn một ghi chú và tệp đính kèm của nó. Chỉ tác giả mới có thể xóa. Yêu cầu id.
list_note_folders — Liệt kê thư mục ghi chú/wiki, tùy chọn giới hạn trong một dự án.
create_note_folder — Tạo thư mục ghi chú/wiki theo phạm vi dự án với cài đặt tùy chọn thư mục cha, khả năng hiển thị, yêu thích và quyền truy cập của đồng nghiệp.

Quy trình Ví dụ

create_note → bắt đầu ghi chú phiên kiểm thử
update_note → thêm quan sát khi bạn kiểm thử
list_notes → tìm kiếm ghi chú trước đây theo từ khóa hoặc dự án
get_note → truy xuất ghi chú đầy đủ với tệp đính kèm

🤖

Tự động hóa

create_automation — Tạo một automation mới với script Playwright tùy chỉnh (không cần ghi hình FAB). Yêu cầu name. Tùy chọn: target_url (tự động suy ra từ URL page.goto(...) đầu tiên trong script nếu bỏ trống), script (Node.js/JavaScript/TypeScript hoặc Python — ngôn ngữ được tự động phát hiện; mặc định là một placeholder), status (draft hoặc active, mặc định: draft), project_id. Trả về id của automation. Mẹo — Nhân bản một automation: sử dụng get_automation để lấy script gốc, sau đó gọi create_automation với name được đặt thành "[Copy] Original Name" và truyền script, target_url, và project_id gốc. Bản nhân bản bắt đầu ở trạng thái draft mà không có lịch sử phiên bản.
list_automations — Liệt kê các script automation Playwright. Lọc theo project_id hoặc status (draft, active, paused). Trả về mảng các automation với tên, target_url, last_run_status, và run_count.
get_automation — Lấy chi tiết đầy đủ của automation bao gồm script Playwright và các lần chạy gần đây. Yêu cầu id. Trả về automation với script trực tiếp, một ngăn xếp script_versions (cũ nhất trước, tối đa 100 mục trước đó, mỗi mục là { script, source, timestamp }), và một mảng recent_runs trong đó mỗi lần chạy mang script_version_label / script_version_source đã thực thi. Gọi hàm này trước run_automation nếu bạn cần chọn một phiên bản lịch sử cụ thể.
run_automation — Kích hoạt một lần chạy ngay lập tức của một bài kiểm tra Playwright. Yêu cầu automation_id. Bộ định vị tự phục hồi (tự động): khi một hành động định vị hết thời gian chờ, trình chạy sẽ hỏi Claude để tìm một bộ chọn hoạt động và thử lại bước đó một lần — các assertion không bao giờ được phục hồi, vì vậy các lỗi thực sự vẫn thất bại — và mỗi lần phục hồi được ghi lại trong stdout của lần chạy. Chế độ mô phỏng (mặc định): device tùy chọn cho hồ sơ thiết bị mô phỏng (ví dụ: desktop, iphone-15). Chế độ thực: đặt browserstack: true với bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X), và bs_os_version để chạy trên trình duyệt máy tính để bàn thực. Di động thực: đặt bs_os: "android" (thiết bị: "Samsung Galaxy S25 Ultra", "Google Pixel 10", "OnePlus 13R") hoặc bs_os: "ios" (thiết bị: "iPhone 17 Pro Max", "iPhone 16 Pro Max", "iPhone 15 Pro Max") và truyền tên thiết bị trong bs_os_version. Cả hai chế độ chạy trong nền; Real mô tả môi trường thực thi, không phải phiên tương tác hiển thị. Script Node.js định tuyến qua browserstack-node-sdk (bao gồm desktop + Android + iPhone). Script Python định tuyến qua browserstack-sdk (pytest-playwright) và chỉ bao gồm desktop — di động thực qua Python không được hỗ trợ vì browser_type.connect() của pytest-playwright không thể điều khiển các điểm cuối di động thực của BrowserStack. Video và nhật ký mạng được thu thập tự động; nhật ký console chỉ dành cho desktop. Phát lại phiên bản: kiểm tra script_versions bằng get_automation, sau đó truyền version_label bền vững ưa thích (ví dụ "v103"). version_index kế thừa vẫn được hỗ trợ nhưng không được kết hợp với version_label. Mặc định: khi cả hai bộ chọn bị bỏ trống, script đã lưu hiện tại sẽ chạy. Các nhãn đã cắt tỉa và chỉ mục không hợp lệ bị từ chối thay vì chạy hiện tại một cách im lặng. Bản ghi lần chạy lưu trữ chính xác snapshot đã chạy, và bất kỳ báo cáo lỗi nào được tự động tạo từ một lần chạy thất bại sẽ liên kết sâu trở lại phiên bản đó trong trình chỉnh sửa.
list_automation_runs — Liệt kê các lần chạy gần đây cho một automation. Yêu cầu automation_id. Trả về các lần chạy với trạng thái, duration_ms, và error_message.
list_schedules — Liệt kê tất cả các lần chạy automation web đã lên lịch với cron_expression có thể null, run_at có thể null, once_status, múi giờ, thiết bị, và cài đặt thông báo. Các hàng định kỳ giữ run_at và once_status là null; các hàng một lần có cron null. Trạng thái một lần: pending, claimed, missed, dispatched, failed, uncertain. Đây là các trạng thái điều phối, không phải kết quả kiểm tra; kiểm tra list_automation_runs để biết kết quả.
Lịch trình web định kỳ: create_schedule xác thực năm trường cron số và múi giờ, và trả về next_run_at UTC trong tương lai. Các lần lặp lại hàng tháng và hàng năm được hỗ trợ. Ví dụ: 30 12 23 9 * trong America/Toronto có nghĩa là ngày 23 tháng 9 lúc 12:30 mỗi năm, không phải là một lần chạy một lần. Thời gian không hợp lệ hoặc không thể xảy ra bị từ chối trước khi tạo. Khi cả ngày trong tháng và ngày trong tuần bị giới hạn, cả hai phải khớp. Thời gian tiết kiệm ánh sáng ban ngày không tồn tại bị bỏ qua; thời gian đồng hồ lặp lại có thể xảy ra hai lần. Việc điều phối xảy ra ở lần thăm dò tiếp theo của bộ lập lịch, không nhất thiết ở phút chính xác. Hành vi định kỳ hiện tại không thay đổi.
Lịch trình web một lần: gọi create_schedule với { "automation_id": "AUTOMATION_UUID", "run_at": "2030-12-15T09:30:00-05:00", "timezone": "America/Toronto" }, chọn một ngày trong tương lai và bỏ trống cron_expression. Cung cấp chính xác một trường thời gian. run_at yêu cầu dấu thời gian ISO 8601 trong tương lai có bù giờ (bù giờ rõ ràng hoặc Z); múi giờ IANA chỉ để hiển thị. Một lịch trình đang chờ được kích hoạt sẽ thực thi ở lần thăm dò cron đầu tiên sau khi đến hạn; trễ hơn một giờ được đánh dấu missed. Nó được xác nhận nguyên tử và bị vô hiệu hóa trước khi điều phối, và không thể được kích hoạt lại sau khi đã tiêu thụ. Các lỗi điều phối chắc chắn là failed; điều phối không rõ ràng là uncertain và không bao giờ được tự động thử lại. Kiểm tra các lần chạy trước khi lên lịch một lần thử khác. dispatched không có nghĩa là hoàn thành hoặc vượt qua. Việc tạo chỉ qua API/MCP, không phải là chế độ tạo mới trên dashboard.
Múi giờ lịch trình web là mã định danh IANA như America/Argentina/Buenos_Aires. Trình chọn trên dashboard bao gồm tất cả các khu vực và thành phố được máy chủ hỗ trợ và mặc định theo múi giờ hồ sơ của bạn; múi giờ mặc định của MCP vẫn là UTC.
create_schedule — Tạo một lần chạy automation web đã lên lịch. Yêu cầu automation_id và chính xác một trong cron_expression hoặc run_at. Hỗ trợ thiết bị, múi giờ, thông báo lỗi, email, và cài đặt kênh Slack tùy chọn. Kết nối Slack qua dashboard trước và chọn một kênh mà bot thuộc về; chỉ cài đặt webhook là không đủ. Xem Thiết lập Slack và khám phá kênh.
Triển khai và phục hồi một lần: áp dụng migration cơ sở dữ liệu 374_one_time_web_schedules.sql trước khi triển khai mã API/MCP và bộ lập lịch tương ứng. claimed có thể tồn tại sau sự cố worker: kiểm tra lịch sử chạy trước khi tạo bản thay thế cho bất kỳ điều phối nào đã xác nhận hoặc không chắc chắn. Một dấu thời gian trễ hơn một giờ không bao giờ được tự động thực thi.
Automation web nháp: kích hoạt automation trước khi tạo lịch trình, kích hoạt lại lịch trình, hoặc thay đổi biểu thức cron hoặc múi giờ của nó. create_schedule xác minh quyền truy cập workspace và dự án trước khi từ chối trạng thái Draft. Các lịch trình hiện có bỏ qua chu kỳ trong khi automation ở trạng thái Draft; tạm dừng, xóa, ghim, và các thay đổi chỉ thông báo vẫn khả dụng. Không có công cụ MCP update_schedule web; sử dụng dashboard cho các cập nhật đó.
delete_schedule — Xóa một lần chạy automation web đã lên lịch
list_mobile_schedules — Liệt kê tất cả các lần chạy automation di động đã lên lịch với thiết bị, cron, múi giờ, và thông báo
create_mobile_schedule — Tạo một lần chạy automation di động đã lên lịch trên thiết bị thực. Yêu cầu automation_id và cron_expression; devices là tùy chọn.
delete_mobile_schedule — Xóa một lần chạy automation di động đã lên lịch
optimize_automation_script — Gửi một script Playwright đến Sonnet 4 để tối ưu hóa bằng AI. Áp dụng danh sách kiểm tra 12 điểm sửa bộ chọn, chiến lược chờ, assertion, xử lý lỗi, mẫu xác thực, tương thích di động, và chế độ nghiêm ngặt. Yêu cầu automation_id. Phiên bản script hiện tại được lưu trước khi tối ưu hóa. Trả về script đã tối ưu và tóm tắt thay đổi.
undo_automation_script — Khôi phục script automation về phiên bản trước đó. Tối đa 100 phiên bản trước được giữ lại. Yêu cầu automation_id. Trả về script đã khôi phục và số phiên bản còn lại.

Quy trình Ví dụ

create_automation → tạo một bài kiểm tra với script tùy chỉnh
list_automations → duyệt các bài kiểm tra có sẵn
get_automation → kiểm tra script Playwright
run_automation → kích hoạt bài kiểm tra
list_automation_runs → kiểm tra kết quả và thời lượng

⏱️

Theo dõi Thời gian

list_time_entries — Liệt kê các mục thời gian cho nhóm. Lọc theo period (today, week, month, all), project_id, category, và sort (newest, oldest, most_time, least_time). Chỉ dành cho gói Enterprise.
create_time_entry — Ghi lại thời gian dành cho các nhiệm vụ QA. Yêu cầu description, category, và duration_minutes. Tùy chọn đặt project_id và entry_date (mặc định là hôm nay). Chỉ dành cho gói Enterprise.
update_time_entry — Cập nhật một mục thời gian hiện có. Yêu cầu id. Có thể cập nhật description, category, duration_minutes, project_id, hoặc entry_date. Chỉ dành cho gói Enterprise.
delete_time_entry — Xóa vĩnh viễn một mục thời gian. Yêu cầu id. Chỉ dành cho gói Enterprise.

Quy trình Ví dụ

create_time_entry → ghi lại 45 phút kiểm tra hồi quy
list_time_entries → xem các mục thời gian của tuần này
update_time_entry → điều chỉnh thời lượng hoặc danh mục
delete_time_entry → xóa một mục không chính xác

☑️

Test Cases

Quản lý kiểm tra với các thư mục phân cấp, bộ kiểm tra lồng nhau (tối đa 3 cấp độ sâu với tự động mở rộng bộ con khi chạy), sắp xếp lại bằng kéo-thả, và tab Phân tích Báo cáo với xu hướng KPI, phân tích lỗi, sức khỏe bộ kiểm tra, phạm vi bao phủ, và năng suất người kiểm tra. Tất cả các công cụ gọi Supabase trực tiếp — không có vòng lặp HTTP, độ trễ tương tự như dashboard.

Giới hạn miễn phí: 10 test case được lưu trữ, 1 bộ kiểm tra, 3 thư mục, 128 KB nội dung có cấu trúc cho mỗi case, 2 khóa API workspace hoạt động, và 10 tổng số lần chạy kiểm tra mỗi tháng dương lịch UTC. Tối đa 3 trong số các lần chạy đó có thể sử dụng Hermes hoặc một tác nhân bên ngoài khác, với 1 lần chạy bên ngoài hoạt động và tối đa 10 case trong mỗi gói bên ngoài. Lưu lượng MCP khóa API miễn phí bị giới hạn ở 30 yêu cầu mỗi khóa và 60 mỗi workspace mỗi phút. Lưu trữ test case và lần chạy Enterprise là không giới hạn, tuân theo các bảo vệ nền tảng chung.

Tạo test case bằng AI, gợi ý thẻ AI, nhập Figma, và tệp đính kèm test case yêu cầu Enterprise. Giới hạn nội dung có cấu trúc 128 KB miễn phí tách biệt với tệp đính kèm Enterprise. Miễn phí có thể lưu trữ tham chiếu URL. Các công cụ test case MCP cốt lõi vẫn khả dụng trên gói Miễn phí trong các giới hạn trên.

Thực thi rảnh tay: trang đánh giá lần chạy là một băng chuyền với một case hiển thị tại một thời điểm, phím tắt (P Pass · F Fail · B Block · S Skip), và điều khiển bằng giọng nói. Nhấp vào mic, sau đó nói "Pass", "Fail", "Block", "Skip", "Next", "Previous", "Add notes" (phiên âm vào trường ghi chú), "Save notes", hoặc "Voice off". Tự động chuyển đến case chưa kiểm tra tiếp theo khi kết quả thành công; giữ nguyên trên Fail để người kiểm tra có thể đọc chi tiết và tạo lỗi. Hoạt động trong Chrome, Edge, và Safari.

Cases & Folders

list_test_cases — Liệt kê các test case có thể truy cập với bộ chọn project tùy chọn cùng các bộ lọc search, priority, type, status và sort. Thêm folder_id (null cho các case chưa được phân loại) hoặc suite_id để chỉ định thành viên trực tiếp, không bao gồm các case con. Người gọi bằng API key yêu cầu test_cases:read. limit mặc định là 50 (1-200); offset mặc định là 0 (0-1000000). Mảng cases không thay đổi đi kèm với total / total_count cho tất cả các kết quả khớp được ủy quyền, limit, offset, has_more và next_offset có thể null. Trước đây total được hiểu sai là độ dài trang. Theo dõi next_offset cho đến khi null; không suy luận hoàn tất từ độ dài trang. Việc tiếp tục vượt quá offset 1000000 sẽ thất bại rõ ràng; hãy thu hẹp bộ lọc thay vì nhận một con trỏ không dùng được hoặc hoàn tất sai. Các trang vượt quá 1 MiB dữ liệu case sẽ thất bại rõ ràng: thử lại với giới hạn nhỏ hơn, thay vì chấp nhận các bản ghi bị bỏ sót. Việc phá vỡ liên kết ID ổn định được sử dụng, nhưng các chỉnh sửa đồng thời có thể làm dịch chuyển các trang offset.
Ví dụ phân trang: gọi list_test_cases với {"project":"test-bed","limit":50,"offset":0}. Với 55 kết quả khớp, phản hồi có total:55, has_more:true, next_offset:50. Lặp lại với offset:50 cho năm kết quả còn lại và has_more:false, next_offset:null.
create_test_case — Tạo một test case trong bộ chọn project bắt buộc (UUID, slug, tên chính xác hoặc tiền tố ticket; gọi list_projects trước). Hai biến thể mẫu: steps (mặc định) — lưới { action, expected } theo từng bước qua mảng steps; text — mô tả tự do duy nhất qua text_content. Cả hai trường có thể được gửi trong cùng một lệnh gọi. Mảng urls tùy chọn (tối đa 10 URL http/https) đính kèm các liên kết tham chiếu và có sẵn trên gói Free. Đính kèm tệp yêu cầu Enterprise và phiên bảng điều khiển. Người gọi bằng API key yêu cầu test_cases:write.
Khôi phục phân trang: yêu cầu một offset case vượt quá kết quả có sẵn sẽ trả về lỗi rõ ràng; khởi động lại ở offset 0. Điều này cũng có thể xảy ra khi các case bị xóa giữa các yêu cầu. Theo dõi phần tiếp tục được trả về thay vì đoán offset tiếp theo.
Định danh case: list_test_cases, get_test_case, create_test_case và update_test_case trả về UUID id, short_id bất biến (ví dụ TEST-BA-CASE-123) và case_number dạng số, bao gồm cả các phản hồi cập nhật gọn/không thay đổi. Các case kế thừa không có dự án sử dụng TEST-CASE-123. Các định danh bị thiếu được trả về dưới dạng null; sử dụng UUID làm phương án dự phòng. Cơ sở dữ liệu gán định danh; người gọi không thể thay đổi chúng hoặc chọn chúng khi tạo. Việc đổi tên tiền tố không viết lại các ID hiện có.
Tra cứu một case: get_test_case và update_test_case chấp nhận UUID hoặc short ID đầy đủ trong id; link_test_case_to_bug và list_test_case_links chấp nhận một trong hai trong case_id. Khoảng trắng xung quanh, chữ hoa/thường và phần đệm số được chuẩn hóa trước khi tra cứu chính xác trong workspace đang hoạt động. Ủy quyền sử dụng workspace và dự án đã lưu, không phải tiền tố ID. Số trần, ID một phần và tìm kiếm ký tự đại diện không được chấp nhận. Mảng case hàng loạt, case_id kết quả thực thi, ID lỗi, ID thư mục và ID bộ thử nghiệm vẫn chỉ dùng UUID. Bản ghi liên kết giữ UUID case_id.
Khoảng trống số thứ tự: số case không cần liên tục. Chỉnh sửa URL hoặc tăng số có thể dẫn đến case bị thiếu hoặc không thể truy cập; đó không phải là hành động đảm bảo case tiếp theo. Khám phá case bằng công cụ danh sách và theo dõi phân trang của nó.
Phạm vi workspace: cùng một short ID có thể tồn tại trong các workspace khác nhau. MCP chỉ giải quyết nó trong workspace đang hoạt động; chuyển ngữ cảnh workspace trước khi sử dụng short ID của workspace khác. Khi chia sẻ URL short-ID của bảng điều khiển, hãy giữ ?team=<case.team_id>, ví dụ /dashboard/test-cases/TEST-BA-CASE-123?team=<team-uuid>. Liên kết cố định UUID giữ hành vi xuyên workspace được ủy quyền hiện có. MCP không xây dựng liên kết cố định.
get_test_case — Lấy bản ghi case được ủy quyền, bao gồm các bước và định danh. Không tải lịch sử thay đổi hoặc lịch sử thực thi. Ví dụ: {"id":"TEST-BA-CASE-123"}.
Ước tính thực thi: get_test_case trả về estimated_time_seconds và bí danh tương thích estimated_time, cả hai đều tính bằng giây. Một 0 đã lưu vẫn là 0; ước tính không xác định hoặc bị thiếu là null. Trường chuẩn thắng khi cả hai tên đều có mặt, bao gồm cả null rõ ràng; các giá trị estimated_time chỉ kế thừa được coi là giây mà không chuyển đổi. list_test_cases sử dụng estimated_time_seconds. Đầu vào create_test_case vẫn là estimated_time, cũng tính bằng giây; yêu cầu và phản hồi REST sử dụng estimated_time_seconds.
list_test_case_folders — Liệt kê các thư mục có thể truy cập. Giới hạn ở 500; chấp nhận bộ chọn project linh hoạt và bộ lọc parent_folder_id (sử dụng "root" cho chỉ cấp cao nhất). Người gọi bằng API key yêu cầu test_cases:read.
get_test_case_folder — Đọc trực tiếp một thư mục test case với id bắt buộc (UUID). Chỉ trả về bản ghi thư mục, không tải ngầm các thư mục con hoặc test case. Yêu cầu quyền truy cập vào workspace và dự án của nó; người gọi bằng API key yêu cầu test_cases:read.
Các giá trị type của test case cho list_test_cases, create_test_case và bulk_update_test_cases: functional (mặc định khi tạo), regression, smoke, integration, performance, security, usability, exploratory. Các loại không hợp lệ bị từ chối trước khi ghi. Sử dụng integration cho các luồng end-to-end; e2e, accessibility và other không được chấp nhận là loại test case. Các loại tập lệnh tự động hóa là một hợp đồng riêng.
create_test_case_folder — Tạo một thư mục trong project bắt buộc được trả về bởi list_projects (lồng tối đa 3 cấp qua parent_folder_id). Yêu cầu quyền truy cập workspace từ cộng tác viên trở lên và quyền truy cập vào dự án. Người gọi bằng API key cũng yêu cầu test_cases:write.
update_test_case_folder — Cập nhật theo UUID thư mục: id, name tùy chọn (được cắt bớt, 1-120 ký tự), description có thể null (tối đa 50000 ký tự), parent_folder_id có thể null và card_color có thể null. UUID cha di chuyển thư mục và cây con của nó trong cùng workspace và dự án; null di chuyển nó về gốc. Màu chấp nhận bảng màu chữ thường #1e293b, #7c2d12, #713f12, #14532d, #1e3a5f, #312e81, #581c87, #831843, #4a044e, #fef08a, #fca5a5, #93c5fd; null xóa nó. Các trường bị bỏ qua được giữ nguyên. Ít nhất một trường cập nhật là bắt buộc. Các trường không xác định, sai chính tả hoặc không hợp lệ sẽ từ chối toàn bộ yêu cầu mà không lưu thay đổi nào. Các vòng lặp tự/thư mục con, tên trùng với thư mục anh em, cha trực tiếp hoặc con trực tiếp (bỏ qua chữ hoa/thường và khoảng trắng xung quanh) và độ sâu cây con trên 3 (độ sâu gốc 0) bị từ chối. Độ sâu thư mục con cập nhật nguyên tử; ID case và tư cách thành viên không thay đổi. Các thay đổi đồng thời xung đột có thể thất bại; đọc lại thư mục trước khi thử lại. Yêu cầu quyền truy cập dự án từ cộng tác viên trở lên đang hoạt động và test_cases:write cho API key. Ví dụ: {"id":"folder-uuid","card_color":"#93c5fd"}. Trả về id, team_id, project_id, name, description, card_color, parent_folder_id, depth và updated_at đã cập nhật. Các thao tác đọc get/list thư mục cũng bao gồm card_color.
update_test_case — Vá một case hiện có bằng UUID hoặc short ID đầy đủ trong id, với ít nhất một trường: name (hoặc bí danh title), description, preconditions, steps, template_type, text_content, priority, type, status hoặc folder_id. Các trường bị bỏ qua được giữ nguyên; steps thay thế toàn bộ mảng ([] xóa). null rõ ràng xóa mô tả, điều kiện tiên quyết, text_content hoặc vị trí thư mục; text_content trống cũng xóa. Nếu cả name và title được gửi, chúng phải khớp. Ưu tiên và loại sử dụng các enum khi tạo; trạng thái là active, draft hoặc deprecated. Thay đổi loại sẽ căn chỉnh type_tags với loại mới, khớp với PATCH API. Không di chuyển workspace/dự án hoặc ghi siêu dữ liệu tệp. Các thư mục phải chia sẻ chính xác workspace và dự án. Yêu cầu test_cases:write. Trả về tóm tắt case, id, short_id, case_number và changed; các giá trị không thay đổi tạo ra changed: false. Một cập nhật được xác nhận với mục lịch sử chưa xác nhận trả về warnings; không lặp lại cập nhật để sửa lịch sử. Khi gặp lỗi thay đổi đồng thời, hãy đọc lại case trước khi thử lại. Tư cách thành viên bộ thử nghiệm là riêng biệt: sử dụng công cụ hàng loạt bên dưới, không phải suite_id trên công cụ này. Không có công cụ xóa nào được hiển thị.
bulk_update_test_cases — Áp dụng một hành động cho 1–500 UUID case; truyền một ID cho một case đơn lẻ. set_folder nhận params.folder_id (UUID để di chuyển, null rõ ràng để bỏ phân loại). add_to_suite và remove_from_suite nhận params.suite_id; việc thêm không bao giờ xóa các tư cách thành viên khác hoặc di chuyển thư mục. Cũng hỗ trợ set_priority, set_status, set_type, add_tags, remove_tags, pin và unpin. API key yêu cầu test_cases:write. Trả về applied, skipped và errors; các hành động tổ chức đếm các hàng thay đổi được xác nhận, loại bỏ trùng lặp ID và bỏ qua các tư cách thành viên hiện có.
Vị trí khi tạo: create_test_case chấp nhận folder_id và suite_id tùy chọn. Khám phá mục tiêu bằng list_test_case_folders và list_test_suites (khám phá bộ thử nghiệm yêu cầu test_runs:read cho API key). Thư mục là một vị trí danh mục duy nhất; bộ thử nghiệm là tư cách thành viên kế hoạch thử nghiệm nhiều-nhiều. Các mục tiêu phải thuộc cùng workspace được ủy quyền và chính xác dự án, bao gồm cả các case kế thừa không có phạm vi. Các ID case không thể truy cập bị bỏ qua mà không có chi tiết; các mục tiêu không khớp bị từ chối. Các mục tiêu tạo không hợp lệ thất bại trước khi tạo case.
Tạo một phần: tạo case và đính kèm bộ thử nghiệm là các thao tác ghi riêng biệt. Nếu đính kèm thất bại, phản hồi trả về ID case đã tạo, suite_id: null và mảng warnings. Không lặp lại create_test_case; thử lại bulk_update_test_cases với add_to_suite cho ID đã trả về đó.
link_test_case_to_bug — Thiết lập khả năng truy vết giữa một test case và UUID báo cáo lỗi (verified_by, covers hoặc relates). Cả hai bản ghi phải thuộc workspace đang hoạt động và các dự án mà người gọi có thể truy cập.
list_test_case_links — Liệt kê tất cả các liên kết truy vết cho một test case.
list_test_case_review_candidates — Cờ test chết: never_run (90+ ngày kể từ khi tạo), always_passes (5+ lần vượt qua liên tiếp trong 90 ngày), always_skipped (3+ lần bỏ qua liên tiếp).
mark_test_case_review_flags — Lưu các cờ ứng viên lưu trữ hiện tại vào test_cases.review_flag. Chạy tự động mỗi Thứ Hai lúc 09:00 UTC qua pg_cron.

Nhập

Nhập Figma (Enterprise) (chỉ phiên bảng điều khiển): tải lên bản xuất zip của các khung Figma (tối đa 100 MiB), Claude phân tích từng màn hình và soạn thảo các test case vào một thư mục bạn chọn hoặc tạo. Trước khi giải mã, kho lưu trữ được giới hạn ở 1.000 mục, 20 MiB mở rộng (đã giải mã) cho mỗi mục và 100 MiB dữ liệu mở rộng tổng hợp, bao gồm cả các tệp và thư mục bị bỏ qua trong ngân sách. Các bộ đệm khung đã giải mã phải khớp với kích thước khai báo của chúng. Kho lưu trữ sai định dạng, không khớp kích thước và vượt quá giới hạn sẽ làm hỏng công việc trước khi phân tích AI; bản tải lên gốc được giữ lại khi thất bại để thử lại, tùy thuộc vào chính sách dọn dẹp lưu trữ. Các kho lưu trữ hợp lệ đi vào quy trình nhiều giai đoạn (phân loại → case theo màn hình → case cấp luồng qua các màn hình có tiền tố chung → tự phê bình) với bộ nhớ đệm lời nhắc, thử lại 429 và cách ly lỗi AI theo khung. Các case được tạo dưới dạng status=active, được gắn thẻ ai_generated=true, với source='figma' và source_frame_name giữ liên kết đến khung gốc. Sử dụng khóa Anthropic của nền tảng — không yêu cầu kết nối Claude riêng cho từng nhóm.

Bộ thử nghiệm & Lần chạy

list_test_suites — Liệt kê tối đa 50 bộ kiểm thử có thể truy cập với bộ lọc project linh hoạt tùy chọn. Mỗi bộ bao gồm một số nguyên chính xác case_count: các ca được gán trực tiếp ở mọi trạng thái, không bao gồm các ca con, loại trừ các ca thuộc không gian làm việc hoặc dự án khác (các ca cũ không thuộc dự án vẫn được bao gồm). Số lượng không bị giới hạn bởi số hàng thành viên được tải. Người gọi bằng khóa API yêu cầu test_runs:read để tương thích ngược với các worker thực thi.
get_test_suite — Đọc trực tiếp một bộ kiểm thử với id bắt buộc (UUID). Chỉ trả về bản ghi bộ kiểm thử, không tự động tải các bộ con hoặc các ca kiểm thử thành viên. Yêu cầu quyền truy cập vào không gian làm việc và dự án của nó; người gọi bằng khóa API yêu cầu test_runs:read.
create_test_suite — Tạo một bộ trong project bắt buộc được trả về bởi list_projects. Lồng tối đa 3 cấp qua parent_suite_id. Người gọi bằng khóa API yêu cầu test_cases:write.
update_test_suite — Cập nhật theo UUID bộ: id, name tùy chọn (được cắt khoảng trắng, 1-120 ký tự), description có thể null (tối đa 50000 ký tự) và status (active/archived). Các trường bị bỏ qua và tư cách thành viên ca được giữ nguyên. Yêu cầu quyền truy cập dự án ở mức cộng tác viên trở lên đang hoạt động và test_cases:write. Di chuyển bộ cha và ghim không được hỗ trợ; di chuyển bộ cha yêu cầu duy trì độ sâu hậu duệ một cách nguyên tử. Trả về id, team_id, project_id, name, description, parent_suite_id, depth, status và updated_at. Ví dụ: {"id":"suite-uuid","name":"Checkout regression","description":null}.
list_test_runs — Liệt kê các lần chạy kiểm thử với tên bộ, người được giao và tóm tắt đạt/không đạt.
create_test_run — Tạo một lần chạy bộ do bảng điều khiển quản lý. Chạy một bộ cha tự động bao gồm mọi ca trong mọi bộ con hậu duệ (một ca được liên kết với cả hai chỉ được thêm đúng một lần). Mỗi hàng test_run_results ghi lại bộ con nguồn mà ca đến từ đó, để các trang kết quả có thể nhóm theo nguồn gốc.

Thực thi tác nhân bên ngoài

Các công cụ này cho phép Hermes hoặc một môi trường chạy tác nhân khác thực thi một bộ đã được phê duyệt mà không trở thành hệ thống lưu trữ hồ sơ QA. Sử dụng khóa có phạm vi không gian làm việc chỉ với test_runs:read và test_runs:write. Bộ cung cấp ranh giới dự án; người gọi không thể ghi đè nó.

start_test_plan — Bắt đầu hoặc tiếp tục một ảnh chụp bộ bất biến với external_run_id ổn định. Một ID lặp lại trả về lần chạy khớp hiện có và trang đầu tiên thay vì tạo bản sao.
get_test_run_plan — Đọc trạng thái chạy chuẩn và một trang kế hoạch ổn định. Truyền next_cursor trước đó; các trang mặc định là 100 ca và giới hạn ở 200.
report_test_results — Gửi 1–200 kết quả với trạng thái passed, failed, blocked hoặc skipped. Thử lại chính xác là an toàn; cố gắng ghi đè một ca bằng trạng thái khác sẽ bị từ chối.
abort_test_run — Dừng một lần chạy bị gián đoạn một cách bất biến trong khi vẫn giữ các kết quả một phần đã chấp nhận và tóm tắt chuẩn.

Hành vi hạn mức: thử lại start_test_plan với cùng external_run_id để tiếp tục lần chạy khớp mà không tiêu tốn thêm một lần chạy. Xóa dữ liệu không đặt lại việc sử dụng lần chạy hàng tháng.

Ranh giới thời gian chạy: ảnh chụp ca loại trừ thông tin xác thực, nội dung tệp và đường dẫn tệp đính kèm riêng tư. Bằng chứng kết quả là văn bản trong MVP. Thông tin xác thực mục tiêu vẫn nằm trong môi trường thực thi. Chi phí trình duyệt, mô hình và mạng vẫn thuộc phía khách hàng, và khách hàng phải hạn chế quyền truy cập mục tiêu và lưu lượng mạng ra ngoài. Một con người vẫn chịu trách nhiệm về các quyết định lỗi và phát hành.

Hướng dẫn tác nhân Hermes đóng gói vòng lặp này như một kỹ năng cộng đồng do bugAgent duy trì. Bộ khởi động công khai chứa cấu hình sẵn sàng sao chép và kỹ năng có thể cài đặt. Đây không phải là tích hợp chính thức của Nous Research.

Báo cáo (Phân tích Tier 1 + Tier 4)

get_test_reports_overview — Các KPI chính cho một khoảng thời gian (tỷ lệ đạt, số lần chạy hoàn thành, số ca đã thực thi) với chênh lệch so với khoảng thời gian tương đương trước đó. Cùng các con số mà dải KPI trên tab Báo cáo hiển thị. Điều này không tạo Báo cáo dự án đã lưu. Báo cáo dự án XLSX Enterprise và lịch trình của chúng được quản lý trong bảng điều khiển; không có công cụ MCP nào được bật cho các tạo phẩm đã lưu đó trong bản phát hành này.
get_test_reports_failures — Bốn danh sách "cần sửa gì?": failing_cases (≥50% không đạt, tối thiểu 3 lần chạy), flaky_cases (nhiều lần đảo đạt/không đạt nhất), failing_suites (≥30% không đạt, tối thiểu 5 lần chạy), regressed_cases (lần không đạt gần nhất với lần đạt trước đó trong khoảng thời gian).

Quy trình ví dụ

create_test_case_folder → tạo cây thư mục (ví dụ: Smoke → Auth). Sử dụng ID thư mục được trả về khi tạo ca kiểm thử trong cùng dự án; biểu mẫu Tạo ca kiểm thử mới của bảng điều khiển cũng cung cấp tạo thư mục nội tuyến.
create_test_case → xác định các ca; chỉnh sửa nội dung bằng update_test_case, tổ chức tư cách thành viên bộ bằng bulk_update_test_cases
Ví dụ công cụ/lệnh gọi: {"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}}. Ưu tiên, loại và mô tả bị bỏ qua vẫn không thay đổi.
create_test_suite → xây dựng kế hoạch kiểm thử (các bộ con tùy chọn, tối đa 3 cấp)
create_test_run → tạo lần chạy do con người/bảng điều khiển quản lý từ bộ cha — các bộ con tự động được bao gồm
start_test_plan → bắt đầu hoặc tiếp tục lần chạy tác nhân bên ngoài an toàn khi thử lại
get_test_run_plan → truy xuất mọi trang kế hoạch bất biến, sau đó thực thi nó trong môi trường chạy đã chọn
report_test_results → trả về các lô kết quả có giới hạn; gọi abort_test_run nếu không thể tiếp tục thực thi một cách an toàn
get_test_reports_failures → hỏi "cần sửa gì tuần này?" khi lần chạy hoàn thành
get_test_reports_overview → theo dõi xu hướng tỷ lệ đạt tuần qua tuần

⚡

Team Booster

scale_team — Mở rộng đội QA của bạn ngay lập tức với các kiểm thử viên booster. Tài khoản được cấp tự động với quyền truy cập kiểm thử viên. Chỉ định team_size (1–10), location, duration, budget và tùy chọn product_url, product_types và tech_levels. Có sẵn trên gói Enterprise. Bạn sẽ không bị tính phí cho đến khi phê duyệt được đưa ra.

Quy trình ví dụ

scale_team → cấp 5 kiểm thử viên cao cấp tại Mỹ trong 1 tháng
list_team_members → xác minh các kiểm thử viên mới xuất hiện trong đội của bạn
list_bug_reports → xem xét các báo cáo do kiểm thử viên booster gửi

📱

Kiểm thử di động (Enterprise)

Tài nguyên di động có phạm vi dự án. Truyền project_id hoặc bộ chọn project linh hoạt khi tạo, nhập và danh sách đã lọc. Tự động hóa kế thừa dự án của ứng dụng được liên kết; nếu không, máy chủ sử dụng dự án mặc định của không gian làm việc. Danh sách không lọc vẫn có thể bao gồm các hàng cấp không gian làm việc kế thừa cho đến khi chúng được di chuyển.

list_mobile_apps — Liệt kê các ứng dụng đã tải lên với các bộ lọc tùy chọn project_id / project, platform và limit. Trả về project_id của từng ứng dụng để các agent có thể giữ các thao tác tiếp theo trong cùng một dự án.
upload_mobile_app — Đăng ký ứng dụng APK (Android) hoặc IPA (iOS) để kiểm thử trên thiết bị thật. Yêu cầu name, platform (android / ios) và file_url; truyền project_id để gán ứng dụng vào dự án đang hoạt động. Đối với iOS, hãy tải IPA lên để chạy trên thiết bị thật, sau đó sử dụng bảng điều khiển để tải lên bản dựng .app cho trình mô phỏng để ghi hình.
update_mobile_app — Thay thế tệp nhị phân của ứng dụng bằng phiên bản mới. Xóa các URL đã lưu trong bộ nhớ cache và các bản dựng cho trình mô phỏng để tất cả các tự động hóa sử dụng phiên bản mới trong lần chạy tiếp theo. Yêu cầu app_id và file_url. Tùy chọn: version. Hồ sơ đăng nhập được liên kết riêng tư yêu cầu người tạo đang hoạt động của chúng; hồ sơ dùng chung yêu cầu quyền truy cập đang hoạt động vào cùng một dự án. Lịch trình kế thừa mặc định của tự động hóa được bảo vệ.
list_mobile_automations — Liệt kê các tự động hóa di động với các bộ lọc tùy chọn project_id / project, app_id, status và limit. Kết quả bao gồm project_id và ID ứng dụng được liên kết.
create_mobile_automation — Tạo một tập lệnh kiểm thử. Yêu cầu name, app_id, script_type (maestro cho YAML, appium cho Appium Python, appium_js cho Appium JavaScript) và script; truyền project_id khi ứng dụng chưa được gắn phạm vi dự án. Đối với một luồng Maestro YAML khép kín, được xác thực bên ngoài, hãy đặt execution_mode thành browserstack_maestro; nếu không, nó mặc định là appium_actions. appId YAML phải khớp với gói hoặc ID bó đã lưu của ứng dụng được liên kết; nếu không có gói nào được lưu, luồng gốc được xác thực đầu tiên sẽ thiết lập nó. ID ứng dụng giữ chỗ và ID tài nguyên Android bị làm rối sẽ bị từ chối. runFlow nội tuyến được hỗ trợ, nhưng các tham chiếu tệp luồng/tập lệnh bên ngoài bị từ chối trong v1. Maestro gốc bảo toàn các lệnh như inputRandomText và copyTextFrom cùng với các biểu thức thời gian chạy như ${maestro.copiedText} và ${output.value}. Một credential_id cùng dự án có thể cung cấp các giá trị inputText hoàn chỉnh của ${USERNAME} / ${PASSWORD}. Một variable_profile_id cùng dự án có thể lưu mặc định cho các giá trị ${DATA_*} được tham chiếu; mọi khóa được tham chiếu phải tồn tại. Hồ sơ dữ liệu chỉ là dữ liệu tổng hợp không bí mật.
import_mobile_script — Nhập một tập lệnh kiểm thử di động hiện có và biến nó thành một tự động hóa có thể chạy được, bảo toàn các bộ định vị của riêp nhà phát triển để các lần chạy giải quyết các phần tử một cách chính xác. Các phương ngữ được hỗ trợ: Appium‑Python, WebdriverIO, Maestro (luồng YAML) và Playwright (web di động). Các trình giữ chỗ ID tài nguyên Android bị làm rối sẽ được bỏ qua và báo cáo trong ánh xạ bộ chọn warnings. Chỉ dành cho ứng dụng Android. Yêu cầu name, app_id và script; tùy chọn target_devices và project_id. Trả về tự động hóa cùng với action_count, dialect được phát hiện và ánh xạ bộ chọn warnings.
run_mobile_automation — Bắt đầu một tự động hóa di động trên thiết bị thật. Yêu cầu automation_id; tùy chọn device, os_version, credential_id và variable_profile_id Maestro gốc. Đối với dữ liệu, bỏ qua variable_profile_id để kế thừa mặc định của tự động hóa, truyền null để không sử dụng hồ sơ hoặc truyền UUID cùng dự án để ghi đè. Mọi khóa ${DATA_*} được tham chiếu phải tồn tại. Hồ sơ đăng nhập riêng tư yêu cầu người tạo đang hoạt động của nó; hồ sơ đăng nhập dùng chung yêu cầu quyền truy cập cùng dự án đang hoạt động. Các giá trị thông tin xác thực đã biết chính xác được lọc và các giá trị hồ sơ dữ liệu chính xác nhận được nỗ lực lọc tốt nhất từ bằng chứng văn bản được lưu trữ; các giá trị dữ liệu đã biến đổi, một phần, được mã hóa hoặc có nguồn gốc từ ứng dụng có thể vẫn còn. Video/ảnh chụp màn hình riêng tư được ủy quyền vẫn khả dụng và có thể hiển thị các giá trị do ứng dụng được kiểm thử hiển thị, vì vậy hồ sơ dữ liệu chỉ được chứa các giá trị tổng hợp không bí mật. Nếu ngữ cảnh biên tập thông tin xác thực không khả dụng hoặc không thể chứng minh việc làm sạch an toàn, văn bản chi tiết có thông tin xác thực sẽ bị giữ lại trong khi trạng thái và bằng chứng trực quan khả dụng vẫn còn. Chẩn đoán yêu cầu ủy quyền không gian làm việc và dự án; các liên kết phương tiện hết hạn sau năm phút.
list_mobile_runs — Lấy kết quả chạy di động được ủy quyền (trạng thái, thiết bị, tóm tắt kết quả, liên kết video và ảnh chụp màn hình riêng tư, phiên BrowserStack, nhật ký Maestro gốc có thông tin xác thực đã được lọc và lỗi khi an toàn để cung cấp, cũng như bất kỳ lỗi nào được tạo tự động). Tư cách thành viên không gian làm việc và quyền truy cập dự án được thực thi cho chẩn đoán chạy. Bộ lọc tùy chọn: project_id, automation_id, status (queued, running, passed, failed, error, archived) và limit. Các lần chạy đã lưu trữ bị loại trừ theo mặc định.
create_login_profile — Tạo hồ sơ tên người dùng/mật khẩu được mã hóa chỉ ghi, có thể tái sử dụng bởi Mobile, Web Automation và Exploratory AI. Yêu cầu project_id, name, username và password; tùy chọn visibility là private (mặc định) hoặc shared. Hồ sơ riêng tư chỉ dành cho người tạo. Hồ sơ dùng chung có thể được sử dụng bởi các thành viên đang hoạt động có quyền truy cập vào cùng một dự án.
create_mobile_credential — Tên tương thích cho create_login_profile; sử dụng cùng các đầu vào và ranh giới bảo mật.
list_login_profiles — Chỉ liệt kê các hồ sơ hiển thị với người gọi, tùy chọn cho một project_id. Trả về siêu dữ liệu không bí mật bao gồm visibility; hồ sơ riêng tư thuộc sở hữu của người dùng khác và các dự án không thể truy cập bị bỏ qua.
list_mobile_credentials — Tên tương thích cho list_login_profiles; không bao giờ trả về bí mật thông tin xác thực.
update_login_profile — Đổi tên, xoay vòng hoặc thay đổi visibility. Người tạo đang hoạt động có thể cập nhật bất kỳ trường nào. Chủ sở hữu/quản trị viên không gian làm việc đang hoạt động có thể đổi tên hoặc xoay vòng hồ sơ dùng chung nhưng không thể thay đổi khả năng hiển thị; hồ sơ riêng tư vẫn chỉ dành cho người tạo.
update_mobile_credential — Tên tương thích cho update_login_profile; sử dụng cùng các kiểm tra quyền sở hữu và dự án.
delete_login_profile — Xóa mềm của người tạo, với khả năng khôi phục vòng đời của chủ sở hữu/quản trị viên chỉ cho hồ sơ dùng chung. Các mặc định sử dụng trong tương lai bị xóa trong khi lịch sử kiểm toán vẫn còn.
delete_mobile_credential — Tên tương thích cho delete_login_profile; các tham chiếu lịch sử vẫn còn để kiểm toán.
create_mobile_variable_profile — Tạo dữ liệu kiểm thử tổng hợp có thể tái sử dụng, gắn phạm vi dự án với project_id, name và một đối tượng variables như {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"}. Các khóa phải là định danh DATA_* viết hoa. Hồ sơ cho phép 1–100 chuỗi, 4096 byte UTF-8 cho mỗi giá trị và tổng cộng 65536 byte. Các tên thông tin xác thực/thời gian chạy dành riêng bị từ chối. Không bao giờ lưu trữ thông tin xác thực, mã thông báo, dữ liệu cá nhân sản xuất hoặc các bí mật khác.
list_mobile_variable_profiles — Liệt kê các hồ sơ Mobile/Cả hai và các giá trị không bí mật có thể đọc được của chúng cho một project_id được ủy quyền. Các quy tắc gán dự án được áp dụng. Các hồ sơ hiện có và việc tạo di động mặc định là both; tạo/cập nhật chấp nhận platform (mobile hoặc both). Các hồ sơ chỉ dành cho web bị loại trừ khỏi quyền truy cập danh mục di động và sử dụng thời gian chạy.
update_mobile_variable_profile — Đổi tên hồ sơ hoặc thay thế đối tượng variables hoàn chỉnh của nó bằng id. Chỉ người tạo đang hoạt động hoặc chủ sở hữu/quản trị viên không gian làm việc đang hoạt động mới có thể cập nhật nó.
delete_mobile_variable_profile — Xóa mềm hồ sơ bằng id. Chỉ người tạo đang hoạt động hoặc chủ sở hữu/quản trị viên không gian làm việc đang hoạt động mới có thể xóa nó; các mặc định tự động hóa bị xóa trong khi các tham chiếu chạy lịch sử vẫn còn.
list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — Liệt kê, tạo và xóa lịch trình thiết bị thật. Lịch trình kế thừa ngữ cảnh dự án, hồ sơ đăng nhập và hồ sơ biến không bí mật từ tự động hóa đã chọn của chúng. Hồ sơ đăng nhập riêng tư yêu cầu người tạo đang hoạt động của chúng; hồ sơ đăng nhập dùng chung yêu cầu quyền truy cập cùng dự án đang hoạt động. Hồ sơ biến không bí mật giữ chính sách người tạo-hoặc-chủ sở hữu/quản trị viên của chúng. Các thay đổi và xóa lịch trình bị giới hạn cho người tạo lịch trình đang hoạt động hoặc chủ sở hữu/quản trị viên không gian làm việc đang hoạt động.

Danh mục Dữ liệu Kiểm thử Web

Cùng một danh mục dự án không bí mật có sẵn từ Automate Web. Các công cụ này yêu cầu quyền automation của không gian làm việc và phạm vi khóa API automations:write, bao gồm cả đọc. Chúng không yêu cầu quyền truy cập Mobile. Các giá trị không bao giờ chia sẻ bản ghi với Hồ sơ Đăng nhập được mã hóa. Hỗ trợ danh mục chưa liên kết hoặc chèn các giá trị hồ sơ vào các lần chạy web.

create_web_variable_profile: bắt buộc project_id, name, variables; tùy chọn platform (web hoặc both), mặc định web. Sử dụng cùng các giới hạn DATA_* như di động. Trả về hồ sơ, bao gồm cả platform của nó.
list_web_variable_profiles: bắt buộc project_id; trả về { profiles: [...] } chỉ chứa các bản ghi Web/Cả hai.
get_web_variable_profile: bắt buộc id; trả về hồ sơ Web/Cả hai có thể truy cập và các giá trị tổng hợp của nó.
update_web_variable_profile: bắt buộc id; tùy chọn name, thay thế hoàn chỉnh variables hoặc platform (web hoặc both). Yêu cầu người tạo đang hoạt động hoặc chủ sở hữu/quản trị viên không gian làm việc đang hoạt động. Để thu hẹp Cả hai thành Mobile, hãy sử dụng danh mục Mobile với quyền truy cập Mobile.
delete_web_variable_profile: bắt buộc id; cùng các quyền quản lý. Xóa mềm và trả về { deleted: true }, giữ lại lịch sử kiểm toán.

Ví dụ: giải quyết một dự án bằng list_projects, gọi create_web_variable_profile với {"project_id":"PROJECT_UUID","name":"Canadian checkout","platform":"both","variables":{"DATA_REGION":"CA"}}, sau đó xác minh nó bằng list_web_variable_profiles. Các dự án/hồ sơ không thể truy cập sẽ thất bại mà không tiết lộ giá trị của chúng; dữ liệu không hợp lệ hoặc tên trùng lặp trên toàn dự án bị từ chối.

Quy trình Ví dụ — Android

list_projects → giải quyết project_id mục tiêu
upload_mobile_app → đăng ký APK trong dự án đó
Ghi hình an toàn trong bảng điều khiển hoặc sử dụng import_mobile_script / create_mobile_automation
list_mobile_automations → giải quyết tự động hóa trong cùng một dự án
run_mobile_automation → kích hoạt nó trên thiết bị thật, tùy chọn với hồ sơ đăng nhập
list_mobile_runs → kiểm tra trạng thái, tóm tắt kết quả, liên kết trực quan riêng tư và siêu dữ liệu phiên BrowserStack
Các lỗi tự động tạo báo cáo lỗi với ảnh chụp lỗi và phân tích bước

Quy trình Ví dụ — iOS

upload_mobile_app → đăng ký IPA của bạn với project_id để chạy trên thiết bị thật
Tải lên bản dựng .app cho trình mô phỏng trên trang chi tiết ứng dụng (để ghi hình)
Ghi lại kiểm thử trong trình duyệt → các hành động được ghi lại từ trình mô phỏng
run_mobile_automation → kích hoạt tự động hóa đã lưu trên iPhone (sử dụng IPA)
update_mobile_app → thay thế IPA bằng phiên bản mới khi sẵn sàng

Quy trình Ví dụ — Maestro Gốc

upload_mobile_app → đăng ký APK hoặc IPA trong dự án mục tiêu
create_mobile_credential → tùy chọn tạo hồ sơ cùng dự án cho luồng được xác thực
create_mobile_variable_profile → tùy chọn tạo các giá trị DATA_* tổng hợp cùng dự án được sử dụng bởi luồng
create_mobile_automation → truyền một luồng YAML đã biết hoạt động với gói/bó appId chính xác của ứng dụng được liên kết, script_type: maestro và execution_mode: browserstack_maestro. Sử dụng ${USERNAME} / ${PASSWORD} để đăng nhập và các trình giữ chỗ kiểu ${DATA_EMAIL} cho đầu vào tổng hợp; truyền ID hồ sơ để lưu mặc định.
run_mobile_automation → chọn một thiết bị tương thích và tùy chọn ghi đè hồ sơ đăng nhập hoặc biến. Bỏ qua hồ sơ biến để kế thừa hoặc truyền null để vô hiệu hóa nó cho một lần chạy.
list_mobile_runs → kiểm tra các tóm tắt đạt/không đạt được ủy quyền, video/ảnh chụp màn hình riêng tư, nhật ký đã lọc, tên bước thực, lỗi chi tiết và siêu dữ liệu phiên. Nếu không thể thiết lập việc làm sạch an toàn cho một lần chạy có thông tin xác thực, văn bản chi tiết sẽ bị giữ lại trong khi trạng thái và bằng chứng trực quan khả dụng vẫn còn.

Tinh chỉnh bằng AI: bản beta được đưa vào danh sách cho phép có sẵn thông qua bảng điều khiển và các điểm cuối tinh chỉnh REST. Chưa có công cụ MCP Refine nào trong danh mục công khai.

✅

Tuân thủ & Bằng chứng (Doanh nghiệp)

collect_compliance_evidence — Kích hoạt thu thập bằng chứng tự động từ các dịch vụ đã kết nối (Cloudflare, GitHub, Sentry, Supabase, Railway). Trả về ID chạy. Thu thập cài đặt SSL/TLS, trạng thái WAF, cảnh báo Dependabot, xu hướng lỗi, lịch sử triển khai, v.v.
check_config_drift — Kiểm tra tất cả các dịch vụ đã kết nối để phát hiện sai lệch cấu hình bảo mật so với đường cơ sở (chế độ SSL, phiên bản TLS, HSTS, quy tắc WAF, tiêu đề bảo mật).
generate_access_review — Tạo báo cáo rà soát quyền truy cập hàng quý. Kiểm toán thành viên nhóm, vai trò, trạng thái MFA, việc sử dụng khóa API và tạo khuyến nghị (ví dụ: thu hồi khóa không hoạt động).
get_security_events — Truy vấn dòng thời gian sự kiện bảo mật xuyên dịch vụ. Lọc theo nguồn (cloudflare, sentry, github) và mức độ nghiêm trọng (critical, high, medium, low, info). Các sự kiện được tự động tương quan giữa các dịch vụ.

Phạm vi tuân thủ

Các công cụ này hỗ trợ các yêu cầu tuân thủ 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) và GDPR (Điều 5, 25, 32, 33).

Máy khách tương thích

bug Agent hoạt động với bất kỳ máy khách nào hỗ trợ Model Context Protocol. Dưới đây là hướng dẫn thiết lập cho các máy khách phổ biến:

Mở Settings → Developer → Edit Config, sau đó thêm:

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

Khởi động lại Claude Desktop sau khi lưu.

✳️

Cursor

Mở Settings → MCP Servers → Add Server, hoặc chỉnh sửa .cursor/mcp.json trong thư mục gốc dự án của bạn:

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

🌊

Windsurf

Mở Settings → MCP → Add Server, hoặc chỉnh sửa tệp cấu hình MCP của bạn:

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

Thêm bug Agent trực tiếp từ terminal:

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

Điều này kết nối trực tiếp đến máy chủ Streamable HTTP được lưu trữ.

Đối với các máy khách yêu cầu stdio, hãy sử dụng cầu nối bugagent-mcp đã xuất bản:

Lệnh: npx
Dòng lệnh: npx -y bugagent-mcp
Đối số: ["-y", "bugagent-mcp"]
Biến môi trường: BUGAGENT_API_KEY

Nhận trợ giúp

Cần hỗ trợ? Chúng tôi luôn sẵn sàng giúp đỡ.

Cộng đồng Discord

Tham gia Discord của chúng tôi để được hỗ trợ theo thời gian thực và thảo luận cộng đồng.

Hỗ trợ qua Email

support@bugagent.com — Chúng tôi thường phản hồi trong vòng 24 giờ.