Sequential Thinking MCP Setup: Cursor

Cursor là một IDE (fork từ VS Code) tích hợp sẵn AI agent mode, cho phép agent tự đọc codebase, sửa nhiều file, và chạy command — tất cả trong cùng một cửa sổ editor. Vì Cursor Agent Mode có xu hướng hành động rất nhanh (đôi khi quá nhanh so với mức độ hiểu bài toán), Sequential Thinking MCP là một công cụ cân bằng tốt: giữ agent trong IDE nhưng buộc nó lập luận rõ ràng trước khi động vào code. Bài này hướng dẫn kết nối server vào Cursor, cách dùng nó cho các thay đổi cross-cutting (xuyên nhiều module), kết hợp với codebase search, và các anti-pattern (cách dùng sai) cần tránh.

Kết Nối Sequential Thinking MCP Vào Cursor Agent Mode

Cursor đọc cấu hình MCP từ file .cursor/mcp.json ở root project (scope project, khuyến nghị commit vào git để share cho team) hoặc ~/.cursor/mcp.json (scope global, áp dụng cho mọi project mở bằng Cursor trên máy đó). Format giống chuẩn Claude Desktop:

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

Sau khi lưu file, vào Cursor Settings → MCP để xác nhận server hiện trạng thái xanh (connected) và có đúng 1 tool sequentialthinking được list ra. Nếu server không lên, nguyên nhân phổ biến nhất là Cursor spawn subprocess với PATH khác terminal của bạn — thử đổi command thành đường dẫn tuyệt đối tới node/npx nếu cần:

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "/usr/local/bin/npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

Trong Agent Mode (không phải Ask mode hay Edit mode thông thường — cần chọn đúng mode có quyền gọi tool), Cursor sẽ tự quyết định gọi tool sequentialthinking khi model đánh giá task đủ phức tạp, hoặc bạn có thể ép gọi bằng cách nhắc trực tiếp trong prompt như các CLI khác đã đề cập ở các bài trước trong module này.

Mẹo: Bật .cursor/mcp.json ở scope project và commit vào repo — điều này đảm bảo mọi engineer trong team, khi clone project và mở bằng Cursor, đều có sẵn Sequential Thinking mà không cần setup tay từng máy, tránh tình trạng "trên máy tôi nó suy luận kỹ, trên máy bạn nó không".

Chia Một Thay Đổi Cross-Cutting Thành Các Edit Có Thứ Tự, Dễ Review

Thay đổi cross-cutting (xuyên nhiều module, ví dụ đổi cách xử lý authentication token từ session cookie sang JWT trên toàn bộ 25 endpoint) là loại task Cursor Agent Mode dễ làm sai nhất nếu để nó tự do sửa hàng loạt file cùng lúc — bạn sẽ nhận về một diff khổng lồ khó review, và nếu có 1 endpoint bị sót logic refresh token, rất khó phát hiện giữa hàng trăm dòng thay đổi.

Prompt kích hoạt structured reasoning trước khi sửa:

Cần đổi cơ chế auth từ session cookie sang JWT cho toàn bộ 25 endpoint trong
src/api/. Dùng sequential thinking để lập plan: liệt kê từng endpoint cần sửa,
nhóm theo mức độ rủi ro (endpoint public vs endpoint có quyền admin), và đề xuất
thứ tự sửa + test lại theo từng nhóm nhỏ, KHÔNG sửa tất cả trong 1 lần.
Sau khi có plan, chỉ thực hiện nhóm rủi ro thấp nhất trước, rồi dừng lại chờ tôi confirm.

Chuỗi thought thực tế cho task này thường phân nhóm theo rủi ro rõ ràng:

{"thought": "Nhóm 1 (rủi ro thấp): 8 endpoint public read-only, không có write action — an toàn để đổi trước và dễ rollback nếu sai.", "thoughtNumber": 2, "totalThoughts": 5, "nextThoughtNeeded": true}

{"thought": "Nhóm 2 (rủi ro trung bình): 12 endpoint có write action nhưng chỉ user thường — cần test kỹ luồng refresh token khi JWT gần hết hạn giữa request.", "thoughtNumber": 3, "totalThoughts": 5, "nextThoughtNeeded": true}

{"thought": "Nhóm 3 (rủi ro cao): 5 endpoint admin — chỉ sửa sau khi nhóm 1 và 2 đã chạy ổn định trên staging ít nhất 1 ngày, vì lỗi ở đây ảnh hưởng trực tiếp quyền quản trị hệ thống.", "thoughtNumber": 4, "totalThoughts": 5, "nextThoughtNeeded": true}

Kết quả: bạn nhận về một PR nhỏ (8 endpoint) dễ review đầu tiên, thay vì một diff 25 endpoint khó kiểm tra hết trong một lần — đây chính là giá trị thực dụng lớn nhất của việc ép Cursor lập plan trước khi hành động cho loại task này.

Mẹo: Với thay đổi cross-cutting ảnh hưởng auth/security, luôn thêm câu "chỉ thực hiện nhóm rủi ro thấp nhất trước, dừng lại chờ confirm" vào prompt — Cursor Agent Mode mặc định có xu hướng làm hết trong 1 lượt nếu không bị chặn lại rõ ràng.

Kết Hợp Sequential Thinking Với Codebase Search Để Có Plan Tốt Hơn

Cursor có tool codebase search (semantic search dựa trên embedding của toàn bộ code trong project) chạy song song với Sequential Thinking rất hiệu quả: agent dùng codebase search để thu thập bằng chứng thực tế, rồi dùng thought để suy luận dựa trên bằng chứng đó — thay vì suy luận dựa trên giả định (điều dễ dẫn tới sai sót ở các CLI không có search tốt).

Prompt khuyến khích kết hợp cả hai:

Dùng codebase search để tìm toàn bộ nơi đang dùng req.session.userId trong
codebase, sau đó dùng sequential thinking để lập plan thay thế bằng
req.user.id (lấy từ middleware verify JWT mới). Với mỗi nơi tìm được,
xác nhận middleware mới đã set đúng field trước khi liệt kê vào plan.

Pattern lý tưởng ở đây là: mỗi thought quan trọng nên trích dẫn trực tiếp kết quả search làm bằng chứng, ví dụ:

{"thought": "Codebase search tìm thấy 14 chỗ dùng req.session.userId, tập trung ở 3 file: order_controller.js (6 chỗ), user_controller.js (5 chỗ), admin_controller.js (3 chỗ). Middleware verifyJwt.js hiện tại set req.user = decoded nhưng field là 'id' không phải 'userId' — cần đổi tên field tham chiếu ở toàn bộ 14 chỗ, không chỉ đổi nguồn lấy session.", "thoughtNumber": 2, "totalThoughts": 4, "nextThoughtNeeded": true}

Việc thought trích dẫn số liệu cụ thể từ search (14 chỗ, 3 file, tên field chính xác) thay vì nói chung "cần cập nhật các nơi dùng session" giúp plan cuối cùng chính xác và có thể verify được — bạn có thể tự đếm lại 14 chỗ đó để chắc chắn agent không bỏ sót.

Mẹo: Nếu agent đưa ra thought mà không trích dẫn cụ thể kết quả search (chỉ nói mơ hồ "hầu hết các file"), yêu cầu ngay "hãy chạy lại codebase search và liệt kê chính xác file + số dòng" trước khi cho phép nó tiếp tục — thought mơ hồ ở bước đầu thường dẫn tới plan sai sót ở bước cuối.

Hạn Chế và Anti-Pattern Lạm Dụng Trong Cursor

Một số cách dùng sai thường gặp và hạn chế thực tế cần biết:

Anti-pattern: bật Sequential Thinking cho mọi edit nhỏ: nếu bạn thấy Cursor gọi tool này cho việc sửa một dòng CSS hay đổi tên biến đơn giản, đó là dấu hiệu system prompt/custom instructions của bạn đang khuyến khích "luôn suy nghĩ kỹ" quá mức — nên giới hạn lại chỉ áp dụng cho task có rủi ro thật.
Anti-pattern: dùng thought thay cho comment code: một số agent có xu hướng nhồi giải thích logic nghiệp vụ vào thought rồi quên viết comment tương ứng trong code — thought sẽ biến mất sau session, không giúp ích cho người đọc code sau này. Luôn yêu cầu agent viết lại các quyết định quan trọng thành comment hoặc doc, không chỉ để trong thought.
Hạn chế: không có cơ chế undo riêng cho một thought: nếu bạn muốn quay lại một thought cụ thể để sửa hướng, cách duy nhất là dùng isRevision trỏ tới revisesThought đó — Cursor không có UI để bạn tay chỉnh trực tiếp một thought giữa chuỗi.
Hạn chế: chuỗi thought dài làm chậm phản hồi trong IDE: khác với chạy CLI nền, trong Cursor bạn đang chờ trực tiếp trong editor — một chuỗi 8-10 thought cho một quyết định kiến trúc có thể khiến bạn chờ 30-60 giây không có phản hồi trung gian nào ngoài các thought lướt qua, gây cảm giác "đứng hình" nếu không biết trước.

Mẹo: Thêm vào Cursor Rules (.cursor/rules/) một rule ngắn: "chỉ dùng sequential thinking cho refactor xuyên nhiều file hoặc quyết định kiến trúc, không dùng cho sửa đổi một file/một hàm đơn lẻ" — việc này giảm hẳn tình trạng agent lạm dụng tool cho các task không cần thiết.