TalkToFigma MCP：讓 Cursor 直接改 Figma 設計稿的橋接方案

它解決什麼問題，誰該注意

設計與開發之間的文字往返，通常是工程師看著 Figma 設計稿，手動把顏色、間距、文字內容搬進程式碼，或反過來把文案修改回填到設計稿。TalkToFigma 想消除這層手工。它讓 Cursor、Claude Code 這類 AI Agent 直接透過 Model Context Protocol 呼叫工具，讀取目前文件、選取範圍、節點屬性，也能建立矩形、框架、文字，甚至批次改寫多個文字節點。目標使用者是那些已經把 AI Agent 當作日常開發夥伴的工程師或設計工程師，他們希望把設計檔案變成 Agent 可以操作的對象，而不是只靠截圖給模型看。此專案不是給純設計師用的，它要求你熟悉命令列、JSON 設定與 WebSocket 概念。若你的工作流程沒有程式化修改設計的需求，這個工具提供的功能會是多餘的。

架構拆解：MCP 伺服器、WebSocket 與 Figma 外掛的三段式通訊

這個專案的核心不是單一程式，而是三個協同元件。首先是 TypeScript 寫成的 MCP 伺服器，位於 src/talk_to_figma_mcp/，它負責對外提供工具介面，讓 Cursor 或 Claude Code 透過標準 MCP 協定呼叫。其次是 Figma 外掛，位於 src/cursor_mcp_plugin/，它跑在 Figma 的沙盒環境內，能存取文件與節點 API。最後是 src/socket.ts，一個 WebSocket 伺服器，扮演兩者之間的橋樑。資料流是這樣的：Agent 呼叫 MCP 工具，伺服器把請求轉成 WebSocket 訊息，外掛收到後在 Figma 內執行對應操作，再把結果傳回。外掛需要先加入一個 channel，例如透過 join_channel 指令，才能與伺服器配對。這個設計迴避了 Figma 外掛無法直接監聽 TCP 連線的限制，但代價是必須同時維持外掛與 WebSocket 伺服器兩條連線。文件提到 Windows 與 WSL 環境需要把 socket.ts 中的 hostname 改為 0.0.0.0，否則連線可能失敗，這說明了此架構對網路環境的敏感度。

安裝與啟動：Bun 是必要前提，設定檔決定一切

安裝流程以 Bun 為中心。你需要先安裝 Bun，然後在專案目錄執行 bun setup，這個指令會同時把 MCP 伺服器註冊到 Cursor 目前啟用的專案。接著執行 bun socket 啟動 WebSocket 伺服器。Figma 端的安裝有兩種方式：直接從 Figma Community 頁面安裝外掛，或手動載入。手動路徑是在 Figma 的 Plugins 選單下選擇 Development 然後 New Plugin，再選 Link existing plugin，指向 src/cursor_mcp_plugin/manifest.json。若不想用 bun setup，也可以手動編輯 ~/.cursor/mcp.json，加入類似這樣的設定：指定 command 為 bunx，args 為 cursor-talk-to-figma-mcp@latest。本機開發時則改為直接執行 server.ts。這個流程對熟悉 Node.js 生態的人不難，但 Bun 並非預設安裝，且 bun setup 的行為可能因 Cursor 版本而異，文件沒有詳細說明它會修改哪個設定檔。

工具清單的廣度與深度：從讀取到修改，但有些操作需要前置條件

MCP 伺服器提供的工具涵蓋文件讀取、選取管理、註解、原型連線、元素建立、文字修改、自動佈局、樣式調整、元件操作與匯出。讀取方面有 get_document_info、get_selection、get_node_info，可以讓 Agent 理解目前畫布狀態。修改方面，create_rectangle、create_frame、create_text 等工具讓 Agent 能生成新元素。文字批次替換是文件特別提到的功能，由社群貢獻，可以掃描文字節點並大量更新。元件操作包含 get_instance_overrides 與 set_instance_overrides，能從來源 instance 提取覆寫，再套用至多個目標，這對重複的卡片或列表設計很有用。但要注意，某些工具依賴特定狀態。例如 set_default_connector 必須在 create_connections 之前設定，否則無法建立 FigJam 連線。create_component_instance 需要先知道本地元件的 ID，而取得 ID 得靠 get_local_components。工具之間存在隱含依賴，Agent 若沒有正確的順序，可能得到錯誤結果。文件沒有列出每個工具需要的參數型別，實際使用時需要依賴 MCP 的 schema 提示，這對除錯會增加一點成本。

真正的限制：外掛必須手動開啟，且無法處理 Figma 的所有功能

這個專案有個根本性的操作限制：Figma 外掛必須由使用者手動執行。外掛不會在 Figma 開啟時自動啟動，你必須先開啟 Figma，然後從外掛選單執行 Cursor MCP Plugin，再讓它連上 WebSocket。這意味著整個自動化流程無法完全無人值守，你仍然需要有人打開 Figma 並啟動外掛。此外，工具清單雖然廣，但主要圍繞在節點層級的操作。它不包含 Figma 的協作功能，例如多人同時編輯的即時同步、留言或版本歷史的讀取。若你的設計流程依賴這些，此工具幫不上忙。另一個限制是文件沒有提及錯誤處理機制，例如當 WebSocket 連線中斷時，MCP 伺服器會如何反應，外掛是否會自動重連，這些都沒有說明。在長時間的自動化任務中，連線穩定性會是實際的風險。若你只需要讀取設計而不修改，Figma 官方提供的 REST API 或 Plugin API 可能更直接，不需要額外維護一個 WebSocket 伺服器。

替代方案：Figma REST API 與其他 MCP 外掛的差異

要理解 TalkToFigma 的定位，可以把它與 Figma REST API 比較。Figma 官方 REST API 允許你讀取文件、取得節點資料，但官方 API 對寫入操作有限制，你無法透過 REST API 直接建立或修改節點。TalkToFigma 利用 Figma 外掛的完整 Plugin API，因此能執行寫入操作，這是它與官方 API 的最大區別。另一個替代方案是 Figma 社群中的其他 MCP 外掛，例如某些專案直接透過 Plugin API 提供 HTTP 端點，讓 Agent 以 HTTP 請求操作設計。那種做法通常不需要 WebSocket，但可能要求 Figma 外掛監聽特定 port，而 Figma 的外掛沙盒不允許任意網路監聽，因此這類方案往往需要額外的代理程式。TalkToFigma 選擇以 WebSocket 伺服器作為中介，本質上也是繞過沙盒限制，但它把連線管理集中在外掛端，使用者需要自行啟動 socket 程式。若你偏好官方支援，Figma 的 Dev Mode 與程式碼連結功能提供另一種互動方式，但那不是 MCP 協定，Agent 無法直接呼叫工具。

維護成本與授權：MIT 許可但無版本標記，升級需自行追蹤

此專案以 MIT 授權釋出，代表你可以自由使用、修改與商用，但授權條款不提供任何擔保，這點在採用前要心裡有數。從維護角度來看，最後一次 push 是 2026 年 7 月，但沒有列出任何正式 release，這表示你必須依賴 main 分支的最新狀態。沒有版本標記代表 bunx cursor-talk-to-figma-mcp@latest 總是拉取最新程式碼，若上游有破壞性變更，你的環境可能突然失效。另外，由於它依賴 Bun，而 Bun 本身仍在快速演進，升級 Bun 版本時可能影響 socket 或 MCP 伺服器的執行。文件沒有提供測試套件或 CI 狀態的資訊，因此你無法從專案本身得知程式碼的穩定性。若你打算長期依賴，建議 fork 一份並鎖定 commit，或自行追蹤上游變更。外掛部分需要透過 Figma 的開發外掛載入，若 Figma 更新 Plugin API，外掛可能需要調整，這部分同樣沒有版本保證。

編輯結論

若你主要使用 Cursor 或 Claude Code，且工作內容包含大量重複性的設計調整，例如批次替換文字、同步 component instance 的 override，或根據程式碼邏輯自動產生框架與佈局，TalkToFigma 提供了一條可行的自動化路徑。它不需要手動操作 Figma 介面，而是讓 Agent 直接呼叫工具，這在處理多頁面或大型設計系統時能節省可觀時間。但若你的工作仰賴 Figma 的協作審閱流程、需要處理複雜的 prototype 互動，或團隊使用 Windows 且不願調整 socket 設定，這個專案可能帶來額外負擔。採用前應先確認三件事：你的 Cursor 版本是否支援自訂 MCP 伺服器、你的 Figma 檔案是否允許外掛存取（團隊或企業版權限可能限制）、以及你對 Bun 執行環境的熟悉度。最後，由於專案沒有正式 release，所有工具行為都以 main 分支的程式碼為準，建議先在複製的測試檔案上驗證，再套用到正式設計稿。

官方來源

1. grab/cursor-talk-to-figma-mcp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README