·

Tiếng Việt: Sentry MCP With Cursor

Sentry MCP With Cursor

Nếu bạn đã quen dùng Sentry MCP (Model Context Protocol — giao thức kết nối AI với dữ liệu/công cụ bên ngoài) với Claude Code CLI hay VS Code, phần này sẽ đưa trải nghiệm đó lên một tầm cao mới với Cursor — một IDE (Integrated Development Environment — môi trường phát triển tích hợp) được fork từ VS Code nhưng thiết kế "AI-first" ngay từ lõi. Điểm khác biệt lớn nhất của Cursor so với các editor khác là Agent Mode (còn gọi là Composer) — chế độ cho phép AI tự động đọc, sửa, và kiểm thử code trên nhiều file cùng lúc, thay vì chỉ gợi ý từng dòng như autocomplete truyền thống.

Khi kết hợp Sentry MCP với Cursor Agent Mode, bạn có một vòng lặp debug gần như liền mạch: AI đọc issue (issue — lỗi/sự cố được Sentry ghi nhận) trực tiếp từ Sentry, đối chiếu stack trace (stack trace — dấu vết ngăn xếp cuộc gọi hàm dẫn đến lỗi) với source code đang mở trong workspace, rồi tự đề xuất và áp fix ngay tại chỗ. Không cần copy-paste log giữa các tab, không cần rời IDE để tra cứu Sentry dashboard. Bài học này sẽ đi từ cấu hình kết nối, cách "kéo" issue vào ngữ cảnh chat, quy trình dùng Agent Mode để fix lỗi thực tế, và cuối cùng là những giới hạn thực tế bạn cần biết để không lạm dụng Cursor vào những việc nó không làm tốt.

Connecting Sentry MCP to Cursor Agent Mode

Cursor hỗ trợ MCP thông qua hai kênh cấu hình: Cursor Settings > MCP (giao diện đồ họa, áp dụng toàn cục cho mọi project) hoặc file .cursor/mcp.json đặt ngay trong thư mục gốc của project (chỉ áp dụng cho project đó, tiện khi bạn muốn mỗi repo có bộ MCP server riêng). Với Sentry MCP, cách nhanh và ổn định nhất là dùng remote MCP server chính thức của Sentry qua giao thức HTTP/SSE, thay vì phải cài và chạy một server local.

Tạo (hoặc mở) file .cursor/mcp.json tại root của project:

{
  "mcpServers": {
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

Đây là cấu hình dạng url-based, dùng cho remote MCP server — khác với dạng command-based (chạy một binary hoặc script local qua stdio) mà bạn có thể đã thấy khi cấu hình các MCP server tự host. Với Sentry, bạn gần như luôn nên dùng remote server chính thức vì nó được Sentry duy trì, cập nhật tool set thường xuyên, và không đòi hỏi bạn quản lý token thủ công trong file cấu hình.

Sau khi lưu file, Cursor sẽ tự phát hiện MCP server mới. Vào Cursor Settings > MCP, bạn sẽ thấy mục sentry xuất hiện với trạng thái "Needs login" hoặc tương tự — nhấn vào đó để bắt đầu flow OAuth (OAuth — giao thức ủy quyền đăng nhập chuẩn, cho phép Cursor truy cập Sentry thay mặt bạn mà không cần bạn nhập password trực tiếp vào Cursor). Một popup trình duyệt sẽ mở ra, yêu cầu bạn đăng nhập tài khoản Sentry (nếu chưa đăng nhập sẵn) và xác nhận quyền truy cập cho Cursor. Sau khi bấm "Approve"/"Authorize", trình duyệt sẽ redirect ngược lại và Cursor tự động nhận token — bạn không cần copy paste auth token (auth token — mã xác thực dùng để gọi API) thủ công vào bất kỳ đâu.

Để xác nhận kết nối đã thành công, quay lại Cursor Settings > MCP:

  • Một chấm xanh (green dot) cạnh tên sentry báo hiệu server đang online và đã xác thực.
  • Mở rộng mục sentry, bạn sẽ thấy danh sách tool mà server này expose ra, ví dụ find_issues, get_issue_details, search_events, update_issue, create_project... Danh sách chính xác tùy phiên bản Sentry MCP hiện hành.
  • Nếu chấm hiển thị màu đỏ/xám, hoặc danh sách tool trống, thường là do phiên OAuth hết hạn hoặc network bị chặn — thử "Reload" hoặc xóa và thêm lại config.

Một điểm quan trọng về an toàn: Cursor cho phép bạn cấu hình per-tool approval — tức là chọn từng tool sẽ được auto-run (chạy tự động không hỏi) hay ask every time (luôn hỏi xác nhận trước khi chạy). Với các tool chỉ đọc dữ liệu như find_issues, get_issue_details, search_events, bạn có thể bật auto-run để tăng tốc độ làm việc vì chúng không có rủi ro thay đổi dữ liệu. Nhưng với các tool có khả năng ghi/thay đổi trạng thái như update_issue (đổi trạng thái resolved/ignored), create_project, hay bất kỳ tool nào có thể xóa hoặc sửa dữ liệu trên Sentry, bạn nên giữ ở chế độ "ask every time". Điều này ngăn trường hợp Agent Mode tự ý resolve nhầm một issue quan trọng chỉ vì nó "nghĩ" đã fix xong.

Loại tool Rủi ro Khuyến nghị
Đọc dữ liệu (find_issues, get_issue_details, search_events) Thấp Auto-run
Ghi/thay đổi trạng thái (update_issue, create_project, assign_issue) Trung bình - cao Ask every time
Xóa dữ liệu Cao Ask every time, cân nhắc tắt hẳn nếu không dùng

Mẹo: Nếu làm việc trong team, đừng để mặc định "auto-run all tools" ngay từ đầu. Hãy bật dần từng tool đọc-dữ-liệu sau khi đã quan sát Agent Mode dùng chúng đúng cách vài lần — an toàn hơn nhiều so với việc tắt approval hàng loạt rồi phải rollback khi có sự cố.

Pulling Sentry Issues into Cursor for In-Context Code Debugging

Sức mạnh thực sự của Sentry MCP trong Cursor không nằm ở việc "xem" issue — Sentry UI đã làm việc đó tốt rồi — mà nằm ở khả năng đối chiếu issue với codebase đang mở. Vì Cursor đã có sẵn context về toàn bộ project (nhờ codebase indexing và semantic search nội bộ), khi bạn tham chiếu một Sentry issue trong chat/Composer, AI có thể lập tức nối stack trace với file/dòng code thật, thay vì chỉ đọc trace như một đoạn text vô nghĩa.

Quy trình thực tế: mở project chứa source code liên quan đến issue, mở Composer (Agent Mode), và tham chiếu issue bằng ID hoặc URL. Ví dụ prompt mở đầu:

Lấy chi tiết issue PROJ-482 từ Sentry, đối chiếu stack trace với codebase hiện tại,
và cho tôi biết dòng code nào khả năng cao nhất gây ra lỗi này.

Agent sẽ gọi tool get_issue_details (hoặc tương đương) qua MCP để lấy stack trace, title, số lần xảy ra (event count), breadcrumb (breadcrumb — chuỗi hành động/log dẫn đến lỗi, giúp tái hiện đường đi của user trước khi crash), và các tag liên quan như release (release — phiên bản phát hành cụ thể của ứng dụng) hay environment. Sau đó, thay vì chỉ in ra trace thô, Cursor sẽ dùng semantic search trên toàn codebase để nhảy thẳng đến đúng file và dòng được nhắc tới trong frame của trace — kể cả khi tên hàm trong trace hơi khác với tên trong code (do wrapper, decorator, hay minify).

Một vài ví dụ prompt hữu ích khác trong giai đoạn khảo sát (triage — bước phân loại và đánh giá mức độ ưu tiên xử lý issue):

So sánh issue PROJ-482 và PROJ-490 — chúng có cùng root cause không?

Issue PROJ-501 chỉ xảy ra trên release 2.14.0. Xem git log/diff quanh
thời điểm release đó để tìm commit khả nghi.

Mở file được nhắc trong frame đầu tiên của stack trace issue PROJ-482,
và cho tôi xem 30 dòng code xung quanh dòng lỗi.

Vì Cursor giữ toàn bộ file đang mở và các file liên quan trong context window (context window — giới hạn lượng văn bản mô hình có thể "nhìn thấy" cùng lúc), AI có thể vừa đọc trace từ Sentry, vừa đọc logic thực tế trong hàm bị lỗi, vừa search các nơi khác trong codebase gọi đến hàm đó — tất cả trong cùng một phiên hội thoại. Đây chính là lợi thế "in-context debugging" mà không công cụ Sentry độc lập nào làm được, vì nó không có quyền truy cập vào source code của bạn.

Mẹo: Khi paste issue ID, luôn mở kèm file mà bạn nghi ngờ có liên quan (dùng @filename trong Cursor để ghim file vào context). Điều này giúp AI ưu tiên đối chiếu đúng khu vực thay vì phải semantic-search toàn bộ repo, vừa nhanh hơn vừa chính xác hơn với các repo lớn.

Using Cursor Agent Mode to Propose and Apply Code Fixes

Đây là phần "đắt giá" nhất: biến một issue đã được investigate thành một fix thực sự, kèm regression test (regression test — bài test đảm bảo lỗi đã fix không tái diễn), và review được diff trước khi merge.

Quy trình khuyến nghị chia làm ba bước tuần tự trong cùng một phiên Composer, mỗi bước là một prompt riêng để bạn kiểm soát được tiến độ và can thiệp kịp lúc nếu AI đi sai hướng:

Bước 1 — Investigate:

Investigate issue PROJ-482 trên Sentry. Lấy đầy đủ stack trace, breadcrumb,
và các event gần nhất. Đối chiếu với code trong src/payments/checkout.ts.

Bước 2 — Explain root cause:

Dựa trên thông tin vừa thu thập, giải thích root cause analysis (root cause
analysis — phân tích tìm nguyên nhân gốc) của lỗi này. Vì sao nó chỉ xảy ra
với một số user nhất định?

Ở bước này, Agent Mode thường trả lời dạng văn bản giải thích trước, KHÔNG sửa code ngay — đây là điểm bạn nên tận dụng để xác nhận logic trước khi cho phép AI động vào code thật.

Bước 3 — Apply fix và viết test:

Áp dụng một fix cho lỗi trên. Thêm một regression test tái hiện đúng
tình huống lỗi (null discount code khi user là guest) để đảm bảo
không tái diễn.

Agent Mode lúc này sẽ đề xuất chỉnh sửa trên (có thể) nhiều file cùng lúc — ví dụ vừa sửa logic trong checkout.ts, vừa thêm test case trong checkout.test.ts. Cursor hiển thị các thay đổi này dưới dạng inline diff ngay trong editor (dòng thêm tô xanh, dòng xóa tô đỏ, gạch ngang), cho phép bạn review từng hunk, accept hoặc reject riêng lẻ trước khi commit — chứ không phải "chấp nhận tất cả hoặc không gì cả".

Ví dụ diff output thực tế bạn có thể thấy:

--- a/src/payments/checkout.ts
+++ b/src/payments/checkout.ts
@@ -42,7 +42,10 @@ export function applyDiscount(user: User, code: string | null) {
-  const discount = discountMap[code.toUpperCase()];
+  if (!code) {
+    return { amount: 0, applied: false };
+  }
+  const discount = discountMap[code.toUpperCase()];
   return { amount: discount ?? 0, applied: Boolean(discount) };
 }

--- a/src/payments/checkout.test.ts
+++ b/src/payments/checkout.test.ts
@@ -18,3 +18,9 @@ describe('applyDiscount', () => {
+  it('handles guest users with no discount code without throwing', () => {
+    const result = applyDiscount(guestUser, null);
+    expect(result.applied).toBe(false);
+    expect(result.amount).toBe(0);
+  });
 });

Sau khi accept diff, hãy để Agent Mode chạy test suite ngay trong terminal tích hợp của Cursor (npm test hoặc lệnh tương ứng) để xác nhận test mới pass và không có test cũ nào bị vỡ. Nếu fix chưa giải quyết được lỗi gốc (ví dụ test vẫn fail, hoặc bạn nhận ra edge case khác), tiếp tục vòng lặp bằng một prompt bổ sung thay vì bắt đầu lại từ đầu — Agent Mode vẫn giữ context của cả phiên.

Một nguyên tắc làm việc quan trọng: mỗi issue nên có một phiên Agent Mode riêng, một issue một Composer session. Đừng dồn hai-ba issue không liên quan vào cùng một cuộc trò chuyện — điều này khiến context bị pha loãng, AI dễ nhầm lẫn trace của issue này với logic đang sửa cho issue khác, và diff cuối cùng khó review vì lẫn lộn nhiều mục đích. Khi chuyển sang issue tiếp theo, hãy mở Composer session mới.

Một yếu tố kỹ thuật thường bị bỏ qua nhưng ảnh hưởng trực tiếp đến chất lượng fix: source map (source map — bản đồ mã nguồn, ánh xạ code đã build/minify về lại code gốc). Với các dự án frontend build qua webpack/vite, code chạy trên production thường đã bị minify — biến số đổi tên thành a, b, c, dòng code dồn lại thành một dòng dài. Nếu Sentry không nhận được source map tương ứng, stack trace trả về sẽ trỏ đến những vị trí vô nghĩa trong file đã minify, và Cursor — dù thông minh đến đâu — cũng không thể đối chiếu chính xác với source gốc. Hãy đảm bảo project của bạn đã cấu hình plugin upload source map lên Sentry mỗi lần build, ví dụ với Vite:

// vite.config.ts
import { sentryVitePlugin } from '@sentry/vite-plugin';

export default {
  plugins: [
    sentryVitePlugin({
      org: 'your-org',
      project: 'your-project',
      authToken: process.env.SENTRY_AUTH_TOKEN,
    }),
  ],
  build: {
    sourcemap: true,
  },
};

Chất lượng fix mà Agent Mode đề xuất phụ thuộc trực tiếp vào chất lượng của trace mà nó đọc được — trace càng rõ ràng, dễ đọc, càng ít khả năng AI "đoán mò" sai vị trí lỗi.

Mẹo: Trước khi bắt đầu bước "Apply fix", luôn yêu cầu Agent Mode tóm tắt lại phạm vi thay đổi dự kiến bằng một câu hỏi phụ như "Bạn định sửa những file nào?" — điều này giúp bạn phát hiện sớm nếu AI có ý định sửa lan sang những khu vực không liên quan trước khi diff thực sự được tạo ra.

Limitations and When Cursor Is Not the Best Tool for Sentry Debugging

Cursor là công cụ mạnh cho việc sửa code trong phạm vi một vài file, một issue cụ thể, ngay tại chỗ code đang mở. Nhưng nó không phải công cụ tối ưu cho mọi bước trong vòng đời xử lý lỗi, và hiểu rõ ranh giới này sẽ giúp bạn tránh lãng phí thời gian hoặc rủi ro thao tác nhầm.

Không phù hợp cho triage/dashboard-style workflow trên diện rộng. Cursor được thiết kế xoay quanh một workspace code cụ thể — nó không có giao diện tổng quan để bạn lướt qua hàng chục, hàng trăm issue đang mở trên nhiều project cùng lúc, sắp xếp theo mức độ ưu tiên, hay theo dõi xu hướng error rate theo thời gian. Với việc triage tổng thể — quyết định issue nào cần xử lý trước, issue nào có thể ignore — Sentry UI (dashboard gốc) vẫn là lựa chọn trực quan nhất, hoặc nếu muốn làm việc này qua AI/terminal ở quy mô lớn hơn một project đơn lẻ, Claude Code CLI thường linh hoạt hơn vì không bị ràng buộc vào một workspace code cụ thể.

Rủi ro tốn context window khi paste stack trace dài trong codebase lớn. Nếu bạn paste nguyên một stack trace dài hàng trăm dòng (phổ biến với lỗi lồng nhiều lớp exception hoặc framework có call stack sâu) vào một session đã có sẵn nhiều file lớn được ghim trong context, bạn có thể nhanh chóng chạm giới hạn context window của model đang dùng. Hậu quả là Agent Mode có thể "quên" một phần thông tin đầu phiên, hoặc phản hồi chậm/kém chính xác hơn. Cách xử lý: chỉ để Agent gọi tool get_issue_details để tự lấy trace gọn gàng qua MCP thay vì copy-paste thủ công toàn bộ text, và tránh ghim quá nhiều file không liên quan vào cùng context.

Cần thao tác thủ công qua CLI/UI nếu tool ghi dữ liệu không được expose hoặc bị tắt approval. Như đã đề cập ở phần cấu hình, nhiều team chủ động tắt auto-run cho các tool như update_issue vì lý do an toàn. Điều đó nghĩa là sau khi fix xong và merge code, bạn vẫn cần tự tay vào Sentry UI hoặc dùng CLI/API để resolve, assign, hoặc gắn release cho issue — Agent Mode sẽ không tự làm thay nếu bạn không cấp quyền. Đây là ví dụ resolve và assign issue thủ công qua Sentry API bằng curl, dùng như phương án dự phòng khi không muốn expose các tool ghi dữ liệu qua MCP:

curl -X PUT "https://sentry.io/api/0/issues/482/" \
  -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "resolved"}'

curl -X PUT "https://sentry.io/api/0/issues/482/" \
  -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"assignedTo": "user:teammate@company.com"}'

Bảng dưới đây tóm tắt khi nào nên chọn Cursor, khi nào nên dùng công cụ khác:

Tình huống Công cụ nên dùng
Fix một lỗi cụ thể, cần sửa code + viết test Cursor Agent Mode
Triage hàng loạt issue trên nhiều project Sentry UI / Claude Code CLI
Phân tích xu hướng, alert, dashboard Sentry UI
Tự động hóa quy trình resolve/assign hàng loạt CLI/API script, hoặc Claude Code CLI
Debug lỗi cần đối chiếu sâu với logic trong code Cursor Agent Mode

Mẹo: Coi Cursor như "công cụ ở tầng code" và Sentry UI/Claude Code CLI như "công cụ ở tầng vận hành/triage" — dùng đúng công cụ cho đúng tầng sẽ hiệu quả hơn nhiều so với việc cố gắng làm mọi thứ chỉ trong một IDE.

Tiếp Tiếng Việt: Real World Workflow Error Investigation And Fix Deployment