·

Google Cloud MCP với Cursor

Cài đặt Google Cloud MCP trong Cursor để AI agent có thể quản lý tài nguyên cloud và điều tra hạ tầng ngay trong trình soạn thảo.

Cursor là IDE mà nhiều senior engineer chọn khi muốn agent hoạt động sát với code hơn là chỉ chạy trong terminal riêng biệt — Agent Mode của Cursor có thể đọc toàn bộ codebase, sửa file trực tiếp, và giờ với GCP MCP, nó còn có thể "nhìn" vào dữ liệu thật trên BigQuery hay config thật trên Cloud Run trong lúc bạn code. Bài này hướng dẫn setup, hai use case chính (sinh code pipeline dựa trên schema thật, và validate config Cloud Run), cùng những rủi ro chi phí đặc thù khi dùng MCP trong một IDE mà agent chạy liên tục ở background.

Kết Nối GCP MCP Với Cursor Agent Mode

Cursor đọc cấu hình MCP từ file .cursor/mcp.json (project-scoped) hoặc ~/.cursor/mcp.json (global, áp dụng mọi project mở trong Cursor). Cấu trúc khai báo tương tự Claude Code:

{
  "mcpServers": {
    "gcp-mcp": {
      "command": "npx",
      "args": ["-y", "@google-cloud/mcp-server", "--project=my-gcp-project-id"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/Users/you/.config/gcloud/agent-mcp-sa-key.json"
      }
    }
  }
}

Sau khi lưu file, mở Cursor Settings > MCP để xem danh sách server và trạng thái kết nối — Cursor hiển thị số tool đã discover kèm một toggle riêng để bật/tắt server đó mà không cần xóa config. Đây tiện khi bạn muốn tạm ngắt GCP MCP lúc đang làm task thuần frontend không liên quan tới cloud, giảm số tool agent phải "nhìn thấy" (context window bị chiếm bởi định nghĩa tool cũng là một chi phí đáng kể khi có nhiều MCP server cùng bật).

Điểm khác biệt quan trọng nhất khi dùng Cursor là cách nó xử lý quyền: Cursor Agent Mode có ba chế độ chạy tool — luôn hỏi (ask), tự động cho tool cụ thể (auto-run allowlist), và full auto (không hỏi gì, rất rủi ro). Với GCP MCP, tôi khuyên set như sau trong Cursor Settings > Agent:

  • bigquery_get_table_schema, bigquery_dry_run, run_describe_service, gcs_list_objects: cho vào allowlist auto-run vì đây là tool đọc thuần, vô hại.
  • bigquery_run_query: luôn để ở chế độ hỏi xác nhận, dù đã dry-run — vì dry-run chỉ ước tính cost, không ngăn được trường hợp query logic sai gây hiểu nhầm dữ liệu.
  • Mọi tool có khả năng write/deploy: không đưa vào GCP MCP scope cho Cursor Agent Mode nếu không thực sự cần — Cursor Agent Mode chạy khá tự động trong nhiều bước liên tiếp, dễ "trôi" xa hơn dự tính nếu không kiểm soát.

Mẹo: Bật/tắt GCP MCP theo từng task cụ thể qua toggle trong Settings > MCP thay vì để bật cố định toàn thời gian — vừa giảm nhiễu context (tool definition chiếm token), vừa giảm rủi ro agent gọi tool GCP ngoài ý định khi bạn đang làm task không liên quan.

Sinh Code Data Pipeline Dựa Trên Schema BigQuery Thực Tế

Đây là use case mạnh nhất của Cursor + GCP MCP: agent vừa thấy code hiện tại trong editor (ví dụ một pipeline Python dùng google-cloud-bigquery), vừa thấy schema thật của BigQuery — nên code sinh ra khớp chính xác tên cột, kiểu dữ liệu, không cần bạn tự copy-paste schema vào prompt.

Ví dụ: bạn đang mở file pipelines/user_activity_etl.py trong Cursor và muốn thêm một transform mới. Prompt trong Agent Mode:

Dùng GCP MCP, lấy schema của table `raw.user_events` và `warehouse.user_daily_summary`.
Viết thêm một hàm `compute_session_duration` trong file này, tính session duration
(giây) cho mỗi user mỗi ngày dựa trên timestamp min/max của event trong bảng raw,
rồi upsert vào warehouse.user_daily_summary theo đúng schema hiện có (không đổi tên
column nào), dùng MERGE statement để tránh duplicate khi pipeline chạy lại.

Vì agent lấy schema thật của cả table nguồn và đích, code sinh ra sẽ dùng đúng tên column (ví dụ event_timestamp không phải timestamp như agent có thể đoán nhầm nếu không có MCP), và câu MERGE sẽ match đúng primary key thực tế của warehouse.user_daily_summary (ví dụ user_id, summary_date).

Một pattern nâng cao hơn: yêu cầu agent viết luôn unit test dựa trên schema thật, dùng dữ liệu mẫu gần giống thật:

Viết thêm unit test cho hàm compute_session_duration vừa tạo, dùng mock data
có cấu trúc khớp với schema thật của raw.user_events (đã lấy ở trên),
test case: user có nhiều session trong ngày, user chỉ có 1 event (duration = 0),
và user không có event nào trong ngày đó (không xuất hiện trong kết quả).

Vì agent đã có schema thật trong context, mock data trong test cũng đúng kiểu dữ liệu (ví dụ timestamp đúng format TIMESTAMP, không lẫn STRING), giảm hẳn tình trạng test pass nhưng code thật fail vì kiểu dữ liệu không khớp production.

Mẹo: Khi yêu cầu agent sinh code pipeline, luôn nói rõ "không đổi tên column nào trong schema hiện có" — nếu không, một số agent có xu hướng "chuẩn hóa" tên biến theo convention riêng (ví dụ đổi user_id thành userId) gây lệch với schema thật khi code chạy.

Kiểm Tra Config Cloud Run Service Ngay Từ Cursor

Khi đang review hoặc sửa file deploy (ví dụ service.yaml hay Terraform config Cloud Run) trong Cursor, bạn có thể yêu cầu agent so sánh trực tiếp với trạng thái thật đang chạy trên GCP — rất hữu ích để phát hiện config drift (lệch cấu hình giữa file trong repo và thực tế đã deploy).

Ví dụ bạn đang mở file infra/checkout-api-service.yaml:

Dùng GCP MCP, describe service `checkout-api` thật trên Cloud Run (region
asia-southeast1). So sánh với file service.yaml đang mở: memory limit,
CPU limit, biến môi trường, min/max instances. Liệt kê rõ điểm nào file
đang khác so với config thật đang chạy.

Đây là cách phát hiện rất thực tế các trường hợp "ai đó update config qua Console tay mà quên commit lại vào Terraform/YAML" — một nguồn gốc phổ biến của config drift trong team dùng Cloud Run mà không enforce infrastructure-as-code nghiêm ngặt.

Sau khi phát hiện lệch, bạn có thể yêu cầu agent sửa trực tiếp file cho khớp với thực tế (nếu thực tế là đúng và file sai), hoặc ngược lại tạo lệnh gcloud run deploy để đồng bộ thực tế theo file (nếu file là nguồn chân lý — source of truth):

File service.yaml là nguồn chân lý. Viết lệnh gcloud run services update
để đồng bộ config thật trên Cloud Run khớp với file này, chỉ update
các field đang lệch đã liệt kê ở trên.

Với use case này, tuyệt đối không để Cursor tự động chạy lệnh gcloud run services update — luôn để nó chỉ sinh ra lệnh, bạn tự review và chạy tay, hoặc paste vào pipeline CI/CD có review riêng.

Mẹo: Định kỳ (ví dụ đầu mỗi sprint) chạy một prompt kiểm tra config drift cho toàn bộ service quan trọng — biến nó thành một routine nhỏ giúp phát hiện sớm những thay đổi "tay" không qua review, trước khi nó gây incident khó hiểu.

Các Hạn Chế Và Rủi Ro Chi Phí Cần Lưu Ý Trong Cursor

Cursor Agent Mode có đặc điểm chạy nhiều bước liên tiếp khá tự động (đặc biệt ở chế độ auto-run), điều này tạo ra một vài rủi ro riêng khi kết hợp với GCP MCP mà bạn cần ý thức rõ.

Agent có thể tự lặp lại tool call nhiều lần khi "chưa hài lòng" với kết quả: nếu bạn yêu cầu một task mơ hồ như "tìm nguyên nhân performance giảm", Agent Mode có thể tự động chạy nhiều query BigQuery liên tiếp để "thử các giả thuyết khác nhau" mà không hỏi lại bạn — mỗi query đều tốn phí BigQuery, và nếu bạn để bigquery_run_query trong auto-run allowlist, chi phí có thể tăng nhanh hơn dự tính mà bạn không nhận ra kịp thời.

Context window bị chiếm bởi nhiều MCP server cùng lúc: nếu project của bạn có sẵn nhiều MCP server khác (GitHub, Sentry, database nội bộ) cùng bật với GCP MCP, tổng số tool definition có thể chiếm một phần đáng kể context window trước cả khi agent bắt đầu suy nghĩ — dẫn tới việc agent "quên" context code quan trọng hơn khi phải cân bằng giữa quá nhiều tool. Nên tắt GCP MCP khi không cần tới trong task hiện tại (như đã nói ở phần cài đặt).

Cursor không có cơ chế budget limit tích hợp sẵn cho MCP tool: khác với việc bạn có thể set quota BigQuery ở tầng GCP (maximumBytesBilled), Cursor bản thân không giới hạn số lần agent được gọi bigquery_run_query trong một session — toàn bộ trách nhiệm kiểm soát chi phí nằm ở tầng GCP IAM/quota, không phải ở tầng IDE.

Auto-run allowlist áp dụng theo tên tool, không theo tham số: nếu bạn allowlist bigquery_run_query để tiện, agent được tự do chạy BẤT KỲ query nào mà không hỏi, kể cả query quét dữ liệu lớn — allowlist không phân biệt được "query nhỏ vô hại" và "query quét cả dataset". Đây là lý do tôi khuyên luôn để bigquery_run_query ở chế độ hỏi xác nhận, không đưa vào auto-run.

Mẹo: Kết hợp guardrail ở hai tầng: tầng GCP (set maximumBytesBilled ở mức project, budget alert riêng cho service account của agent) và tầng Cursor (không auto-run cho tool chạy query thật) — đừng chỉ dựa vào một tầng, vì Cursor không tự giới hạn được chi phí BigQuery.

Tips

  • Chỉ bật GCP MCP trong Cursor khi task hiện tại thực sự cần, tắt lại sau khi xong để giảm nhiễu context và rủi ro gọi tool ngoài ý định.
  • Không đưa bigquery_run_query hay bất kỳ tool write/deploy vào auto-run allowlist, dù các tool đọc schema/describe có thể an toàn để auto-run.
  • Set guardrail chi phí ở tầng GCP (budget alert, maximumBytesBilled) vì Cursor không có cơ chế giới hạn chi phí BigQuery tích hợp sẵn.