__Figma_-_www.figma.com.png)
隨著生成式 AI 技術迅速進步，我們開始嘗試讓大型語言模型（LLM）直接操作設計工具生成的可能性。想像一下，未來的程式設計師或介面設計師可以透過 AI 助手自動讀取設計稿、編輯圖形元件，甚至將設計轉換為程式碼。這樣的願景需要強大的協議支援——模型上下文協議（Model Context Protocol, MCP）的出現正是為此而生。之前我曾分享過《善用AI強化產品架構與開發》一文，文章中提及利用 LLM 來處理產品規格書（Product Requirement Document，PRD）、系統架構圖，以及 Prototype/Wireframe，當時也是透過 LLM 採用 Ugic 這款 Figma 外掛，來生成 JSON 碼透過 Figma 繪製出使用者介面。
而隨著 Anthropic 提出 Model Context Protocol 這個開源的開放標準，加上近日 AI Agent 的議題蔚為風潮，一時之間 AI 除了只能跟人對話之外，已經可以操作不同的工具程式，很有電影《全面進化》（Transcendence）劇情的既視感。而這篇文章我將以實際作業的視角，分享一個將 MCP 應用於設計領域的開源專案**「cursor-talk-to-figma-mcp」**。從協議原理、專案架構到實際使用心得，我們將全面解析 AI 助手如何透過 MCP 與 Figma 互動，以及人機協作在這個過程中的最佳實踐與反思。
何謂 MCP？設計初衷與技術優勢 – Model Context Protocol（模型上下文協議，MCP）是由 Anthropic 在 2024 年底提出並開源的開放標準。它的目的在於為 LLM 應用與外部世界（各種工具與資料源）建立一個通用的介接方式，堪稱「AI 應用的 USB-C 接口」。在沒有 MCP 之前，每個 AI 代理（Agent）想接入不同系統，都需開發客製化邏輯，形成許多資訊孤島，也讓工作碎片化。MCP 的誕生正為了解決這個痛點——它提供一組標準規範，讓任意的 AI 用戶端可以與任意的工具伺服器溝通，大幅降低整合複雜度。
LLM 與工具溝通的新標準 – 根據官方規範文件，MCP 是一種使用 JSON-RPC 2.0 傳訊的協議，它在「主機、客戶端、伺服器」三者之間建立連線。具體來說，LLM 應用（主機）內部包含 MCP 客戶端
作為連接橋樑，一對一連上 MCP 伺服器（外部工具服務），從而標準化 LLM 調用外部工具、擷取資料的方式。這種架構深受語言伺服器協議（LSP）啟發：正如 LSP 統一了編輯器與語言分析器的溝通介面，MCP 也希望統一 AI 與各類外部工具的互動方式。透過 MCP，AI 助手不再受限於訓練語料，可以按需查詢資訊或執行操作，而且是以可擴充、跨平台的通用語言完成。換句話說，MCP 為 AI 應用提供了連接萬物的介面，使之能安全、標準化地存取外部即時資料與工具。
協議優勢與生態系 – MCP 帶來的主要技術優勢在於標準化與可組合性。它將工具功能抽象為「Resources（資源）」、「Tools（工具函式）」等統一概念供 AI 調用。例如一個 MCP 伺服器可以向 AI 提供資料查詢（如資料庫存取）或操作指令（如調用第三方 API）等功能，AI 透過統一的 JSON-RPC 介面調用，不需關心底層實作差異。這種通用規範意味著開發者只需遵循 MCP 定義的界面，就能讓不同模型與工具彼此兼容，大幅減少重複造輪子的工作。正因為這樣，自從 2024 年 11 月 MCP 推出以來，極短時間內便獲得廣泛關注與支持。Andreessen Horowitz 的報導指出，許多開發者已開始基於 MCP 打造各式應用，讓像 Cursor 這樣的 IDE 透過 MCP 變身為 Slack 客戶端、郵件助理或圖像生成器等多面手。實際上，在 MCP 工具註冊平台 Smithery.ai 上，短短數月已累積了數百個 MCP 工具伺服器案例，涵蓋生產力、資料庫、設計等領域。例如，有開發者推出整合 Gmail、行事曆等 40 多項服務的 MCP 工具套件，一站式連接常用生產力工具；也有針對 Slack、Notion、資料庫查詢等單點功能的 MCP 插件，大大豐富了 AI 助手可調用的工具生態。MCP 所營造的正是這樣一個開放且繁榮的代理工具生態系統。