Model Context Protocol 是一個讓 AI agent 連接資料來源的標準介面——官方文件的原話是「a standard interface that lets AI agents interact with data sources」。Figma MCP server 就是 Figma 這一側的實作：它把設計檔案裡的結構化資料暴露成 agent 可呼叫的工具，讓 Cursor、Claude Code、VS Code 之類的 client 能直接讀到設計，而不必靠人工複製貼上或截圖。
📖 最重要的一件事：分工
官方有一頁專門講這件事，而它是理解整個主題的前提：
| 誰 | 負責什麼 |
|---|---|
| MCP server | 從你選取的 Figma 圖層取得結構化的設計脈絡 |
| 你的 agent | 寫出最終的程式碼——調整版面、重用元件、遵循你的提示與 codebase |
官方對 agent 那一側的描述是：它只有在你透過 Code Connect、變數、規則檔或提示告訴它的時候，才知道你的設計系統慣例。
官方並明確指出：結果取決於脈絡的品質、模型、以及提示的清晰度三者。
這個三因素框架有實際的診斷用途。 產出不理想時，多數人直覺去換模型或改提示——但在 Figma MCP 的情境下，脈絡那一項通常才是瓶頸，而脈絡品質由你的 Figma 檔案結構與 Code Connect 決定，不是由 agent 決定。
一個快速的自我檢查：如果你的 Figma 檔案裡還有叫
Frame 1268的圖層、顏色是硬刻而非變數、重複的按鈕不是元件——那麼換任何模型都不會有明顯改善。先修脈絡。
📖 與「截圖丟給 AI」的差別
這是最常被問的問題，而差別不在便利性，在資訊的種類。
| 截圖餵圖 | Figma MCP | |
|---|---|---|
| 間距 | 模型目測推估 | auto layout 的實際參數 |
| 顏色 | 從像素取樣 | 變數名稱（如 color/bg/subtle） |
| 層級結構 | 從視覺推測 | 實際的圖層樹 |
| 重複元素 | 看起來像就各自生一份 | 元件實例，可識別為同一個 |
| 對應既有程式碼 | 無 | Code Connect 給出 import 與用法 |
| 文字 | OCR，可能出錯 | 實際字串與文字樣式 |
| 狀態與變體 | 只有畫面上那一個 | 變體屬性 |
最關鍵的一行是「對應既有程式碼」。 截圖永遠做不到這件事——它沒有任何管道知道你的 codebase 裡有一支 <Button variant="primary">。這正是 MCP 真正不可取代的地方，其餘各項都只是精確度的差異。
但截圖仍有用途，而且官方自己提供了這個工具。 get_screenshot 存在的理由是：結構化資料描述不了「看起來對不對」。實務上最好的做法是兩者並用——用結構化資料生成，用截圖驗證，見 忠實度。
📖 遠端 vs 本機
2026 年最大的結構性改變在這裡。原本只有本機版（當時叫 Dev Mode MCP server），現在官方建議用遠端版。
| 遠端伺服器 | 本機／桌面伺服器 | |
|---|---|---|
| 端點 | https://mcp.figma.com/mcp | http://127.0.0.1:3845/mcp |
| 需要 Figma 桌面 App | 否 | 是 |
| 官方定位 | 建議使用，功能最完整 | 「for specific organization and enterprise needs」 |
| 認證 | OAuth，首次連線時登入 | 透過桌面 App |
| 席次要求 | 見 限額 | Dev 或 Full 席次，且需 Professional 以上方案 |
| 獨有能力 | 寫回畫布、多數寫入工具、search_design_system、whoami 等 | — |
| Figma for Government | 不支援 | 只支援本機版，且工具受限 |
為何遠端變成主流？ 官方沒有說明理由，但從工具清單可以推出來：大量標註「Remote only」的工具都是寫入類與跨檔案查詢類——generate_figma_design、html_to_figma、create_new_file、search_design_system、list_generative_plugins。這些功能需要 Figma 後端的參與，不是一個綁在本機桌面 App 上的 server 能提供的。
選哪一個？ 除非你的組織有明確理由（合規、網路隔離、Figma for Government），否則用遠端。這與 2025 年的教學結論相反，而那些教學仍大量存在。
📖 它能做的事（官方列舉）
官方文件列出的能力範圍：
- 從選取的 frame 生成程式碼
- 擷取變數、元件與版面資料
- 用 Code Connect 讓產出與你的 codebase 一致
- 寫回畫布——在 Design、FigJam、Slides 裡建立原生內容
- 從實際運行的網頁 UI 生成設計（遠端伺服器，部分 client）
- 取得 FigJam 資源（把白板圖轉成 XML）
- 取得 Make 資源
- 讀寫 Figma Specs（透過
figma-specskill，open beta）
注意第四與第五項：這代表 Figma MCP 在 2026 年已經是雙向的。「design → code」只是其中一個方向，反方向的「code → design」也成立了。這對工作流的影響見 完整 UI workflow。
📖 兩種指向設計的方式
要讓 agent 知道你在講哪一塊設計，官方文件描述了兩種：
連結式——在 Figma 裡對 frame 或圖層按右鍵，選「Copy link to selection」，把連結貼進 client 並要求實作。官方特別說明：你的 client 不會真的去打開那個連結，它是從連結中取出 node ID。
選取式——在 Figma 裡選好 frame，然後在 client 裡說「implement the selected frame」。
連結式在團隊協作上明顯較實用。 選取式依賴「Figma 裡當下選了什麼」這個隱含狀態——你無法把它寫進 issue、PR 描述或規則檔裡。連結可以貼在任何地方並長期有效，這讓它能嵌進既有的工作流程，見 設計→工程交接。
🧠 重點整理
MCP server 只給脈絡，寫程式的是 agent。 產出品質 ＝ 脈絡品質 × 模型 × 提示。
三因素之中，脈絡通常才是瓶頸，而它由 Figma 檔案結構與 Code Connect 決定。
與截圖最關鍵的差別是「對應既有程式碼」，其餘只是精確度差異。
截圖仍有用——結構化資料描述不了「看起來對不對」，用它驗證。
2026 年官方建議遠端伺服器，本機版被定位為特定組織需求；這與 2025 年的教學結論相反。
大量寫入與跨檔案工具標註 Remote only，這解釋了為何遠端成為主流。
它現在是雙向的——從網頁 UI 生成設計、寫回畫布都已經可用。
連結式指向比選取式實用，因為連結可以寫進 issue 與規則檔，選取是隱含狀態。
✍️ 動手做
用同一個元件做一次對照，約 20 分鐘，可以親眼看出 MCP 與截圖的差距：
- 在 Figma 裡挑一個使用了變數與 auto layout 的元件（必須有這兩者，否則對照沒有意義）。
- 截一張圖，丟給 agent，請它生出程式碼。
- 用 MCP 指向同一個元件，請它生出程式碼。
- 並排比較三件事：間距數值是否正確、顏色是變數名稱還是十六進位硬碼、重複元素有沒有被識別為同一個元件。
第 4 步的第二項差距通常最明顯。如果你的 Figma 檔案沒有用變數，這三項的差距會小得多——而這本身就是一個有用的發現：它告訴你該先去修的是檔案，不是工具。
🔗 資料來源
- Figma 開發者文件 — Figma MCP server——MCP 定義、遠端與本機定位、能力列舉、方案要求（一手，2026-11-01 查證）。
- Figma 開發者文件 — MCP server vs your agent——分工的官方說明與三因素。
- Figma 開發者文件 — 工具與提示——Remote only 標註。
- Figma Help Center — Guide to the Figma MCP server——連結式與選取式的指向方式、端點。