Nếu bạn đã quen dùng Figma MCP với Claude Code hay VS Code, chuyển sang Gemini CLI của Google không khó — nhưng có vài điểm khác biệt về cách khai báo config, cách xác thực, và quan trọng hơn là chất lượng output khi model xử lý cùng một bộ tool. Bài này đi thẳng vào việc setup Figma MCP cho Gemini CLI, dùng thử các tool trích xuất design context, làm một ví dụ thực tế sinh CSS variables từ design token, và cuối cùng đối chiếu trực diện với Claude Code để bạn biết nên dùng công cụ nào cho việc gì.
Gemini CLI là AI coding agent chạy trên terminal do Google phát triển, hỗ trợ MCP (Model Context Protocol — giao thức chuẩn hóa cách AI agent kết nối với công cụ và nguồn dữ liệu bên ngoài) theo đúng spec chung, nên về lý thuyết mọi MCP server viết cho Claude cũng chạy được cho Gemini CLI. Thực tế triển khai thì có vài "gotcha" (điểm cần lưu ý) đáng nói.
Cài Đặt và Kết Nối Figma MCP vào Gemini CLI
Trước tiên cần cài Gemini CLI qua npm. Yêu cầu Node.js từ bản 20 trở lên:
npm install -g @google/gemini-cli
Kiểm tra cài đặt thành công:
gemini --version
Lần đầu chạy gemini trong terminal, CLI sẽ hỏi bạn đăng nhập Google account (hoặc dùng API key riêng nếu bạn muốn dùng qua Gemini API trả phí thay vì gói miễn phí). Sau bước này bạn đã có thể chat với Gemini ngay trong terminal, nhưng chưa có quyền truy cập Figma.
Gemini CLI đọc cấu hình MCP server từ file settings.json, có hai vị trí tương ứng hai phạm vi áp dụng:
- Global:
~/.gemini/settings.json— áp dụng cho mọi project bạn chạy Gemini CLI. - Project-level:
.gemini/settings.jsonngay trong thư mục project — chỉ áp dụng khi bạn chạygeminitừ project đó, override lên trên config global.
Khai báo Figma MCP server dưới key mcpServers:
{
"mcpServers": {
"figma": {
"httpUrl": "https://mcp.figma.com/mcp",
"trust": false
}
}
}
Vài điểm cần chú ý về config này:
httpUrlchỉ tới remote MCP server chính thức của Figma (khác với server chạy local qua Figma desktop app dùng cho Claude Code/Cursor ở bài trước — nếu bạn từng setup local server dạngcommand/argschạy qua Figma desktop app, config đó không dùng lại được ở đây, phải trỏ sang remote endpoint).trust: falsenghĩa là Gemini CLI sẽ hỏi xác nhận (confirm) trước mỗi lần gọi tool thuộc server này — nên đểfalsekhi mới làm quen, chỉ chuyển sangtruekhi bạn đã tin tưởng workflow và muốn giảm số lần phải bấm "yes".- Có thể thêm nhiều server khác cùng cấp trong
mcpServers, ví dụ vừa cófigmavừa có server GitHub, Jira nội bộ.
Sau khi lưu file, khởi động lại phiên Gemini CLI (hoặc chạy lại lệnh gemini trong thư mục project). Vì đây là remote MCP server, bước kết nối đầu tiên sẽ yêu cầu xác thực qua OAuth (giao thức ủy quyền chuẩn, không cần chia sẻ mật khẩu trực tiếp) — Gemini CLI tự mở trình duyệt, bạn đăng nhập bằng tài khoản Figma đang dùng, xác nhận quyền truy cập, sau đó token được lưu cục bộ (thường ở ~/.gemini/ hoặc thư mục cache của CLI) để các lần chạy sau không phải đăng nhập lại. Nếu bạn dùng máy không có trình duyệt (SSH vào server, container CI), Gemini CLI sẽ in ra URL để bạn copy sang máy khác mở thủ công — một điểm hơi bất tiện so với việc chạy local hoàn toàn.
Để kiểm tra kết nối đã thành công chưa, gõ lệnh:
/mcp
ngay trong phiên chat Gemini CLI. Lệnh này liệt kê toàn bộ MCP server đã cấu hình, trạng thái kết nối (connected/disconnected/error), và danh sách tool mà mỗi server expose ra. Nếu thấy server figma ở trạng thái connected kèm danh sách 6 tool (get_code, get_variable_defs, get_screenshot, get_code_connect_map, get_metadata, create_design_system_rules) thì bạn đã sẵn sàng.
Một lỗi hay gặp: nếu bạn đổi tài khoản Figma (ví dụ chuyển giữa account cá nhân và account tổ chức), token cũ vẫn còn hiệu lực nhưng trỏ sai workspace, dẫn tới lỗi "file not found" dù link Figma đúng. Cách xử lý là xóa token cache và chạy lại flow OAuth.
Mẹo: Nếu làm việc trên nhiều project Figma khác nhau cho nhiều khách hàng, đừng đặt config MCP ở global
~/.gemini/settings.json— hãy đặt riêng ở.gemini/settings.jsontrong từng project repo và thêm file này vào.gitignorenếu có thông tin nhạy cảm, để tránh nhầm context giữa các dự án và tránh commit nhầm token/URL nội bộ lên git.
Dùng Tool Figma MCP để Trích Xuất Design Context trong Gemini CLI
Figma MCP server expose 6 tool chính, và hiểu rõ vai trò từng tool giúp bạn viết prompt hiệu quả hơn nhiều so với việc chỉ ném link Figma vào và hy vọng model tự biết cần gọi tool nào.
get_metadata — trả về cấu trúc cây node (node tree) ở dạng rút gọn: tên layer, loại node (FRAME, TEXT, INSTANCE...), vị trí, kích thước, nhưng không kèm chi tiết style đầy đủ. Đây là tool nên gọi đầu tiên khi làm việc với một frame lạ, vì nó giúp model (và cả bạn) nắm được bức tranh tổng thể trước khi đào sâu — đặc biệt quan trọng với frame có nhiều node lồng nhau (nested node), tránh việc model "đoán mò" cấu trúc.
get_code — tool trung tâm, sinh code (mặc định React + Tailwind, nhưng có thể yêu cầu framework khác trong prompt) từ một node cụ thể. Input là node ID hoặc link Figma kèm node ID trong query string (?node-id=...). Output là JSX/HTML kèm class hoặc inline style tương ứng.
get_variable_defs — lấy danh sách design token (biến màu sắc, spacing, typography, radius...) đang được áp dụng trong phạm vi một node, trả về dạng key-value kèm tên biến gốc trong Figma (ví dụ color/primary/500, spacing/md). Đây là tool quan trọng nhất khi mục tiêu là đồng bộ design system thay vì chỉ lấy code của một màn hình đơn lẻ.
get_screenshot — chụp ảnh render của node, dùng để model đối chiếu trực quan giữa code sinh ra và thiết kế gốc. Về bản chất đây là input dạng ảnh gửi kèm vào context của model — chất lượng xử lý phụ thuộc vào khả năng vision của model đang chạy phía sau Gemini CLI.
get_code_connect_map — trả về ánh xạ (mapping) giữa node Figma và component code thật trong codebase, nếu team bạn đã cấu hình Code Connect (tính năng của Figma cho phép gắn component Figma với component React/Vue thật, kèm đường dẫn file và tên props). Nếu chưa cấu hình Code Connect, tool này trả về rỗng hoặc báo không tìm thấy mapping — không phải lỗi, chỉ là chưa có dữ liệu.
create_design_system_rules — sinh ra file rule mô tả design system (dạng markdown hoặc config) dựa trên phân tích token và component đã quét được, dùng làm ngữ cảnh nền cho các lần generate code sau, giúp model tuân theo convention của bạn thay vì bịa ra class name mới mỗi lần.
Một prompt thực tế kết hợp nhiều tool:
Lấy metadata của frame này: https://www.figma.com/design/abc123/App?node-id=42-100
Sau đó lấy code cho node "Card - Product" bên trong frame đó,
và cho tôi biết token màu/spacing nào đang được dùng.
Gemini CLI sẽ tự quyết định gọi tuần tự get_metadata → get_code → get_variable_defs dựa trên yêu cầu, miễn là bạn diễn đạt rõ ràng cần gì. Với node lồng sâu (một Card nằm trong List nằm trong Section), nên tách nhỏ yêu cầu theo từng bước thay vì hỏi tất cả một lần — model dễ bỏ sót context nếu cây node quá lớn so với context window (giới hạn lượng token model xử lý một lần) đang khả dụng.
Mẹo: Khi frame Figma có nhiều biến thể (variant) của cùng một component (ví dụ nút Button có 5 state: default, hover, disabled...), đừng gọi
get_codetrên cả component set — hãy chỉ định rõ node ID của variant cụ thể bạn cần. Gọi trên cả set thường ra code dư thừa lẫn lộn giữa các state, khó tách sau này.
Ví Dụ Thực Tế: Sinh CSS từ Design Token Figma trong Gemini CLI
Đây là workflow rất phổ biến khi làm việc với design system: lấy token từ Figma, biến thành file CSS variables để dùng xuyên suốt codebase, thay vì hard-code màu/spacing rải rác.
Giả sử bạn có một frame tên "Design Tokens" trong Figma, chứa các style màu chủ đạo, spacing scale, và typography. Bước đầu, mở phiên Gemini CLI trong thư mục project frontend, đảm bảo /mcp báo server figma đã connected, rồi gõ prompt:
Dùng get_variable_defs để lấy toàn bộ design token (màu sắc, spacing,
typography) từ frame Figma này:
https://www.figma.com/design/abc123/DesignSystem?node-id=10-50
Sau đó tạo file src/styles/tokens.css với các CSS custom properties
tương ứng, theo quy tắc:
- Token màu đặt trong khối :root, tiền tố --color-
- Token spacing tiền tố --spacing-
- Token typography (font-size, line-height) tiền tố --font-
- Giữ nguyên tên gốc từ Figma nhưng chuyển sang kebab-case
- Thêm comment phía trên mỗi nhóm token nêu rõ nguồn gốc (tên style trong Figma)
Sau khi Gemini CLI gọi get_variable_defs, nó sẽ nhận về dữ liệu dạng tương tự:
{
"color/primary/500": "#2563EB",
"color/neutral/900": "#111827",
"color/danger/500": "#DC2626",
"spacing/xs": "4px",
"spacing/md": "16px",
"spacing/xl": "32px",
"typography/heading-lg/fontSize": "28px",
"typography/heading-lg/lineHeight": "36px"
}
Và sinh ra file CSS tương ứng:
:root {
/* Color tokens — nguồn: Figma style "Primitives/Color" */
--color-primary-500: #2563EB;
--color-neutral-900: #111827;
--color-danger-500: #DC2626;
/* Spacing tokens — nguồn: Figma style "Spacing Scale" */
--spacing-xs: 4px;
--spacing-md: 16px;
--spacing-xl: 32px;
/* Typography tokens — nguồn: Figma style "Heading LG" */
--font-heading-lg-size: 28px;
--font-heading-lg-line-height: 36px;
}
Kết quả thực tế thường cần tinh chỉnh vài chỗ: model đôi khi giữ nguyên tên biến gốc dạng color/primary/500 (có dấu /) thay vì chuyển đúng kebab-case như yêu cầu, hoặc bỏ sót một vài token nếu frame chứa quá nhiều style không liên quan trực tiếp đến node bạn chỉ định. Cách xử lý thực dụng là yêu cầu review lại ngay trong cùng phiên:
Kiểm tra lại file vừa tạo, đối chiếu với danh sách token gốc,
liệt kê token nào bị thiếu hoặc đặt sai tên convention.
Một bước nâng cao hơn: sau khi có tokens.css, bạn có thể yêu cầu Gemini CLI generate luôn file Tailwind config map các token này vào theme, hoặc sinh SCSS map tương đương nếu codebase dùng Sass thay vì CSS thuần — chỉ cần đổi yêu cầu format output trong prompt, tool get_variable_defs không đổi.
Mẹo: Luôn yêu cầu Gemini CLI in ra bảng đối chiếu "token Figma gốc → biến CSS sinh ra" ngay trong response text (không chỉ ghi vào file) trước khi merge. Việc này giúp bạn (hoặc reviewer trong PR) phát hiện ngay lệch tên hay thiếu token mà không cần mở lại Figma so sánh thủ công từng dòng.
So Sánh Chất Lượng Output Figma MCP Giữa Gemini CLI và Claude Code
Sau khi đã dùng cả hai công cụ này trên cùng một bộ frame Figma thực tế (component library có nested component, variant, và Code Connect map đã cấu hình sẵn), có vài khác biệt rõ rệt đáng ghi nhận — không phải để tuyên bố công cụ nào "thắng" tuyệt đối, mà để chọn đúng công cụ cho đúng việc.
Với các tác vụ trích xuất dữ liệu có cấu trúc (structured data) như lấy token qua get_variable_defs hay quét metadata một frame lớn, Gemini CLI phản hồi khá nhanh và ổn định — có thể do model xử lý tốt các tác vụ dạng liệt kê/chuyển đổi dữ liệu JSON sang format khác. Ngược lại, khi yêu cầu sinh code cho component phức tạp có nhiều state và nested node, output từ Claude Code thường bám sát cấu trúc component thật hơn, ít bị "làm phẳng" (flatten) cấu trúc phân cấp của node so với thiết kế gốc.
Một khác biệt lớn khác nằm ở việc tuân theo Code Connect map. Khi frame đã có mapping tới component React thật trong codebase, Claude Code có xu hướng ưu tiên tái sử dụng đúng component đã map (import đúng component, đúng tên prop) thay vì viết lại JSX từ đầu — điều này quan trọng với team đã đầu tư thời gian setup Code Connect, vì mục tiêu của họ chính là để AI dùng lại component có sẵn thay vì tạo trùng lặp. Gemini CLI đôi khi vẫn sinh JSX mới dù đã có mapping, đòi hỏi bạn phải nhắc lại rõ ràng trong prompt "hãy dùng component đã map qua Code Connect, đừng viết mới".
Về xử lý get_screenshot, cả hai đều nhận ảnh làm input để đối chiếu trực quan, nhưng mức độ "bắt lỗi" giữa ảnh và code sinh ra (ví dụ lệch padding vài pixel, sai shade màu) có xu hướng rõ hơn ở Claude Code trong các trường hợp mình thử nghiệm — có thể vì cách model được huấn luyện gắn liền chặt hơn với các tác vụ coding chi tiết pixel-level. Đây là quan sát thực chiến, không phải kết luận benchmark chính thức, nên bạn nên tự thử trên chính bộ component của mình trước khi kết luận.
Về độ ổn định kết nối MCP remote, cả hai CLI đều dùng chung endpoint mcp.figma.com nên tỷ lệ lỗi timeout hay rớt kết nối tương đương nhau — vấn đề chủ yếu đến từ phía server Figma (đang trong giai đoạn beta, thỉnh thoảng rate-limit) hơn là từ client.
| Tiêu chí | Gemini CLI | Claude Code |
|---|---|---|
| Độ chính xác code sinh ra (fidelity với design) | Khá tốt với layout đơn giản, đôi khi làm phẳng cấu trúc phức tạp | Thường bám sát cấu trúc gốc hơn với component nhiều state/nested node |
| Hiểu context nhiều node lồng nhau | Tốt khi tách nhỏ yêu cầu theo từng bước | Xử lý tốt cả khi yêu cầu gộp nhiều bước trong một prompt |
Xử lý ảnh từ get_screenshot |
Nhận diện tổng thể ổn, đôi khi bỏ sót lệch nhỏ (padding, shade màu) | Thường bắt lỗi chi tiết pixel-level tốt hơn |
| Tốc độ phản hồi | Nhanh, đặc biệt với tác vụ trích xuất token/dữ liệu thuần | Tương đương hoặc chậm hơn đôi chút với tác vụ phức tạp |
| Tuân theo Code Connect map | Cần nhắc rõ trong prompt mới ưu tiên dùng lại component đã map | Có xu hướng tự ưu tiên component đã map mà ít cần nhắc |
| Mức cần chỉnh tay sau khi generate | Trung bình, hay phải sửa tên biến/convention | Thấp hơn với component phức tạp, vẫn cần review với layout đơn giản |
| Độ ổn định kết nối MCP remote | Tương đương (cùng phụ thuộc mcp.figma.com) |
Tương đương (cùng phụ thuộc mcp.figma.com) |
Tóm lại theo kinh nghiệm thực chiến: nếu công việc chính là trích xuất dữ liệu có cấu trúc — token, metadata, audit design system — Gemini CLI làm nhanh gọn và đủ dùng. Nếu công việc là generate code thật cho component phức tạp, nhiều state, cần bám sát Code Connect map đã đầu tư công sức setup, Claude Code hiện cho kết quả cần chỉnh tay ít hơn. Không có công cụ nào toàn diện tuyệt đối — nhiều team thực tế dùng kết hợp: Gemini CLI cho bước khảo sát/trích xuất nhanh, rồi chuyển sang Claude Code cho bước generate code production.
Mẹo: Đừng chọn công cụ dựa trên bài so sánh chung chung (kể cả bài này) — hãy tự chạy cùng một prompt trên chính bộ component thật của team bạn với cả hai CLI, so sánh diff giữa code sinh ra và component gốc trong 15-20 phút. Đặc điểm component library của mỗi team (mức độ nesting, số lượng variant, có Code Connect hay chưa) ảnh hưởng tới kết quả nhiều hơn là đặc điểm chung của model.