Airtable MCP với Gemini CLI

Gemini CLI là coding agent terminal của Google, hỗ trợ MCP qua file settings.json, và có một điểm mạnh riêng khi làm việc với dữ liệu dạng bảng: context window (cửa sổ ngữ cảnh) lớn giúp nó xử lý tốt việc đọc và tổng hợp một lượng lớn record cùng lúc mà không cần page nhiều lần. Bài này hướng dẫn cài đặt Airtable MCP cho Gemini CLI, cách filter view và aggregate (tổng hợp) record ngay từ CLI, một ví dụ thực tế tạo backlog health report, và so sánh output thực tế giữa Gemini CLI và Claude Code khi làm cùng một tác vụ Airtable để bạn biết nên chọn công cụ nào cho từng loại việc.

Cài Đặt Và Kết Nối Airtable MCP Vào Gemini CLI

Gemini CLI đọc cấu hình MCP server từ ~/.gemini/settings.json (cấp user) hoặc .gemini/settings.json trong project (cấp project, ưu tiên cao hơn khi cả hai cùng tồn tại).

{
  "mcpServers": {
    "airtable": {
      "command": "npx",
      "args": ["-y", "airtable-mcp-server"],
      "env": {
        "AIRTABLE_API_KEY": "patXXXXXXXXXXXXXX.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      },
      "timeout": 30000
    }
  }
}

Field timeout (đơn vị milli-giây) đáng chú ý riêng với Gemini CLI: khi bạn giao task tổng hợp lớn (đọc hàng nghìn record qua nhiều lần gọi list_records liên tiếp), timeout mặc định của một số version có thể quá ngắn khiến tool call bị hủy giữa chừng — nên set tường minh giá trị đủ lớn (20-30 giây) ngay từ đầu.

Sau khi lưu config, khởi động Gemini CLI và kiểm tra server bằng lệnh:

gemini
/mcp list

Lệnh này hiện danh sách MCP server đã đăng ký kèm số tool mỗi server expose ra — nếu airtable hiện 0 tool hoặc trạng thái lỗi, thường do token PAT sai định dạng hoặc thiếu quyền data.records:read tối thiểu.

Kiểm tra nhanh bằng một prompt đơn giản:

Kết nối tới Airtable MCP và cho tôi biết những base nào tôi
đang có quyền truy cập.

Mẹo: Khi làm việc với base có schema lớn (nhiều table, nhiều field phức tạp), tăng giá trị timeout lên 60000 (60 giây) ngay từ đầu cho các tác vụ tổng hợp/báo cáo — chi phí chờ thêm vài giây rẻ hơn nhiều so với việc phải chạy lại toàn bộ task vì bị timeout giữa chừng.

Filter View Và Aggregate Record Từ Gemini CLI

Gemini CLI xử lý tốt các tác vụ cần đọc nhiều record rồi tính toán tổng hợp (aggregate) nhờ khả năng giữ nhiều dữ liệu trong context cùng lúc. Đây là nhóm việc bạn nên tận dụng nó nhiều nhất so với các agent khác.

Filter theo view đã định nghĩa sẵn trong Airtable (nếu team bạn đã setup view "This Sprint", "Overdue"...):

Trong base "Product Roadmap", table "Requirements", đọc dữ liệu
theo view "Overdue" (view đã filter Due Date < hôm nay và
Status khác Done). Liệt kê Title, Assignee, số ngày đã quá hạn.

Việc dùng view có sẵn thay vì tự viết filterByFormula từ đầu có lợi thế: logic filter đã được team thống nhất và maintain sẵn trong Airtable UI, agent chỉ cần đọc đúng view, giảm rủi ro viết công thức sai.

Aggregate theo nhóm — đây là điểm Gemini CLI thường cho kết quả rất chắc tay:

Đọc toàn bộ record trong table "Requirements".
Tính số lượng record theo từng Status, và theo từng Assignee.
Trình bày hai bảng riêng: bảng theo Status, bảng theo Assignee
(sắp giảm dần theo số lượng).

Aggregate có điều kiện thời gian — tận dụng tốt các hàm ngày tháng:

Trong table "Requirements", tính effort trung bình (field
"Effort (story points)") của các record đã Done, nhóm theo tháng
Merged Date, cho 6 tháng gần nhất. Chỉ ra tháng nào effort trung
bình cao bất thường (> 1.5x trung bình chung).

Với các câu hỏi dạng "chỉ ra bất thường", cần nói rõ ngưỡng cụ thể (như "> 1.5x trung bình") thay vì để agent tự định nghĩa "bất thường" theo cảm tính — cách này giúp kết quả nhất quán giữa các lần chạy lại cùng câu hỏi.

Mẹo: Khi câu hỏi cần tính toán số học chính xác (trung bình, phần trăm), luôn yêu cầu agent liệt kê công thức/số liệu thô đã dùng để tính ra kết quả cuối — mô hình ngôn ngữ vẫn có thể tính sai số học với tập dữ liệu lớn, và việc thấy được "phép tính" giúp bạn tự kiểm tra lại nhanh.

Ví Dụ Thực Tế: Tạo Backlog Health Report Từ Airtable

Một báo cáo rất hay được yêu cầu trong sprint review: "backlog health report" — bức tranh tổng thể về tình trạng backlog, không chỉ đếm số lượng mà còn chỉ ra rủi ro (stale item, thiếu assignee, effort chưa ước lượng).

Prompt đầy đủ:

Đọc toàn bộ record trong table "Requirements" (base "Product Roadmap")
có Status khác "Done" và khác "Archived".
Tạo backlog health report gồm các phần:

1. Tổng quan số lượng: tổng số item, phân theo Status.
2. Stale items: record có Status = "In Progress" nhưng
   Last Modified > 14 ngày trước — liệt kê Title, Assignee,
   số ngày không cập nhật.
3. Missing data: record thiếu Assignee HOẶC thiếu Effort — liệt kê
   Title và trường nào đang thiếu.
4. Priority mismatch: record có Priority = "High" nhưng vẫn ở
   Status = "New" quá 5 ngày kể từ Created Date — đây là dấu hiệu
   item quan trọng bị bỏ quên.
5. Risk score tổng thể: tính điểm rủi ro backlog từ 0-100 dựa trên
   tỷ lệ stale items + missing data + priority mismatch trên tổng
   số item, giải thích ngắn công thức tính.

Trình bày dạng Markdown, có heading rõ cho từng phần.

Kết quả mẫu (rút gọn):

## Backlog Health Report — 2026-08-22

### 1. Tổng quan
- Tổng: 47 item đang mở
- New: 18 | In Progress: 21 | Blocked: 8

### 2. Stale items (5)
- "Add rate limiting to public API" — Minh Tran — 19 ngày không cập nhật
- ...

### 3. Missing data (3)
- "Improve export performance" — thiếu Effort
- ...

### 4. Priority mismatch (2)
- "Fix checkout timeout on mobile" — High priority, 9 ngày chưa vào In Progress

### 5. Risk score: 62/100 (Trung bình-cao)
Công thức: (stale/total * 40) + (missing/total * 30) + (mismatch/total * 30)

Bước hữu ích tiếp theo: lưu report này lại thành record trong một table riêng (Sprint Reports) để có lịch sử theo dõi risk score qua từng tuần, giúp bạn nhìn thấy xu hướng backlog đang tốt lên hay xấu đi theo thời gian, không chỉ một snapshot rời rạc.

Mẹo: Chạy report này định kỳ (đầu mỗi sprint) và lưu risk score vào một table lịch sử — chỉ cần vài dòng dữ liệu theo thời gian, bạn đã có được một biểu đồ xu hướng sức khỏe backlog rất thuyết phục để trình bày trong sprint review, thay vì chỉ báo cáo con số một lần.

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

Cả hai đều gọi cùng một Airtable MCP server, cùng schema, nhưng cách agent diễn giải task và trình bày kết quả có khác biệt đáng chú ý trong thực tế sử dụng:

Gợi ý chọn công cụ theo tình huống thực tế: nếu task chính là đọc/tổng hợp/báo cáo trên tập dữ liệu lớn, Gemini CLI thường cho kết quả nhanh và đúng cấu trúc yêu cầu. Nếu task chính là ghi dữ liệu gắn với logic code (ví dụ đồng bộ status theo PR, cần agent hiểu sâu ngữ cảnh code trong repo), Claude Code có xu hướng cho kết quả thận trọng và bám sát convention hiện có của repo hơn.

Mẹo: Với các task quan trọng ảnh hưởng dữ liệu thật, chạy thử cùng một prompt trên cả hai agent (nếu bạn có sẵn cả hai) và so sánh kết quả trước khi tin tưởng giao hoàn toàn cho một công cụ duy nhất — sự khác biệt trong cách diễn giải một câu prompt mơ hồ giữa hai model đôi khi lộ ra chính điểm mơ hồ mà bạn cần làm rõ lại trong prompt gốc.

Mẹo Thực Chiến

• Luôn set timeout đủ lớn trong config Gemini CLI cho các tác vụ tổng hợp dữ liệu lớn, tránh tool call bị hủy giữa chừng.
• Ưu tiên dùng view đã định nghĩa sẵn trong Airtable (qua UI) khi có thể, thay vì luôn để agent tự viết filterByFormula từ đầu.
• Với câu hỏi thống kê/bất thường, luôn định nghĩa ngưỡng số cụ thể trong prompt, không để agent tự quyết định thế nào là "bất thường".
• Lưu lại các báo cáo định kỳ (backlog health, sprint summary) vào một table lịch sử trong Airtable để có dữ liệu xu hướng theo thời gian.
• Với task quan trọng, đối chiếu kết quả giữa nhiều agent nếu có thể, đặc biệt là các phép tính tổng hợp trên tập dữ liệu lớn.

Mẹo: Viết sẵn các prompt template chuẩn cho report định kỳ (backlog health, sprint summary) vào một file trong repo, để cả team dùng chung một chuẩn báo cáo nhất quán qua các sprint, không phụ thuộc vào việc mỗi người diễn đạt yêu cầu khác nhau mỗi lần.