·

Slack MCP với Gemini CLI

Cài đặt Slack MCP trong Gemini CLI để AI agent có thể đọc và gửi tin nhắn, quản lý channel ngay trong trình soạn thảo.

Gemini CLI của Google cũng hỗ trợ MCP như một first-class citizen, nhưng cách khai báo config và hành vi tool-calling có vài khác biệt so với Claude Code hay OpenCode — đủ để gây bối rối nếu bạn quen một client rồi chuyển sang client khác mà không đọc kỹ. Bài này đi vào cấu hình cụ thể, và một use case Gemini CLI làm khá tốt nhờ context window (cửa sổ ngữ cảnh) lớn: biến một incident channel hỗn loạn thành timeline rõ ràng.

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

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

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "$SLACK_BOT_TOKEN",
        "SLACK_TEAM_ID": "$SLACK_TEAM_ID"
      },
      "timeout": 30000
    }
  }
}

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

export SLACK_BOT_TOKEN="xoxb-xxxxxxxxxxxx-xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx"
export SLACK_TEAM_ID="T0XXXXXXX"
gemini

Trong session, xác nhận server đã load bằng lệnh:

/mcp list

Kết quả hiển thị tên server, số tool được expose, và trạng thái kết nối. Nếu Gemini CLI báo "0 tools" dù server ở trạng thái connected, thường do version package Slack MCP không tương thích với cách Gemini CLI parse tool schema (JSON Schema draft khác nhau) — thử pin version cụ thể thay vì dùng @latest:

npx -y @modelcontextprotocol/server-slack@0.6.2

Tham số timeout trong config đáng chú ý riêng với Gemini CLI: mặc định timeout cho mỗi tool call khá ngắn, và với action như search_messages trên workspace lớn (hàng trăm nghìn message), request có thể mất hơn thời gian mặc định — nên set timeout (đơn vị milliseconds) cao hơn nếu bạn gặp lỗi timeout thường xuyên.

Mẹo: Nếu Gemini CLI báo lỗi kết nối MCP mơ hồ, chạy với flag --debug để in ra log JSON-RPC thô giữa CLI và server — thường lỗi thực sự (sai token, sai scope) nằm trong response chi tiết mà UI thông thường không hiển thị đầy đủ.

Tìm Kiếm Lịch Sử Channel và Trích Xuất Yêu Cầu Từ Gemini CLI

Gemini CLI mạnh ở khả năng xử lý input dài, nên use case tìm kiếm và trích xuất thông tin từ lịch sử channel dài là nơi nó phát huy tốt. Ví dụ:

Tìm trong #customer-feedback tất cả message có chứa từ khóa
"chậm" hoặc "lag" hoặc "timeout" trong 30 ngày qua.
Trích xuất thành bảng: ngày, người gửi, nội dung tóm tắt,
mức độ nghiêm trọng ước lượng (thấp/trung/cao).

Gemini CLI gọi search_messages với query kết hợp (in:#customer-feedback "chậm" OR "lag" OR "timeout"), rồi dùng khả năng suy luận của model để gán mức độ nghiêm trọng — đây là bước "trích xuất yêu cầu" (requirement extraction) rất hữu ích khi bạn cần biến feedback rời rạc thành backlog có cấu trúc.

Một pattern nâng cao hơn: yêu cầu agent tự tạo ticket draft từ kết quả tìm kiếm.

Từ các message tìm được ở trên, với mỗi vấn đề mức độ "cao",
soạn một draft ticket theo format:
Title: <ngắn gọn>
Description: <mô tả, kèm quote nguyên văn message>
Reporter: <tên người dùng gốc, không phải người báo lại>
Chỉ in ra draft, không tự tạo ticket trên Jira.

Việc yêu cầu "chỉ in ra draft, không tự tạo" là bước kiểm soát quan trọng — tách rõ giai đoạn agent đề xuất và giai đoạn con người quyết định thực thi, tránh tạo ticket rác nếu agent hiểu nhầm mức độ nghiêm trọng.

Mẹo: Với truy vấn search phức tạp, luôn yêu cầu agent in ra query Slack thực tế nó dùng (in:#channel keyword after:2026-07-01) trước khi chạy — giúp bạn phát hiện ngay nếu agent hiểu sai phạm vi tìm kiếm bạn muốn.

Ví Dụ Thực Tế: Biến Channel Incident Thành Timeline

Khi một incident kéo dài vài giờ, channel #incident-xxx thường chứa message dồn dập từ nhiều người, xen lẫn log bot, screenshot, và bình luận không theo thứ tự thời gian rõ ràng. Gemini CLI với context window lớn có thể đọc toàn bộ và tái cấu trúc thành timeline:

Đọc toàn bộ #incident-2026-0815 từ 09:00 đến 14:00 hôm nay.
Tạo timeline dạng bảng: thời gian | sự kiện | người thực hiện | nguồn (link message).
Kết thúc bằng một đoạn "Root Cause Summary" 3-4 câu.
Đăng kết quả vào #postmortems dưới dạng message mới, kèm link
tới channel incident gốc.

Kết quả là một bảng timeline sạch sẽ mà trước đây phải mất 30-45 phút để một engineer tự đọc lại và ghép nối bằng tay. Đây chính là use case biện minh rõ nhất cho việc đầu tư tích hợp Slack MCP — giảm gánh nặng "hành chính hoá incident" (viết postmortem, tổng hợp timeline) để engineer tập trung vào xử lý kỹ thuật thật.

Mẹo: Yêu cầu agent giữ nguyên link gốc tới từng message quan trọng trong timeline (Slack cho phép copy "link to message") — giúp người đọc postmortem sau này bấm vào để xem nguyên văn ngữ cảnh, không phải chỉ tin vào bản tóm tắt.

So Sánh Hành Vi Slack 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ụ:

Khía cạnh Gemini CLI Claude Code
Cấu hình settings.json, biến $VAR .mcp.json, biến ${VAR}
Xử lý thread dài Tốt nhờ context window lớn, ít cần chia chunk Vẫn tốt nhưng nên chia chunk sớm hơn với thread cực dài
Xác nhận trước khi post Tuỳ theo cấu hình approval mode (--yolo bỏ qua xác nhận) Có cơ chế permission mode rõ ràng theo tool
Debug tool call Cần flag --debug để xem JSON-RPC thô Log hiển thị sẵn trong transcript, dễ xem hơn
Format markdown Slack Cả hai đều cần được nhắc rõ dùng cú pháp Slack (*bold*) thay vì Markdown chuẩn Tương tự

Điểm chung quan trọng nhất: cả hai đều không tự biết cú pháp Slack markdown khác Markdown chuẩn nếu bạn không nhắc trong system prompt — đây là lỗi phổ biến khiến message đăng ra bị hiển thị sai (**text** thay vì *text*).

Mẹo: Nếu team dùng song song nhiều CLI agent, hãy viết chung một file hướng dẫn ngắn (ví dụ SLACK_STYLE_GUIDE.md) mô tả format, tone, quy tắc mention — rồi include file này vào context của cả Gemini CLI và Claude Code, đảm bảo message đăng ra nhất quán bất kể công cụ nào tạo ra nó.

Lưu Ý Thêm Khi Dùng Gemini CLI Với Slack MCP

Vài điểm thực tế đáng ghi nhớ khi đưa Gemini CLI vào workflow Slack hàng ngày:

  • Cẩn trọng với flag --yolo. Flag này bỏ qua toàn bộ xác nhận trước khi thực thi tool, kể cả action ghi dữ liệu như post_message — chỉ nên dùng trong môi trường sandbox test, tuyệt đối không dùng khi agent có quyền post vào channel thật của công ty.
  • Model lớn (Gemini 1.5/2.x Pro) xử lý tool-calling nhiều bước tốt hơn model flash/nhỏ khi task cần phối hợp nhiều tool Slack liên tiếp (search rồi post rồi reply) — nếu thấy agent bỏ bước hoặc gọi tool sai thứ tự, thử đổi sang model lớn hơn trước khi nghi ngờ do cấu hình MCP.
  • Log JSON-RPC qua --debug khá dài — nên redirect ra file (gemini --debug > debug.log 2>&1) khi cần soi lỗi tool call chi tiết, thay vì đọc trực tiếp trên terminal.

Mẹo: Trước khi giao một quy trình Slack quan trọng (như thông báo incident) cho Gemini CLI chạy tự động theo lịch (cron/CI), hãy chạy thử ít nhất 5-10 lần thủ công để chắc chắn agent không bỏ sót bước xác nhận hay hiểu sai phạm vi channel.

Tiếp Slack MCP với Cursor