Sentry MCP hay dán gói bằng chứng: nên đưa gì cho coding agent

Hãy nối MCP server của Sentry khi agent phải tự tìm ra vấn đề: phân loại lỗi, lỗi mới sau một release, tìm qua nhiều project. Hãy dán một gói bằng chứng chuẩn bị sẵn khi bạn đã biết issue nào và chỉ muốn sửa. Dù chọn cách nào, giữ quyền của agent ở mức chỉ đọc.

Mình không thử server của Sentry. Thứ mình thử ngày 26/10/2026 là sự đánh đổi nằm bên dưới nó: cùng một issue được đưa cho ba model AI qua một MCP server, một lần dưới dạng event thô và một lần dưới dạng gói bằng chứng ngắn. Gói bằng chứng chỉ tốn 39 đến 61 phần trăm số token, và agent vẫn tìm ra đúng issue.

Sentry MCP đưa cho agent những gì#

MCP server của Sentry là “middleware to the upstream Sentry API” (README Sentry MCP), tức một lớp trung gian trước API của Sentry. Ở phiên bản mình đọc, danh sách tool có search_issues, search_errors, search_logs, search_traces, get_sentry_resource, update_issue và analyze_issue_with_seer. Agent tự quyết định gọi tool nào, với tham số gì.

Có hai cách cài:

• Bản hosted, tại https://mcp.sentry.dev/mcp. Tài liệu Sentry ghi “All connections use OAuth”, và một kết nối có thể được giới hạn để “tools automatically default to the constrained org/project” (tài liệu Sentry MCP). README cũng cho phép client truyền API token qua header.
• Bản chạy ở máy, qua stdio, dùng được cả với Sentry tự host. Nó cần một user auth token có các scope org:read project:read project:write team:read team:write event:write.

Có hai chi tiết đáng tính trước. Các tool tìm kiếm bằng ngôn ngữ tự nhiên cần cấu hình một nhà cung cấp LLM trên server chạy ở máy; “without a configured provider, these specific tools will be unavailable”. Còn analyze_issue_with_seer gọi Seer, agent debug bằng AI của Sentry, vốn “only available when added to an existing Team or Business plan” với giá 40 USD cho mỗi contributor đang hoạt động (tài liệu ngân sách Seer). Seer không có trong Sentry tự host.

Một gói bằng chứng dán sẵn đưa cho agent những gì#

Gói bằng chứng gồm những phần của một issue quyết định cách sửa, do một người chuẩn bị: stack đã giải qua source map, khoảng năm dòng code quanh chỗ crash, release và số lần xảy ra, cùng vài breadcrumb cuối. Nội dung người dùng gõ vào thì nên bỏ đi hoặc thay bằng độ dài của nó. Trong bài thử với Claude Code, gói này giúp ba model tìm đúng bug và sửa đúng ở cả 24/24 câu trả lời.

Với một gói bằng chứng, agent không tìm kiếm được gì thêm. Nó chỉ thấy đúng những gì bạn chọn, và đó vừa là mục đích vừa là cái giá.

Cùng một issue, hai dạng, đo thử#

MCP lab của mình đưa cho gpt-5-mini, gemini-3-flash-preview và claude-haiku-4-5 một công cụ theo dõi lỗi có sáu issue, trong đó một issue là bug khách đang gặp. Ở cách thứ nhất, lấy một issue sẽ trả về event mới nhất dưới dạng JSON, giống một event @sentry/node 11.8.0 thật, có contexts, modules và 27 breadcrumb. Ở cách thứ hai, nó trả về một gói bằng chứng khoảng 700 ký tự.

• gpt-5-mini tìm đúng issue 4/4 lần ở cả hai cách, tốn 2.198 token với gói bằng chứng so với 5.590 với event thô.
• Claude Haiku cũng tìm đúng 4/4 lần, tốn 4.181 so với 6.837 token.
• Gemini tốn nhiều nhất ở cả hai cách, 12.207 và 15.709: nó lướt sang các issue khác sau khi thử làm theo một ghi chú cài sẵn trong tiêu đề issue.

Ở đây gói bằng chứng không làm chẩn đoán tốt hơn: agent của mình không có repo, và phần khó là đọc đúng frame. Nó làm việc điều tra rẻ hơn, ngắn hơn, và không đưa thêm gì ngoài lề để agent xem lan man.

Đặt hai cách cạnh nhau#

Nên dùng cách nào#

Dùng Sentry MCP, chỉ đọc và giới hạn trong một project, khi câu hỏi còn mở:

• “Sau release sáng nay thì cái gì hỏng?”
• “Lỗi nào trong số này ảnh hưởng tới trang thanh toán?”
• “Tìm log và trace của request này.”

Dán gói bằng chứng khi yêu cầu đã cụ thể: issue này, release này, sửa đi. Cách này rẻ hơn, và agent không thấy gì ngoài thứ bạn chọn. Nhiều team sẽ làm cả hai: MCP để tìm issue, gói bằng chứng để sửa.

Dù dùng cách nào, hãy coi tiêu đề và message của issue là dữ liệu người dùng nhập. Trong lab, mình cài một câu lệnh vào message lỗi. Khi có tool ghi, agent đánh dấu đã xử lý luôn bug đang xảy ra ở 12/12 lần có ghi chú đó, và 10/12 lần không có. Danh sách tool của Sentry có update_issue, nên hãy kiểm tra token của bạn làm được gì trước khi nối.

Belvador nằm ở đâu#

Belvador không có MCP server, nên với Belvador bạn luôn ở cột gói bằng chứng. Trang issue hiện đủ các phần một gói bằng chứng cần: stack đã giải qua source map bạn upload, các dòng code, breadcrumb, tag và context, đã được lọc trong SDK và lọc lần nữa trên node của bạn. Chi tiết issue liệt kê chúng; hiện tại bạn tự chép tay. Trang Belvador so với Sentry so sánh phần còn lại, còn bài Belvador không có MCP chỉ cách nối agent vào cảnh báo của Belvador thay vì MCP.

Đọc tiếp#

• MCP cho observability: agent có quyền truy cập, chưa chắc có chẩn đoán
• Belvador không có MCP server: ba cách đưa lỗi cho agent
• Claude Code và lỗi production: đưa bằng chứng, đừng kể