·

HubSpot MCP với Gemini CLI

Cài đặt HubSpot MCP trong Gemini CLI để AI agent có thể quản lý contact, deal và ticket ngay trong trình soạn thảo.

Gemini CLI của Google hỗ trợ MCP như một first-class citizen, với context window (cửa sổ ngữ cảnh) lớn là lợi thế rõ rệt khi làm việc với dữ liệu CRM — nơi bạn thường cần agent đọc hàng chục, hàng trăm ticket/note cùng lúc để tìm pattern mà con người đọc bằng tay sẽ mất cả ngày. Bài này hướng dẫn cấu hình cụ thể, cách tổng hợp dữ liệu deal/ticket quy mô lớn để phân tích xu hướng, một ví dụ xếp hạng feature request theo revenue impact, và so sánh hành vi thực tế giữa Gemini CLI và Claude Code khi cùng làm việc với HubSpot MCP.

Cài Đặt và Kết Nối HubSpot MCP Với Gemini CLI

Gemini CLI đọc cấu hình MCP từ settings.json, tại ~/.gemini/settings.json (global) hoặc .gemini/settings.json (project, ưu tiên cao hơn):

{
  "mcpServers": {
    "hubspot": {
      "command": "npx",
      "args": ["-y", "@hubspot/mcp-server"],
      "env": {
        "PRIVATE_APP_ACCESS_TOKEN": "$HUBSPOT_TOKEN"
      },
      "timeout": 45000
    }
  }
}

Set biến môi trường trước khi mở CLI:

export HUBSPOT_TOKEN="pat-na1-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
gemini

Xác nhận server đã load:

/mcp list

Tham số timeout đáng chú ý riêng với HubSpot MCP: các truy vấn tổng hợp nhiều object (ví dụ lấy tất cả ticket rồi lấy company liên kết cho từng ticket) có thể mất nhiều thời gian hơn một request đơn — nếu bạn hay gặp lỗi timeout khi phân tích trên khối lượng dữ liệu lớn, tăng giá trị này (đơn vị milliseconds) lên.

Nếu Gemini CLI báo "0 tools" dù server ở trạng thái connected, thường do version package không tương thích cách CLI parse tool schema — thử pin version cụ thể:

npx -y @hubspot/mcp-server@1.4.0

Mẹo: Chạy với flag --debug khi gặp lỗi kết nối mơ hồ — log JSON-RPC thô giữa CLI và server thường lộ ra nguyên nhân thật (thiếu scope, sai định dạng token) mà UI chuẩn không hiển thị đủ chi tiết.

Tổng Hợp Dữ Liệu Deal và Ticket Để Phân Tích Xu Hướng Trong Gemini CLI

Context window lớn của Gemini CLI phát huy rõ nhất khi bạn cần agent "đọc hết" một khối lượng lớn ticket/deal để tìm pattern, thay vì xử lý từng cái riêng lẻ.

Lấy toàn bộ deal đã "Closed Lost" trong 90 ngày qua. Đọc note và lý do
đóng deal (closed lost reason) của từng deal, nhóm theo nguyên nhân chính
(giá, thiếu tính năng, chọn đối thủ, timing). Với mỗi nhóm, cho biết số
lượng deal và tổng amount đã mất (giá trị deal nếu đã thắng).

Đây là loại phân tích rất khó làm bằng tay khi số lượng deal lớn — đọc và phân loại 50-100 deal note theo nguyên nhân đóng deal thường mất cả ngày nếu làm thủ công, nhưng agent với context window lớn xử lý trong một lần gọi.

Một pattern nâng cao hơn — kết hợp deal lost với ticket support để tìm tương quan:

Trong các deal "Closed Lost" vì lý do "thiếu tính năng" ở trên, kiểm tra
xem company đó có ticket support nào từng yêu cầu đúng tính năng bị thiếu
không (tìm trong nội dung ticket các từ khóa liên quan). Nếu có, đây là
tín hiệu mạnh cho thấy tính năng đó đáng được ưu tiên.

Mẹo: Với truy vấn phân loại theo "nguyên nhân chính" mang tính chủ quan (như lý do đóng deal), luôn yêu cầu agent trích dẫn câu gốc trong note đã dùng để phân loại. Nếu không có câu gốc kèm theo, rất khó kiểm tra agent phân loại đúng hay chỉ đoán theo từ khóa hời hợt.

Ví Dụ Thực Tế: Xếp Hạng Feature Request Theo Mức Độ Ảnh Hưởng Doanh Thu

Đây là bài toán kinh điển của product engineer: có hàng chục feature request rải rác trong ticket và note sales, cần xếp hạng ưu tiên theo dữ liệu thay vì cảm tính "ai la to hơn thì làm trước".

Bước 1 — Thu thập toàn bộ feature request từ nhiều nguồn:

Quét toàn bộ ticket 60 ngày qua và note trên deal đang active, tìm các
đoạn có nhắc yêu cầu tính năng cụ thể (không phải bug report). Với mỗi
yêu cầu, ghi lại: tên tính năng (tự đặt tên ngắn gọn nếu chưa có),
nguồn (ticket ID hoặc deal name), company liên quan.

Bước 2 — Gộp các yêu cầu trùng ý và tính impact:

Gộp các yêu cầu ở trên nếu chúng mô tả cùng một tính năng (dù dùng từ
khác nhau). Với mỗi tính năng đã gộp, tính: số company đã yêu cầu, tổng
deal amount của các company đó (active + closed won), và có company nào
đang "at risk" (không hoạt động 14 ngày) yêu cầu tính năng này không.

Bước 3 — Xếp hạng và trình bày:

Xếp hạng các tính năng theo tổng deal amount liên quan, giảm dần.
Trình bày bảng: Tính năng, Số company yêu cầu, Tổng amount, Company at-risk (có/không).
Không tự đề xuất tính năng nào nên làm trước — chỉ trình bày số liệu để
tôi và PM cùng quyết định.

Kết quả là một bảng ưu tiên có căn cứ doanh thu thực tế — khác hẳn với việc chọn feature theo "ticket nào ồn ào nhất gần đây" vốn dễ bị lệch bởi một khách hàng viết nhiều ticket nhưng giá trị hợp đồng nhỏ.

Mẹo: Luôn tách riêng cột "company at-risk" trong bảng xếp hạng. Một tính năng có tổng amount thấp nhưng được yêu cầu bởi company đang có nguy cơ rời bỏ (churn risk) có thể quan trọng hơn một tính năng tổng amount cao nhưng company vẫn đang hoạt động ổn định — con số tổng amount đơn thuần dễ khiến bạn bỏ sót tín hiệu này.

So Sánh Kết Quả HubSpot MCP Giữa Gemini CLI và Claude Code

Vài khác biệt thực tế đáng lưu ý nếu team bạn dùng song song cả hai công cụ cho việc phân tích CRM:

Khía cạnh Gemini CLI Claude Code
Cấu hình settings.json, biến $VAR .mcp.json, biến ${VAR}
Xử lý khối lượng ticket/deal lớn Tốt nhờ context window lớn, ít cần chia batch Vẫn tốt nhưng nên chia batch sớm hơn với dữ liệu rất lớn (hàng trăm ticket)
Trích dẫn nguồn gốc dữ liệu Cần nhắc rõ trong prompt để agent giữ lại ticket ID/quote Tương tự, cả hai đều cần được nhắc rõ, không tự làm nếu không yêu cầu
Xác nhận trước khi ghi Tuỳ approval mode (--yolo bỏ qua xác nhận, nên tránh với HubSpot) Có permission mode rõ ràng theo từng loại tool
Debug tool call Cần --debug để xem JSON-RPC thô Log hiển thị sẵn trong transcript, dễ xem hơn

Điểm chung quan trọng nhất: cả hai đều không tự động ẩn PII hoặc giới hạn phạm vi nếu bạn không yêu cầu rõ trong prompt — trách nhiệm kiểm soát dữ liệu khách hàng nằm ở người viết prompt, không phải ở công cụ.

Mẹo: Nếu team dùng song song nhiều CLI agent cho phân tích HubSpot, viết chung một file hướng dẫn ngắn (ví dụ HUBSPOT_QUERY_GUIDE.md) mô tả quy tắc giới hạn phạm vi, quy tắc PII, và các prompt mẫu chuẩn — include file này vào context của cả Gemini CLI và Claude Code để kết quả phân tích nhất quán bất kể ai chạy công cụ nào.

Mẹo Thực Chiến Khi Dùng HubSpot MCP Với Gemini CLI

  • Tận dụng context window lớn cho các batch phân tích rộng (quét cả quý dữ liệu ticket/deal) thay vì chia nhỏ như bạn thường làm với model context ngắn hơn — đây là lợi thế riêng của Gemini CLI cho use case CRM.
  • Luôn set timeout đủ cao cho các truy vấn nhiều tầng (deal → company → ticket) để tránh lỗi timeout giả gây hiểu nhầm là server lỗi.
  • Tránh dùng flag bỏ qua xác nhận (--yolo hoặc tương đương) khi làm việc với HubSpot MCP — dữ liệu khách hàng thật không nên để agent tự do ghi mà không có điểm dừng.
  • Định kỳ pin version cụ thể của package MCP server thay vì luôn dùng @latest, để tránh thay đổi bất ngờ về tool schema làm gãy các prompt đã hoạt động ổn định.

Mẹo: Khi giao một batch phân tích lớn (toàn bộ ticket/deal trong quý), luôn yêu cầu Gemini CLI báo cáo số lượng record đã xử lý thực tế so với tổng số bạn kỳ vọng — nếu có sự chênh lệch do phân trang (pagination) chưa lấy hết, bạn sẽ phát hiện sớm thay vì tin vào một báo cáo tổng hợp bị thiếu dữ liệu.

Tiếp HubSpot MCP với Cursor